Closed Bug 1614751 Opened 5 years ago Closed 5 years ago

DoH canary domain use-application-dns.net not honored

Categories

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

73 Branch
defect

Tracking

()

RESOLVED FIXED
user-doc-firefox docs-completed

People

(Reporter: jschauma, Assigned: grover)

Details

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

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Steps to reproduce:

My organization has the DoH canary domain use-application-dns.net blackholed, so any lookup will return NXDOMAIN. Per https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet, this ought to disable the use of DoH in Firefox.

However, I am observing FF 73.0 to continue to use DoH if that is configured.

To wit, the attached screenshot shows my settings, a tcpdump of DNS traffic (showing no lookups at all) and a tcpdump of traffic going to the nextdns DoH server. With those commands running, I started Firefox from scratch; it immediately made DNS lookups to the DoH server, with no lookup for use-application-dns.net ever observed to be sent to the regular resolver.

In short, to reproduce:

  • ensure your DNS resolver returns NXDOMAIN for use-application-dns.net
  • configure FF to use DoH (network.trr.mode=2)

Actual results:

Firefox performed all DNS lookups via DoH.

Expected results:

Firefox should have performed all DNS lookups using the regular resolver.

Component: Untriaged → Networking: DNS
Product: Firefox → Core
Priority: -- → P1
Whiteboard: [necko-triaged]

FF only uses heuristics if the user had doh enabled via the add-on (i.e. there was a UI notification and you clicked "OK") rather than if you select to enable DoH in preferences. In the latter case, the heuristics (which includes checking use-application-dns.net) will not run and DoH will be used all the time, unless an error occurs, in which case it will fall back to regular DNS.

As a workaround, first make sure you disable DoH in preferences, then change doh-rollout.enabled in about:config to true.

That does not seem in line with users' expectations.

Many organizations are concerned that users may enable
DoH and they will leak DNS queries that the
organization would rather not go to external
resolvers, or that would lead to an undesirable user
experience.

The message around the use of the canary domain seemed
to suggest that an organization can prevent the use of
DoH by Firefox entirely by having
use-application-dns.net return e.g. NXDOMAIN.

To quote https://use-application-dns.net:


To signal that their local DNS resolver implements
special features that make the network unsuitable for
DoH, network administrators may configure their
networks to modify DNS requests for the following
special-purpose domain called a canary domain:
use-application-dns.net.

Firefox will attempt to resolve this domain using the
DNS server(s) configured in the operating system of
the device, and examine the result.

The wording does not hint at the use of this canary
domain only applying under certain circumstances. If
that is so, and is not going to be reconsidered, then
the wording around the canary domain needs to be
updated to clarify that an organization has not way
other than forcing client settings on all devices to
restrict the use fo DoH.

(https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
is more clear in this regard: "If a user has chosen to
manually enable DoH, the signal from the network will
be ignored and the user's preference will be
honored."
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_opt-out
again is unclear: "Firefox allows users (via settings)
and organizations (via enterprise policies and a
canary domain lookup) to disable DoH when it
interferes with a preferred policy.")

I've tested the DoH feature enabling it in the Network Settings, it works but ignores use-application-dns.net which we configured.

"Host use-application-dns.net not found: 3(NXDOMAIN)"

This breaks FF on our network for users who enable this feature because of split horizon DNS. It is also a major privacy and security leak as all DNS queries are done through a untrusted party as this is configured on the application level.

(In reply to Machiel from comment #3)

This breaks FF on our network for users who enable this feature because of split horizon DNS.

Note that bug 1582472 made it so we don't use DoH for domains in the DNS suffix list.
If you are able to configure the Local domain suffix for your network, you can make it so that domain and all subdomains are excluded from DoH.
Also, you can use the network.trr.excluded-domains to specify which other domains we should not use DoH to resolve.

It is also a major privacy and security leak as all DNS queries are done through a untrusted party as this is configured on the application level.

If the user chooses to enable TRR, then technically it is a "trusted party"

Whiteboard: [necko-triaged] → [necko-triaged][trr]

proposed fix: bug 1616644

(In reply to Valentin Gosu [:valentin] (he/him) from comment #4)
We discussed this by email before in 2018, thanks again for taking the time. If the proposed fix is implemented we should be good.

doc needed: please update https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet to make it clear that the canary domain only applies to users who get DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.

https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_opt-out also needs update:
"Firefox allows users (via settings) and organizations (via enterprise policies and a canary domain lookup) to disable DoH when it interferes with a preferred policy. "
should be changed to
"When enabling DoH by default for users, Firefox allows users (via settings) and organizations (via enterprise policies and a canary domain lookup) to disable DoH when it interferes with a preferred policy."

ok I'll talk to SUMO to make this change.

Assignee: nobody → agrover

Thanks!! Closing.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: