Hacker News Reader

Hacker News

Comment by znpy | Hacker News Reader

Full thread

znpy

I run my own DNS servers at home. I have a small virtualization cluster and run a small DNS vm on each physical host.

My resolvers perform queries against the root servers directly and cache results.

It's refreshing to skip all the DNS fuckery that's going on nowadays.

View on HN

Except for certain applications that want to do their own DNS, eg DOH...

Not the person you responded to, but I too run my own resolver on my router. I also have the router configured to drop [1] all outgoing packets to any DoH IPs; there are a bunch of lists for those, like https://github.com/Sekhan/TheGreatWall

[1]: Specifically, to reject them, which means sending a TCP reset / ICMP unreachable response back rather than blackholing them.

Are you aware of "Adaptive DNS Resolver Discovery"[1] and do you have plans to block that too? (It's already in iOS 14 and slated for macOS 11.)

1: https://datatracker.ietf.org/doc/draft-pauly-add-resolver-di...

So if I understand this correctly, this provides a way for example.com to suggest a DoH server that the client can use to resolve example.com's subdomains? I can see it being problematic because it'll bypass my resolver's ad-blocking.

I don't use any Apple software or hardware, but if Firefox starts using it I'll start worrying about it.

Yes, that's right. I don't know whether this is on the agenda for Firefox or not.

I run a DoH resolver domain-fronted by Cloudflare... Blocking it at IP level would mean blocking other Cloudflare proxied websites. With IPv6, a DoH endpoint rotating between various IPs might get even more trickier to block.

A better strategy might be to look at the SNI for hostname at least until ESNI becomes prevalent (the one I run supports ESNI already).

Which is why my nameservers answer NXDOMAIN to use-application-dns.net, which DoH-using applications are supposed to honor.

And I supply DNS-over-TLS and DNS-over-HTTPS locally. It's really not too difficult.

I have a similar setup, but the DNS servers are at a hosting facility and I access them from home over a VPN. This avoids the problem of the ISP messing with the DNS responses (e.g. to replace NXDOMAIN with an A record for their own bullshit "not found" page with ads).

I do the same, but I read that that is also sending your IP all around the internet, which can have repercussions? The alternative is to not use a recursive resolver, but just punt to one of the "safer" ones such as 1.1.1.1?

edit: downvoting honest questions?

What, exactly, does "sending your IP all around the internet" even mean?

Meaning, if you don't want people to know you are searching for snm.donkeyporn.com than going out to the nameserver that donkeyporn is using is not exactly keeping the information private.

In practice with 1.1.1.1 you're trading the parties who know about your access from:

Donkeyporn's DNS provider, com's DNS provider (0.1% chance it's not already cached), your ISP, transit providers, donkeyporn's ISP, donkeyporn service

To: cloudflare, your ISP, transit providers, donkeyporn's ISP, donkeyporn service

It's not a huge change and it's really about whether you trust CloudFlare more than the service donkeyporn has chosen.

I though correctly switching to cloudflare should just be me -> cloudflare via an encrypted channel?

If you're talking about clouflare warp, then yes... kind of. If you mean only the DNS, them no, there are still many connections matching you to the destination.

You are correct that if you run your own resolver, then all the DNS traffic from your resolver to other nameservers is in cleartext. DoH and DoT only get used by forwarders.

Worth noting that until Encrypted SNI is universally used, you probably transmit snm.donkeyporn.com in the clear when your browser does the initial TLS exchange anyway.

I personally feel that concentrating all the information of "what DNS names are people looking up" into the hands of a few parties (e.g. CloudFlare) makes it much easier to collect and analyze this information.

I tried doing the same, how do you precache and reduce query lookup times for a new website ? Could you explain your setup if you don’t mind ?

Real answer: you don't.

I run the same setup, local resolver that recurses from the roots, and I don't cache anything other than what my systems actually request. If I hit a new site, I pay the penalty for not having certain information cached.

Hows the DNS server to know what to pre-cache to reduce lookup times?

Even for something that is not in the cache DNS is lightweight and quick, and I have full control over when to flush it, and have logs.

I am not huge fan of the trend of various device manufacturers (looking at you Google, and now Apple too) sending queries over DoH instead of using the local resolver on my network :/

DNS lookup times are strongly affected by things entirely within the control of DNS content publishers and nothing to do with what one uses locally, namely whether "glue" is in-bailiwick. Out-of-bailiwick glue causes a massive explosion of additional back-end queries.

This has been a known problem for decades, people having encouraged in-bailiwick "glue" since at least the turn of the century. If you want to decrease lookup times, add your voice to encouraging this. Experts in the field are nowadays generally persuaded that it is a good thing, which took a saddening amount of persuasion. But everyday administrators still too-often do not get encouraged to use in-bailiwick delegations.

* https://cr.yp.to/djbdns/notes.html

Thank you. What an awesome explanation. This has been incredibly helpful. Perhaps one of the web optimizations that site owners need to think about is use in-bailiwick delegations

Reply on news.ycombinator.com