Closed Bug 1525854 Opened 2 years ago Closed 4 months ago

TRR shouldn't fallback to DNS on DNSSEC error (extended error support)


(Core :: Networking: DNS, defect, P2)




82 Branch
Tracking Status
firefox82 --- fixed


(Reporter: kristian, Assigned: valentin)


(Blocks 1 open bug)


(Whiteboard: [necko-triaged][trr])


(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

User agent: Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0
Build ID: 20190206095431

  1. Set network.trr.mode=2 and
  2. Visit

Actual results:

DNSSEC: "Your resolver does not appear to validate DNS responses with DNSSEC."

Expected results:

DNSSEC: "Your resolver validates DNS responses with DNSSEC."
Firefox should only fallback on network error, not on DNSSEC errors.

Assignee: nobody → valentin.gosu
Priority: -- → P2
Whiteboard: [necko-triaged]

So, right now it's difficult to differentiate between "resolve failed because the DNSSEC failed" and "resolve failed because domain doesn't exist".

The RCODE will be SERVFAIL for a validation error, but it could be SERVFAIL for other reasons too.
One solution in this case would be to retry the DoH resolve with the CD flag set (checking disabled). If the second request succeeds, there is a high probability it's because the DNSSEC validation failed, so we don't fallback to regular DNS.
Of course, it could also intermittently fail/succeed for a bunch of other reasons, so this isn't a clear fix.

One other way would be to set the CD flag, and perform DNSSEC validation locally. Like the previous solution, this is also non-trivial, and since the server is already capable of doing it it seems like we should keep it on the server.

Or lastly, if there was a way for the server to annotate the response in a way that indicates there was a validation failure, that would be best; maybe there is a way, but I couldn't find it.

Blocks: 1434852
Ever confirmed: true

Please look at bug 1495126. I will make it dup of this one.

Also there is:

Duplicate of this bug: 1495126
Whiteboard: [necko-triaged] → [necko-triaged][trr]

Blocked on the standard, but would be good to revisit once the standard discussion is complete.

Waiting on standard to progress. We can get started on this when there's at least one DoH server implementation that implements the draft.

Assignee: valentin.gosu → nobody
Priority: P2 → P3

Prototype implementations for a few open-source resolvers were created during IETF 104 hackathon, so some testing should be possible already... but even the EDNS option code hasn't been allocated yet AFAIK [1] and the error numbers don't seem completely stable yet, so you might want to wait a bit.


This problem really undermines DNSSEC with network.trr.mode=2, as I imagine you often use TRR in cases when your default resolver is "bad" (in some sense) and thus probably doesn't validate, i.e. the bogus names will usually succeed incorrectly. On the other hand, people concerned with privacy would probably dislike silent fallbacks like this anyway, even if caused e.g. by a short connection disruption, so maybe the DNSSEC part is not such a big additional problem relative to the intended properties of .mode=2.

the error numbers don't seem completely stable yet

My bad, you probably don't need to care for the codes or DNSSEC; instead you can just decide based on the "retry flag". In any case, it might be nice to be able to supply multiple URLs to have some private fallback before trying the system resolver.

That relates to the default list of providers which will hopefully get longer than one item and to the way the UI will look like, but there's been little public information around that so far. (I do understand it's PR-sensitive.)

See Also: → 1580551

You need to fix this. network.trr.mode=3 is not a fix!!! See

Also please do a caching of and put it in network.trr.bootstrapAddress so when network.trr.mode=3 it will not broke!!! Or fallback to (and or ipv6 addresses, please use both -- we had a crazy IPS provider that used inside router interface, then it fixed that)
ALSO WHY you cannot open While using trr??

Duplicate of this bug: 1635767

Sorry, Valentin, did not open because it should not open before scan(( Only opens initially... BTW, any progress?

The standard [1] is currently in RFC Editor's queue, i.e. it's quite certain that no significant changes will be done before really publishing it. As for implementations of the final version, I'm not aware of any prototypes. I didn't feel much interest there lately, but perhaps they will start to appear now that we've finally come to some consensus on what the extended errors would look like.


Blocks: doh
Summary: TRR shouldn't fallback to DNS on DNSSEC error → TRR shouldn't fallback to DNS on DNSSEC error (extended error support)
See Also: → 1649801
Assignee: nobody → valentin.gosu
Severity: normal → S3
Priority: P3 → P2

This patch adds support for the Extended DNS Errors draft code.

While not yet in the draft, it seems the OPT code for Extended DNS Error is 15

The list of errors for which we hard fail isn't necessarily final.
I picked the errors that indicate a DNSSec failure, or an intentional
filtering done by the resolver.

Pushed by
TRR shouldn't fallback to DNS on DNSSEC error r=necko-reviewers,dragana
Pushed by
TRR shouldn't fallback to DNS on DNSSEC error r=necko-reviewers,dragana
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch
Blocks: 1667975

Does Cloudflare even support those Extended DNS Errors? What will happen if the server does not support it, it will still be broken under network.trr.mode=2?

I don't think anyone big has deployed it yet, but I certainly don't see a problem in Firefox being the first. If the information is not in the reply, there's not much that can be done...

You need to log in before you can comment on or make changes to this bug.