Canary domain – use-application-dns.net | Hacker News Reader

Canary domain – use-application-dns.net

support.mozilla.org

41 pointsconductor51 comments

DoH is such a weird thing.

I am against individual applications making their own DNS queries. This is a responsibility of the OS.

I love the idea that I can query DNS without being spied upon. However, at home, for the protection of my family and me I want all devices to go through a certain DNS server.

So where does this leave us? We're delegating the statement of 'I'm being secure' to the DNS server itself.

Shoutout to my Google Mini which ignores DNS servers in the DHCP response.

This is exactly what Cloudflare wants - they want us to blindly "trust" them with our DNS lookups, even though they've prioritized paying scammers over doing the right thing for years.

> Shoutout to my Google Mini which ignores DNS servers in the DHCP response.

Put Roku on that list. They also break in a spectacular fashion if you redirect the queries to a DNS server that returns NXDOMAIN. Its like they query in an infinite loop with no rate limits. They absolutely hammer the DNS server.

I made it a point to NAT redirect all outbound requests to UDP 53 in our enterprise back to our enterprise DNS server. It would sometimes piss off our engineers, when they realized 8.8.8.8 was somehow resolving our internal DNS names, but if they came to us and nicely explained their use-case then we excluded them from the NAT rule.

Great when you debug something for ages, just to find out your company's DNS setup is broken. Because it can't be DNS, right? /s

Compliance sucks, but it's required. I didn't make up the rules, just implemented and enforced them.

Sorry, my snarkiness was not meant personal, I know you're not to blame :)

I had add port 53 NAT redirect to my home network.

Kindle Fire tablet has hard-coded Google's 8.8.8.8 DNS server, bypassing the Pi-Hole ad blocker.

That's very unkind. It probably took them a good long while to figure out that you did that, in the middle of troubleshooting something else. Why not just block that traffic?

People like you are the reason DoH is being rolled out. I hate the concept, but I would immediately enable it if I caught my IT unapologetically getting in the way of my work like you do.

They seemed to like it less when we blocked it, as their stuff completely failed to work.

Yes, but at least they immediately knew why.

As a one-time developer of consumer IoT hardware I’m divided on this. In principle everything should respect the DNS servers provided by your local DHCP server. In practice some of those DNS servers are hilariously bad, because they’re operated by ISPs, who will happily highjack every single DNS query to inject a message about how you’re approaching your bandwidth quota, or just outright ignore TTLs that were dropped to allow clean switchover between providers. We ended up hardcoding known good DNS servers because otherwise we’d get complaints from customers when things stopped working, and no amount of saying it’s not our fault would avoid being branded as useless crap.

> In principle everything should respect the DNS servers provided by your local DHCP server. In practice some of those DNS servers are hilariously bad, because they’re operated by ISPs

It's not just ISP operated DNS. There are many other scenarios where multiple parties share one DHCP server, where the DHCP admin's choice of DNS might not be what every other participant desires. For instance, using a public wifi, roommates sharing a router, visiting someone's house, etc.

> I am against individual applications making their own DNS queries

But every other network request they will ever make is fine if they do it themselves? Like at some point we have to be like DNS being a service provided by the system to apps was mostly a historical accident or an idea for a network model that never really panned out.

I would have loved to see the alternate universe where your typical unprivileged app has no direct access to sockets and routes all requests through a system service that handles all the application-layer protocols and encryption.

> Like at some point we have to be like DNS being a service provided by the system to apps was mostly a historical accident or an idea for a network model that never really panned out.

I think that I prefer the network model where I the system owner have control over what the programs executing on my behalf are doing on my system and my network. I really don’t want to be presented the choice of binary blob A, binary blob B or living without Internet access.

> I would have loved to see the alternate universe where your typical unprivileged app has no direct access to sockets and routes all requests through a system service that handles all the application-layer protocols and encryption.

Ditto.

Yeah, I think the question is what exactly the thread model is and what gets protected.

DoH as protection of my own traffic against snooping ISPs is very much welcome. DoH as protection of locked down apps and devices against their owners - not so much.

> The use of this domain is specified by Mozilla, as a limited-time measure until a method for signaling the presence of DNS-based content filtering is defined and adopted by an Internet standards body.

Yeah. Once DoH succeeds in preventing DNS based blocking of ads, trackers, etc., I’m sure all the big tech companies will come back to the table and agree on a standard that gives that power back to users.

/s for anyone that needs it.

> Once DoH succeeds in preventing DNS based blocking of ads, trackers, etc...

I'm not sure how DoH dramatically changes this. Even absent DoH a device can always ignore your network's DNS settings and just query 8.8.8.8 or whatever "known good" DNS server they wanted. This isn't uncommon with IoT devices today, usually to avoid ISP tampering with DNS.

Routers can intercept your Port53 queries and inject their own replies.

This is almost the exact opposite reason why browsers adopted DoH; the problem is that DNS providers and any intermediary that can MitM have been applying content filtering at the DNS level. It can also be used to track users to an extent. DoH is necessary to reduce the set of parties who are able to see what domains you are accessing, in conjunction with ECH.

I actually think Chromium adopted the better solution. Chromium will "upgrade" to DoH when you are already connecting to a DNS server known to support DoH anyways. It also bothers to implement /etc/hosts resolution, as well.

Of course Google could use DoH to defeat AdBlock, but they can do that regardless of whether or not DoH is adopted by browser vendors. You already have control over the DNS resolution on your browser/most devices, so it hardly does anything. If they really wanted to defeat DNS based filtering, there's no reason they need to use DNS in the first place.

For some reason, unencrypted DNS has a lot of fans. I don't understand it. I can understand why Firefox's approach is not loved, but Chromium's approach seems entirely reasonable and has basically no conflict of interest whatsoever.

> the problem is that DNS providers and any intermediary that can MitM have been applying content filtering at the DNS level. It can also be used to track users to an extent. DoH is necessary to reduce the set of parties who are able to see what domains you are accessing, in conjunction with ECH.

I am my DNS provider. I choose to apply content filtering.

DoH just increases the set of parties who see my traffic.

> DoH just increases the set of parties who see my traffic.

DNS-over-HTTPS has nothing to do with your traffic being sent to somewhere you didn't intend for it to. If you experienced something like this, it's because some software decided to ignore your configured DNS resolver, which has absolutely nothing to do with DNS-over-HTTPS and is not how it is implemented in all software. If a piece of software wishes to, it can use any name resolver it wants, and bypass the DNS system altogether.

You can also run your own DNS-over-HTTPS resolver. It's probably even a good idea to.

Reading the comments I think it may sound worse than it is.

> The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.

So basically it sounds like a way for system administrators to disable DNS over HTTPS on their local network when DoH is enabled by default on the machine.

Though I'm not sure what's preventing people from abusing this on public networks and ISP level.

How is it abuse? Think about it - something is turned on for you by default, without asking you, which sends all of your DNS lookups to some third party (Cloudflare), which we have no reason to trust (rather, we have plenty of reasons to not trust).

So a public network, which you already have to trust enough to use, tells you which DNS servers to use, and there's an implicit agreement and understanding about that. So which is more abusive - this implicit agreement and understanding, or some third party changing your defaults without asking you which then sends all your lookups to a third party you probably didn't even know anything about?

You may not have a reason to trust Cloudflare but if DoH is off you are essentialy trusting every router / NAT gateway / anyone capable of packet inspection between you and the DNS server.

I think this can be translated pretty accurately as follows.

You may not have a reason to trust Cloudflare, a company that you have no contract with, and a company that you do not pay, and a company that blocks most of the internet to people using browsers/extensions to protect their privacy.

But if DoH is off, you are essentially trusting your hardware, and your ISP with which you have a paid contract.

One must have technical expertise and lots of available time to enforce said contract

And one must have magical powers to enforce a contract that doesn't exist.

Enforcing a hard-to-enforce contract is possible, and such contracts have been enforced before.

You will have a more difficult time getting anyone to enforce good behaviour from an entity that you do not pay, and have no contractual relationship with. Especially if that entity is subject to a law that requires them to access not only their data on US servers, but foreign ones as well.

My point was this can be done on any network you join... a coffee shop, a coworking space, etc (unless your using encrypted VPNed obviously) so not just your hardware.

Additionally, any network along the way can inspect unencrypted packets not just your ISP. Unless your ISP is just one hop from the DNS server you're using (or you use your ISPs DNS).

You are trusting potentially dozens of parties... some of whom you have a contract with any many you don't and some of whom may be a malicious government (depending on where in the world you are).

But I do agree with, implicitly, what you are saying. I wish the default wasn't Cloudflare and if you change it explicitly it sounds like the canary won't work anyway.

If you're doing it right then you're using GPO and/or the policies file to lockout the ability to tamper with your preferred DNS settings on browsers in the enterprise.

Worse, I clicked the thumbs down icon on "Was the article helpful?" at the bottom of their page: A forever circling waiting icon appears. Running latest Mozilla Firefox on latest Apple iOS.

In short, it is a *cricket*

Was going to say: as a DNS administrator of 30 years, this stuff does not fully nor adequately explains how this feature is used or benefit the end-user.

> Running latest Mozilla Firefox on latest Apple iOS.

Shouldn't matter btw. On iOS everyone uses Webkit as that's the only engine Apple allows on the App Store.

I don’t completely understand this.

Isn’t the purpose of DoH to increase privacy?

But then if I go to a coffee shop that wants to inspect my DNS queries, they can respond for this mentioned domain in a certain way, and it will result in DoH being disabled and leaving the coffee shop free to inspect the unencrypted DNS I am making?

