Hacker News Reader

Comment by neilalexander | Hacker News Reader

You could just run a recursive resolver yourself by using the root hints. You don't need to delegate your DNS queries onto a third-party resolver like Quad9.

https://www.iana.org/domains/root/files

View on HN

Thanks for that, appreciated. I'll be honest- I'm just a 'little guy' in the food chain so I always figured that doing something like that was for the ISP level folks <edit to clarify, I mean connecting to a Zone 1 Resolver. I wasn't aware that one could download the Root Hints File directly (Thanks!).

One quick question though - After taking a quick skim of it the list seems to be extremely 'Western-Centric' (reference link https://www.internic.net/domain/named.root)

The root servers are anycasted. Each one of those root server IPs corresponds to N physical servers at diverse networks / locations all over the world.

The canonical DNS system itself is extremely Western-Centric.

As are many Western inventions

DNS[0] is only a decentralized hierarchy with caching, a class of system which pre-dates the digital era as the de-facto means of political and military organization in any human society larger than a village or town. DNS as a directory system for IP is could itself be viewed as a direct philosophical descendant of military insignia (perhaps via the then-popular branch-tangent of the telephone book, itself ex-telegraph, and postal system) and these could all be in effect traced back to at least Roman society[1], I don't think arguing this is a "western" invention is very convincing or useful. Any ancient army or polity of any size would have had an equivalent, which would then include ancient Egypt, China[2], India, Mesopotamia[3], Mesoamerica, etc. Actually, come to think of it, the comparative study of ancient postal systems would be pretty interesting.[4]

[0] Original DNS RFC1035 https://datatracker.ietf.org/doc/html/rfc1035 (1987) [1] Somewhat cheekily as the inventor of DNS has a Greek surname. https://en.wikipedia.org/wiki/Paul_Mockapetris [2] 2000+ years ago and mature enough to have QoS+max-TTL/hop: http://libgen.rs/scimag/10.1163%2F9789004292123 (pp17-48) + where I write this. [3] Evidenced to 9th century BC https://www.ucl.ac.uk/sargon/essentials/governors/thekingsro... [4] Start by fixing https://en.wikipedia.org/wiki/Timeline_of_postal_history

By that same token the internet was invented by the first person to hand gesture to another one. You can’t dilute DNS down to a directory because there were/and are already other directory protocols.

Walking gets you from A to B just like a car, so actually the first bipeds really invented the automobile.

It's more like describing a walking robot as an original invention, which it is, but all they really did was ape apes.

> I don't think arguing this is a "western" invention is very convincing or useful. Any ancient army or polity of any size would have had an equivalent, which would then include ancient Egypt, China[2], India, Mesopotamia[3], Mesoamerica, etc.

And yet, none of these other regions and cultures actually did invent it, and thus it remains a Western invention.

Of course. However, my point was the originality and claim to authorship is low, because if you look at store and forward networks with centrally agreed node identification and local caching using that for routing purposes, humans have literally done it globally for 3000+ years... that's clear prior art.

It's like "technology" being used to describe a bash script, or "invention" used to describe a standard algorithm.

https://datatracker.ietf.org/doc/html/rfc883#page-72

You've been nerdsniped my friend! bazinga

They are western centric, and unfortunately, in this current state of the web they're still essentially the authority on DNS.

Alternatively, you can maintain the NSes for all the TLDs you are particularly interested in, and alert yourself if they change to something you don't recognize.

Finally, keep in mind that whatever you do, you need to have multiple vantage points to the internet. There's not a lot stopping your ISP from not delivering you to the right host when you try to talk to it. E.g. your ISP can fake the DNS responses.

> They are western centric, and unfortunately, in this current state of the web they're still essentially the authority on DNS.

I‘m curious to see your evidence on that or which future state you would see as a more fortunate one.

Questioning why the distributed cluster runs on nodes 'a' and 'b' alone doesn't necessarily imply that nodes 'c', 'd' and 'e' are any better or worse, today or in future.

If I knew the answer to this I would be very rich and probably have my name on multiple textbooks of solving decentralized computing problems.

> I'm just a 'little guy' in the food chain so I always figured that doing something like that was for the ISP level folks

A lot of people are running recursive resolvers at home (like pi-hole stuff, or most people running some custom openwrt router/modem). I'm running one on my laptop (my resolver is localhost) and it works great.

> After taking a quick skim of it the list seems to be extremely 'Western-Centric'

It is, but that's what the internet is. But by running your own recursive resolver you can control your cache and a lot of the data doesn't change often. If you're extra paranoid you can cache the record data (or even archive the history) for ccTLD (or even all TLDs). For stuff (domains) you're interested in you can also hard-code or otherwise program "non-standard" ways to resolve the ips (by somehow populating a local database that overrides recursive resolution), like pi-hole/safebrowsing blocklists, stuff from institutions or CDNs you trust.

Although querying the root servers directly is always unencrypted right? So your ISP can see and might manipulate all queries at will?

In addition to the root hints, you should also download the DNSSEC anchor key (available on the same site as the root hints). That will let you detect manipulations of records that are DNSSEC-signed.

Otherwise, you could spin up your recursive resolver on your cloud, VPS, or other hosting provider of choice, and then use that.

Right, DNSSEC will solve the "manipulate" problem, but it won't solve the "see" problem. But whether that's a concern is up to you. You could run your resolver on a VPS and speak DoT / DoH to that, which shifts the leak from your ISP to your VPS provider.

It doesn't solve the "manipulate" problem we're talking about here, either: nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain; it only (situationally) prevents them from redirecting it somewhere else. (And, of course, it only works if you're running your own recursive server; it does nothing whatsoever in the 8.8.8.8-type use case).

Yes, that's true.

> nothing about DNSSEC prevents a DNS server (or middlebox) from denying results to a disfavored domain

But at least it is detectable thanks to NSEC and NSEC3 records.

Kind of. An intermediary can drop packets and the client will never get the response.

It's detectable when the site that the DNS provider is censoring falls off the Internet!

And make sure it only resolves records for you. Don't leave it wide open or it will be used as an attack vector. https://www.cloudflare.com/learning/ddos/dns-amplification-d...

In theory if you got a resolver which could disable UDP queries, it would then default to TCP, and the ISP couldn't manipulate those. Don't know if any resolver supports disabling UDP though.

Unbound

Unbound as a client will fall back to TCP automatically if the UDP response is too big. I'm uncertain if there is widespread support for TCP servers though.

> would then default to TCP, and the ISP couldn't manipulate those

They can easily manipulate TCP as well. Unless you establish an authenticated session like TLS, TCP can be mitm-ed easily.

The way I handle this is to run unbound on a server in the public cloud and then tunnel over TLS from my local unbound to the cloud instance. My local clients query a PiHole, which forwards to unbound on localhost:15353, which forwards everything over TLS to the fully recursive instance of unbound in the cloud, which uses root.hints.

Still, your cloud vendor can see the requests.

But someone can see it, but you can rotate upstream resolvers to split requests if you have to.

How is the latency for such a setup? And how is the general browsing experience with said latency (I realize it also depends on which sites you frequently access)? I see some cloud providers/CDNs using a caching TTL as low as five minutes.

You spend most of the time waiting for the actual resolve to complete, not for the "transfer" time between you and VPS.

Source: I'm running Unbound on my notebook, I'm actually queried the stats for some heated discussion on reddit.

For example my current stats_noreset:

    histogram.000000.000512.to.000000.001024=17
    histogram.000000.001024.to.000000.002048=33
    histogram.000000.002048.to.000000.004096=251
    histogram.000000.004096.to.000000.008192=509
    histogram.000000.008192.to.000000.016384=1161
    histogram.000000.016384.to.000000.032768=1891
    histogram.000000.032768.to.000000.065536=2611
    histogram.000000.065536.to.000000.131072=3197
    histogram.000000.131072.to.000000.262144=2502
    histogram.000000.262144.to.000000.524288=1547
    histogram.000000.524288.to.000001.000000=857
    histogram.000001.000000.to.000002.000000=121
    histogram.000002.000000.to.000004.000000=70
    histogram.000004.000000.to.000008.000000=22
    histogram.000008.000000.to.000016.000000=441
    histogram.000016.000000.to.000032.000000=80

As you can see most of queries are completed in a way below 500ms. Adding another 20-40ms on top that doesn't change anything, because caching is a thing and with Unbound you can even ask to actually refresh the expiring records, so you would be served a fresh one from the cache every time, though I never bothered with it, it works fine even without it.

Reply on news.ycombinator.com