Odd DNS Requests that are Normal (2019) | Hacker News Reader

Odd DNS Requests that are Normal (2019)

isc.sans.edu

45 pointspmoriarty17 comments

It's been a couple years since I plugged in my Amazon Alexa, but at the time it rocketed three domains to the top of my frequently resolved list: example.com, example.net, and example.org each dwarfed the 4th most frequent request and cumulatively they were more than half my queries.

Sixty times per hour it resolved all three and sent http requests to all three.

I assume it was a simple connectivity check, but using those three domains was worse than redundant, it was gratuitous. They all resolve to the same IP address, same NS record, and connect to the same service on the same server. The only scenario I can conceive of that would cause the second or third test to differ from the first is if the IANA borked one of their registrar records.

Anyway I got the thing to read me a book during LASIK recovery and unplugged it within a week after the third time it piped up out of nowhere. (Nothing like waking up during a deep sleep in a quiet house to a blaring "SORRY, I DIDN'T QUITE CATCH THAT.") Maybe someone who didn't have that problem can let us know if the device is still doing this.

Curious that example.com et al actually resolve and have IP addresses even though they are IANA reserved domains for documentation, I would have thought they won't result in delivering requests over the network.

The existence of the website is documented in the RFC:

https://datatracker.ietf.org/doc/html/rfc6761#section-6.5

> All example names are registered in perpetuity to IANA:

[…]

> IANA currently maintains a web server providing a web page explaining the purpose of example domains.

Yep. That RFC also is interesting because the older RFC it supersedes recommended using .example foremost, having the example second-level domains in a more side note status, and that is absent from the newer (2013) RFC.

A non-working example would be a bad example.

example.com is actually useful for manual connectivity checks because it doesn't redirect http to https.

Agree that analyzing DNS requests is the highest-value infosec practice when it comes to detecting compromises in enterprise networks.

Shame that (mostly US-based) ISPs realized the same thing (albeit for entirely different purposes), and therefore DoH is now pretty much the default.

And ensuring all DoH requests go through a corporate proxy is... not entirely trivial. On Windows, all major browsers respect their respective group policies, but that doesn't help for mobiles and such.

Shame!

> And ensuring all DoH requests go through a corporate proxy is... not entirely trivial.

Remember that it's a good thing that it's hard to do that. If it were easy, then the ISPs would just do it too.

I have found it trivial to block DoH/DoT public resolvers and I believe it would be trivial for an ISP to do it as well. My theory around why they don't is the customer support issues and potential negative PR. Adding to that, short of totalitarian regimes there really is not any incentive to block DoH. Totalitarian regimes can simply disable the internet or kick doors down if they think something is up. All other ISP's can still monitor what websites a person visits if they wish as server names in TLS handshakes are not encrypted. If anything DoH/DoT servers remove some load off the ISP's DNS resolvers.

In my opinion DoH does not really add much privacy and in reality just doubles the number of organizations that can monitor a persons traffic patterns. Now instead of Comcast it is Comcast and Cloudflare that can analyze ones behavior. This would be a major win for governments should have an agreement in place with a centralized DoH/DoT provider. Instead of aggregating hundreds of ISP logs and having to chase down all the new ISP's, they get everyone that is using any of the popular browsers all in one fell swoop.

One place DoH might make sense is in an organization such as a college campus or company that enable fascist firewall rules but have not yet blocked DoH/DoT. Or maybe non-technical parents using a consumer router to block content.

> All other ISP's can still monitor what websites a person visits if they wish as server names in TLS handshakes are not encrypted.

eSNI/ECH is a thing.

> Now instead of Comcast it is Comcast and Cloudflare that can analyze ones behavior.

No, because of the above, it'd be just Cloudflare instead of just Comcast, and there's two reasons to like that better: that Cloudflare is more trustworthy, and that Cloudflare doesn't know the real person behind the IP address like Comcast does.

> One place DoH might make sense is in an organization such as a college campus or company that enable fascist firewall rules but have not yet blocked DoH/DoT. Or maybe non-technical parents using a consumer router to block content.

It definitely does make sense in those places, but they're far from the only ones.

What browsers and how many sites are currently using eSNI by default? My understanding is that is a thing only in limited concept. The RFC [1] is still an active draft.

Why is Cloudflare more trustworthy with my browsing habits? I have no contract with them and no agreements on what they may do with my internet activity. I have no contract stating how the data is to be used, how long it is to be kept or whom it may be shared with or sold to. For all I know they could sell that data right back to Comcast. Or worse, they could feed it into a ML training program for a social credit system for future use.

[1] - https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

> What browsers and how many sites are currently using eSNI by default?

It's not widely rolled out yet, but it exists and it will be in the future.

> Why is Cloudflare more trustworthy with my browsing habits?

Because of a comparison of Cloudflare's and Comcast's past track record of privacy-related matters.

I suppose my personal experience varies from that a bit. I agree Comcast has a horribly shady past abusing their customers.

Cloudflare's origins are lesser known, likely even to those currently working for them. That doesn't really matter for this purpose I suppose. Former volunteer for their previous honeypot project

In the end, I have no contracts with anyone stating how my data may be (ab)used or how long it will exist. So instead of one company potentially abusing my data, now it is two. There is really no way around that other than to not participate. My personal preference is to assume the Only Two Rules. [1]

In full disclosure, I use neither of those services for DNS but my I would not expect non-HN people to use my convoluted process combining open source VPN meshes, dozens of unbound caches and dozens on many VPS providers that talk to upstream DoT resolvers with cron jobs that pre-cache thousands of domains in random orders using "shuf" that I do not visit and dozens that I do visit and unbound configured to both override min-ttl and to hold onto 0-ttl records until requested again and running the same cron jobs on my home firewalls that talk to those VPS nodes over DoT and Tinc.

[1] - https://www.youtube.com/watch?v=Wxi-IUnCN_8 [video]

Many places block DoT eg the Sky ISP provided router (as it relies on DNS for parental controls) or the WiFi on the London Underground.

That's one of the reasons DoH is better than DoT: it's harder to block wholesale.

Looking at my DNS requests, I discovered many things that are considered normal but are completely non-necessary... like Firefox pinging Mozilla's servers every few minutes to detect captive portals (on my desktop computer). I stopped that one (network.captive-portal-service.enabled) along with others in other software and devices.

You can sneak information out via the DNS requests, got to write your own DNS server first to respond accordingly but its just one of the many ways you can bypass security systems, its just another communication channel.

Reply on news.ycombinator.com