Not entirely certain, but I think to some degree this is a way for the network to say, “I will not respect your privacy, so don’t try”.

If a network implements DNS-based content filtering and blocks DOH requests, not responding to a query for this domain could allow an application to know to not bother trying DOH, since it will definitely fail every time.

I could be totally off the mark here, though.

> and blocks DOH requests

It’s on port 443, probably to the IP of a huge CDN. How would you block it?

This comes up in discussions quite a bit but in practice I have never seen that become a thing. There is technically nothing stopping a DNS provider from using random CDN nodes but unless you have found a working exception they all have well defined static IP addresses, sometimes even novelty IP's. Perhaps some day they will do this at the risk of CDN nodes getting blocked.

I block DoH/DoT quite successfully on my network, not to invade privacy but to block privacy invading sites and usage statistics that the current DoH/DoT providers gather. Thus far it has not been an issue.

I was surprised to find that cell phones automagically discover my DoT 853 listener on my firewall that is served up by Unbound. I do have a "_dns.resolver.arpa" hint record but nothing has ever queried it.

> This comes up in discussions quite a bit but in practice I have never seen that become a thing.

How would you even know it’s happening? Is it even possible to snoop on HTTPS traffic if you have a mobile device like an iPhone? Making it impossible to see is the entire point AFAIK.

I have physical access to the devices and I can also see every device that is registered in DHCP making queries to Unbound. Unless a specific application is leaking requests to 443 I can say with certainty that they are using my DNS server. People on my network appreciate the ad blocking and I would hear about it if that stopped working.

[Edit] I should also add that I do not block VPN's. If someone wants to manually bypass my DNS they can do so with a VPN client. Perhaps some day all the browsers will start creating VPN tunnels to random CDN's on 443.

So you can tell they’re not using your DNS server, but you said:

> I block DoH/DoT quite successfully on my network

How do you block encrypted traffic that’s mixed in with normal HTTPS? I get that you can block the well known IPs, but that’s only a partial solution.

Ah of course, sorry, teaches me to speak without thinking.

DoH only increases privacy if the DoH provider is demonstrably more honest and privacy concerned than the network you're on. Mozilla defaults to Cloudflare, and Cloudflare are deceptive, disingenuous, and scammer friendly. Plus, many of us who care about privacy believe Cloudflare would sell access to the data they collect (the DNS lookups) to the US government for the right price.

The argument for this is specious at best - people who don't care enough to change their own DNS servers on their own networks apparently have to be saved from themselves, which is why Firefox decided to turn it on without prompting the user, in spite of many people complaining about changing the default without asking.

Enabling this canary domain doesn't disable DoH, if you've explicitly turned it and/or configured DoH with your own settings. DoH still stays on.

> many of us who care about privacy believe Cloudflare would sell access to the data they collect

The Cloudflare DoH privacy policy is already one of the least privacy friendly, so anyone who remotely cares about their privacy should not be using Cloudflare DoH.

For example, "transactional and debug log data" is stored for 25 hours at Cloudflare.

> But then if I go to a coffee shop that wants to inspect my DNS queries

If you're in a coffee shop and not using a VPN then, well....

But in direct answer to your question. No.

If you setup DoH correctly then you are not reliant on the initial DNS lookup. For example 9.9.9.9 has a valid cert for 9.9.9.9, so no initial DNS lookup needs to be done.

It seems like you misunderstood the question, which was about the coffee shop messing with queries about the canary domain, not queries about the DoH endpoint.

`use-application-dns.net` to me means:

As an application, don't do your own DNS lookups but respect the ones from the OS.

Which makes me wonder, does Windows respect `use-application-dns.net` when I enable DoH?

It doesn't seem relevant to that situation:

> The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.

This domain has zero to do with home use and everything to do with enterprise. DNS is one of the best tools for detecting and sinkhole'ing malicious domains using threat intelligence feeds. If the systems on your network are bypassing your DNS servers then you lose that visibility and ability to filter malicious DNS traffic.

The ship has already sailed... no one says one has to use the prescribed DoH protocol. An app could simply embed a list of known IP addresses and make custom TCP queries using entirely proprietary / opaque protocols to "resolve DNS" or just discover ip addresses for their services.

I'm sure many applications and devices are already doing it. Who has the time and inclination to monitor the network traffic of all their appliances to ensure they're not being spied on? I wish someone would and we'd publicly shame all the scumbags that do it, but alas...

Can we rename the domain to "privacy-isnt-permitted-on-this-network.net"?

more like "tell-cloudflare-everything-i-visit"...

Sounds like this is meant to avoid interfering with internal DNS servers. Mozilla's documentation says that if you enable DoH manually, it will use DoH even if the canary domain check would have turned it off.

Reply on news.ycombinator.com