Hacker News Reader

Comment by rswail | Hacker News Reader

So if I have a recursive nameserver then it will just get the correct answers from the TLD nameservers.

Unless the courts start legislating what people can run in their homes that will ignore any of these rulings.

Hopelessly ignorant of DNS beyond basics. I see this page https://en.wikipedia.org/wiki/Public_recursive_name_server and there is a list of DNS servers. What do you mean by running it on your own computer? If feeling generous, maybe a quick rundown on how to get authoritative name resolution from TLDs? OS setting or need to run something (OS X)? TIA )

Dns is a hierarchical recursive service. When you make a DNS query, such as requesting "www.google.com", you typically do not do the full resolution in your application - but you do make the DNS query on your application. What you instead do is make a DNS request to your configured "recursive" server, asking it to make further queries on your behalf if it doesn't know the answer.

We do something obviously silly for this exercise - we assume that all caches are cold, because the point of a recursive DNS server is mostly to act as a cache. So we'll be going through a bunch of queries that usually are simply answered from cache instead.

At the top are 13 "root dns servers". These return responses for top level domains, such as ".com". When you want to request www.google.com, first you have to ask who controls ".com". Your recursive server (just "you" from now on) sends a request to the root servers - "Who are the nameservers (ns) for .com?" Also written as "QUERY .com NS". The root servers will answer - "A(answer) .com NS 1.2.3.4 AA (Authoritative answer)". The root dns servers believe they are the authority for the "." Zone, because they are.

The recursive resolver, you, then use this knowledge. You ask a similar query of the ".com" nameservers - "Q google.com NS" they respond, giving you an authoritative answer for google.com "A google.com NS nameservers.google.com AA". But you don't know who the nameservers for google.com, how do you resolve this loop? DNS has a mechanism for that. It includes a few extra records, called glue records, to close the gap. "X(tra) nameservers.google.com 8.8.9.9"

Finally, you know who the nameservers for google.com are - You then send them a request. "Q www.google.com A(Internet Protocol)" you might instead send an AAAA request, for an ipv6 address, instead.

There's a ton more - Support for text records of arbitrary type, support for addressing schemes that no longer see use, etc. but thems the basics. You can run your own whole Internet, if you want to - Just build your own recursive server pointing at your own roots, and then host whatever you want on whatever up you want - Just don't expect to be able to connect to the real Internet at the same time. Also basically everything phones home and breaks. :shrug:

Thanks!

DNS is a tree. The root of the tree is a "." (mostly left off). So for example "google.com" is actually "google.com.".

So who looks after "."? Those are the "root servers" that are basically hardcoded into a DNS server.

So when your app requests the IP address of "google.com" with a recursive DNS server, it does the following:

1. Application -> your server "What's the IP address of google.com"

2. Your server: Hmm, I know how to get to ".", I'll ask them about "com".

3. Root server(s) reply with "here are the name servers for "com"

4. Your server: Hey name servers for com, tell me about "google.com."

5. Name servers for com, "we don't know, but here are the name servers for google.com, and their IP addresses, go ask them.

6. Your server: Hey name servers for google.com, tell me the IP address (A) for google.com

7. Google's name servers: The IP address for google.com is a.b.c.d

In steps 3 and 5, the name servers for the higher level in the tree (".", "com") have "glue records" that give you the NS (name server) records for the next level down.

Here's the output of a trace of the lookup for google.com.

You can see first it finding out the NS (name server) records for ".", which are hardcoded in the server, then the name servers for "com.", then the name servers for "google.com." then finally the IP address (A record) for google.com. The RRSIG and DS records are related to DNSsec, which is a security mechanism for guaranteeing the answers:

$ dig +trace google.com

; <<>> DiG 9.18.27 <<>> +trace google.com

;; global options: +cmd

. 29650 IN NS h.root-servers.net.

. 29650 IN NS m.root-servers.net.

. 29650 IN NS d.root-servers.net.

. 29650 IN NS g.root-servers.net.

. 29650 IN NS f.root-servers.net.

. 29650 IN NS e.root-servers.net.

. 29650 IN NS l.root-servers.net.

. 29650 IN NS i.root-servers.net.

. 29650 IN NS c.root-servers.net.

. 29650 IN NS j.root-servers.net.

. 29650 IN NS b.root-servers.net.

. 29650 IN NS a.root-servers.net.

. 29650 IN NS k.root-servers.net.

. 29650 IN RRSIG NS 8 0 518400 20240720050000 20240707040000 20038 . 0M7/rD5sHnlEuTKN5gbTcpUlXvTSPm+uAhIoy4QFSTFV2DCmGDEP1hGg KR1fpO11wmzPhtAKGrDdxaEiWfiEf0/fUYMcl0pg65/FHBNvPM1VrgJ6 cBJ5M9Vq5Fk55ydLK1zKZr7fXP1E03v9k2f2U9dBPVvkMnGueOhNrs7S HfvmPM1oMdJsxLnFW7M1le4sFRnMz2SLb6TPUcuAiy0wl/+QQ6SoR8Pt cH+l095gBydGAA+yRk2FENC0med1e+pra5l+5xypKwGiUEKRLu7qO3hx RvXogiCJ6Y86phc7y+F/YQRu0RxhX41i6BsJSGfUWO+cpcmqSHAoqH+f Xov48A==

;; Received 525 bytes from 172.16.0.254#53(172.16.0.254) in 10 ms

com. 172800 IN NS g.gtld-servers.net.

com. 172800 IN NS a.gtld-servers.net.

com. 172800 IN NS b.gtld-servers.net.

com. 172800 IN NS m.gtld-servers.net.

com. 172800 IN NS c.gtld-servers.net.

com. 172800 IN NS k.gtld-servers.net.

com. 172800 IN NS f.gtld-servers.net.

com. 172800 IN NS d.gtld-servers.net.

com. 172800 IN NS h.gtld-servers.net.

com. 172800 IN NS e.gtld-servers.net.

com. 172800 IN NS i.gtld-servers.net.

com. 172800 IN NS j.gtld-servers.net.

com. 172800 IN NS l.gtld-servers.net.

com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A

com. 86400 IN RRSIG DS 8 1 86400 20240721050000 20240708040000 20038 . HMz1YGw7JwAmZ85745beLSsFWDbix2SV5ZGTyNZr3mE+9/H4D46v9z4x LMO9J+WqwoHeFRpUUePIZuCn1bxUsqxy8F0FBJRuISuQo7kTbEcYwZuF ksFsyyHDiPqAyq4qKvpwYJzSBEqpn+GlXmfZMim4p3xcmD8igYcb2d6Z jeFTOjkDQBudDhsVwSkhRpe5vHFY8aIeTMjzLZxSnUMBbbfrLMYqStx9 H4kV1nxCciwz4u4kxWgZeGvH36eJa/vb5QULBECMIow5LDrGvYoSn2A5 GSZnTjwDWsSPImQWR91bEqi6PrpH0mLm/JnrN1XBksYh1ij9Aw7G6h35 NVGf7g==

;; Received 1198 bytes from 192.112.36.4#53(g.root-servers.net) in 177 ms

google.com. 172800 IN NS ns2.google.com.

google.com. 172800 IN NS ns1.google.com.

google.com. 172800 IN NS ns3.google.com.

google.com. 172800 IN NS ns4.google.com.

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 -

CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM

CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 13 2 86400 20240715002454 20240707231454 956 com. tzsJ3z4Kk4KryI1O0h5CIzr28u4EV4XP/ZAgWu2AXJfKxvbZfAycog1V CJB55AyLB+17t54QOsdjTlYN1KSmvA==

S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 86400 IN NSEC3 1 1 0 - S84BR9CIB2A20L3ETR1M2415ENPP99L8 NS DS RRSIG

S84BOR4DK28HNHPLC218O483VOOOD5D8.com. 86400 IN RRSIG NSEC3 13 2 86400 20240712015714 20240705004714 956 com. +xLRl4ouJCpVTkmW+FufdUyQoWSBSpMGLQmhawqNP0LDVzEIGVav5wdb 2E/EpW5Fi5OLsQjTofjKxbpLPjNtnw==

;; Received 644 bytes from 2001:503:d2d::30#53(k.gtld-servers.net) in 91 ms

google.com. 300 IN A 142.250.70.174

;; Received 55 bytes from 216.239.34.10#53(ns2.google.com) in 21 ms

If your ISP or your government doesn't steal them in transit.

But yes, installing Unbound is easy and with the detailed logging you can actually see what your (or "your") software is quering

Or port 53 starts getting blocked, at which point VPN providers will probably start getting a surge in business.

Port 53 is still needed to communicate with caching DNS servers like 8.8.8.8.

You could still use DNS over HTTPS or TLS protocols.

Reply on news.ycombinator.com