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

Status: RESOLVED FIXED

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

Description

[Kristian Klausen]

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 network.security.esni.enabled=true
2. Visit https://www.cloudflare.com/ssl/encrypted-sni/

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.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

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.

Comment 2

[Dragana Damjanovic [:dragana]]

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

Also there is:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

Comment 4

[Selena Deckelmann :selenamarie :selena]

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

Comment 5

[Valentin Gosu [:valentin] (he/him)]

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

Comment 6

[vcunat]

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.

[1] https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-05#section-5.1

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.

Comment 7

[vcunat]

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.)

Comment 8

[val.zapod.vz]

You need to fix this. network.trr.mode=3 is not a fix!!! See https://www.reddit.com/r/firefox/comments/cdf4hy/firefox_fails_dnssec_test_at_cloudflares_esni/

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

Comment 10

[val.zapod.vz]

Sorry, Valentin, https://www.dnsleaktest.com/results.html did not open because it should not open before scan(( Only https://www.dnsleaktest.com/ opens initially... BTW, any progress?

Comment 11

[vcunat]

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.

[1] https://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-extended-error/

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1525854 - TRR shouldn't fallback to DNS on DNSSEC error r=#necko

This patch adds support for the Extended DNS Errors draft code.
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-extended-error-16

While not yet in the draft, it seems the OPT code for Extended DNS Error is 15
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-11

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.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/419e26e3f452
TRR shouldn't fallback to DNS on DNSSEC error r=necko-reviewers,dragana

Comment 14

[Razvan Maries]

Backed out for perma failures.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1645108#c3

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8e1ecb457285
TRR shouldn't fallback to DNS on DNSSEC error r=necko-reviewers,dragana

Comment 16

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/8e1ecb457285

Comment 17

[val.zapod.vz]

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?

Comment 18

[vcunat]

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...