1580551 - DoH fails over to legacy DNS if DoH response is 0.0.0.0

Status: RESOLVED DUPLICATE of bug 1649142

(Core :: Networking: DNS, defect)

Description

[Yegor]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Steps to reproduce:

1. Setup a DoH server that filters domains (ads for example) and responds with 0.0.0.0 when those records are resolved
2. Configure the DoH server with trr.mode = 2
3. Resolve an ad domain

Actual results:

The DNS query reached the DoH resolver, but the response was ignored. The domain resolved through the OS configured "legacy" resolver instead.

Expected results:

DoH response should have been used, since it was valid. If using trr.mode = 3, no such problem.

Comment 1

[Florencia Di Ciocco, NI to vbalducci]

Hi Yegor,

Could you share a URL with us so that we may replicate this bug, please?

Thanks in advance, Flor.

Comment 2

[Yegor]

I don't have a public endpoint, as it's currently internal only. I'll have something public in a few days.

However, you can reproduce it with any DoH server that blocks ads, for example: https://blahdns.com/

Then go on popads.net or exoclick.com. In trr=3 mode, they don't load. In trr=2 mode, they do.

Comment 3

[Florencia Di Ciocco, NI to vbalducci]

Hi Yegor,

With the help of this page (https://www.zdnet.com/article/how-to-enable-dns-over-https-doh-in-firefox/) and the ones you gave me I was able to reproduce the bug on Windows 10 on the following versions:

Release 69.0 (64-bit), Nightly 71.0a1 (2019-09-19) (64-bit) and Beta 70.0b3 (64-bit).

I've chosen a component. If you consider that there's another component that's more proper for this case you may change it.

Best regards, Flor.

Comment 4

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

(In reply to Yegor from comment #2)

I don't have a public endpoint, as it's currently internal only. I'll have something public in a few days.

However, you can reproduce it with any DoH server that blocks ads, for example: https://blahdns.com/

Then go on popads.net or exoclick.com. In trr=3 mode, they don't load. In trr=2 mode, they do.

TRR mode 2 intentionally falls back to regular DNS if:

1. The DoH request failed (or returned NXDOMAIN, SERVFAIL or RFC1918 IPs/etc )
2. Connecting to that IP fails -> we do another with regular DNS and connect to that one.

There's a certain overlap with bug 1525854 here - I suggest you watch that one, as it will open up the possibility for a DoH server to specify why you shouldn't fall back to DNS.

Comment 5

[Yegor]

In case of SERVFAIL I can understand this behavior, however NXDOMAIN/RFC1918 doesn't make sense. This is a valid response from the DNS server configured by the user, especially if you're using a filtering/internal DNS server. The failover should only happen if:

DoH server is unreachable OR DoH server is reachable but inoperable. In all other cases it defeats the point of using DoH (in trr mode 2).

Comment 6

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

(In reply to Yegor from comment #5)

In case of SERVFAIL I can understand this behavior, however NXDOMAIN/RFC1918 doesn't make sense. This is a valid response from the DNS server configured by the user, especially if you're using a filtering/internal DNS server. The failover should only happen if:

DoH server is unreachable OR DoH server is reachable but inoperable. In all other cases it defeats the point of using DoH (in trr mode 2).

There are other cases which the DoH server is incapable of handling, which result in NXDOMAIN, such as a DNS suffix, you adding entries to /etc/hosts and many others.
RFC1918 is currently preffable - network.trr.allow-rfc1918 - a regular user who is using a DoH server outside their network normally would not receive RFC1918 addresses.

Comment 7

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

(In reply to Yegor from comment #5)

DoH server is unreachable OR DoH server is reachable but inoperable. In all other cases it defeats the point of using DoH (in trr mode 2).

Oh, and there's also the point of split horizon - where an IP you get from a remote resolver is different than the one you get from the local one, in which case the first IP may not work.
As with every engineering topic, there are trade-offs to be made. In this case mode 2 gives you a decent balance between compat and privacy, while mode 3 gives you full privacy but with compat risks.

TRR as a feature will evolve over time, so we'll eventually be able to cut away at those compromises.

Comment 8

[Daniel Veditz [:dveditz]]

It looks like this was fixed in bug 1648142