DNS things
This article contains interesting things that I’ve come across while learning more about DNS.
Anatomy of a DNS request
Here’s how you can run a full DNS request for the domain zombo.com using dig:
dig +trace +all zombo.com
When you run a full DNS request, dig retrieves the A DNS record for a domain by querying the whole chain of the Fully Qualified Domain Name (FQDN) zombo.com.. When a DNS client queries a FQDN, it starts at the root ., and recursively work its way down to query .com., and then .zombo.com. The precise sequence of queries that dig performs depends on each response.
With a full DNS request, you can query DNS records for domains from scratch without needing any DNS resolver or DNS cache.
This is the transcript, split by individual query.
Startup information
First, dig prints some general information, like the command that received, or its version:
; <<>> DiG 9.18.28 <<>> +trace +all zombo.com ;; global options: +cmd
Root name server
Next, dig queries the DNS resolver configured for the network this computer runs in. The DNS resolver has the IP address 10.0.48.1 and runs on a Ubiquiti Dream Router.
dig asks for the NS record for the name .. It receives a long list of NS records in the answer section. Each of these records starts with a single lowercase letter and ends on .root-servers.net.. Each of these names represent a root name server that dig can then ask for zombo.com.
Furthermore, the querying the name . also gives us back a few A and AAAA records for each of these root name servers. This tells dig what the IPv4 and IPv6 addresses of each of these root name servers are.
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38385 ;; flags: qr rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 190794 IN NS b.root-servers.net. . 190794 IN NS m.root-servers.net. . 190794 IN NS h.root-servers.net. . 190794 IN NS i.root-servers.net. . 190794 IN NS j.root-servers.net. . 190794 IN NS d.root-servers.net. . 190794 IN NS a.root-servers.net. . 190794 IN NS g.root-servers.net. . 190794 IN NS f.root-servers.net. . 190794 IN NS c.root-servers.net. . 190794 IN NS e.root-servers.net. . 190794 IN NS k.root-servers.net. . 190794 IN NS l.root-servers.net. . 445435 IN RRSIG NS 8 0 518400 20250118170000 20250105160000 26470 . m7C4icJMnOILA5mlMR9oDLoQBWE0Y9sPoqbXSoVUVrTKgWDbZNOrlMig xBubsOExXwQ4XZg3jwmh6FckcIMly1ZMIfZycMxWvyIvOrgxnBAt4Gu1 sMC4bn45v2BIaMHCaSLwW1jUB+MvrCPhBeYQJsfeLkRBi3W2VPwFIV60 BmPt2/i8jCJrkxx8bOaDGuTGFdwm1L62Ri2+QrewsbRGOcWpJHptJI/h Di61Q/C043YHHhc9w037cKYFeP8dupWS8RLcW/jIELTXhW2FrgETv285 3RndOgaFb9RBoTUo16i3lge1KIMZoS2eksoGQEt8kfgfYVrIKTrwQpf6 Z5NvCQ== ;; ADDITIONAL SECTION: a.root-servers.net. 104582 IN A 198.41.0.4 b.root-servers.net. 276147 IN A 170.247.170.2 c.root-servers.net. 368518 IN A 192.33.4.12 d.root-servers.net. 187359 IN A 199.7.91.13 e.root-servers.net. 187359 IN A 192.203.230.10 f.root-servers.net. 199714 IN A 192.5.5.241 g.root-servers.net. 216475 IN A 192.112.36.4 h.root-servers.net. 240623 IN A 198.97.190.53 i.root-servers.net. 532693 IN A 192.36.148.17 j.root-servers.net. 320888 IN A 192.58.128.30 k.root-servers.net. 271911 IN A 193.0.14.129 l.root-servers.net. 357258 IN A 199.7.83.42 m.root-servers.net. 104622 IN A 202.12.27.33 a.root-servers.net. 113505 IN AAAA 2001:503:ba3e::2:30 b.root-servers.net. 294399 IN AAAA 2801:1b8:10::b c.root-servers.net. 331660 IN AAAA 2001:500:2::c d.root-servers.net. 32858 IN AAAA 2001:500:2d::d e.root-servers.net. 307198 IN AAAA 2001:500:a8::e f.root-servers.net. 408208 IN AAAA 2001:500:2f::f g.root-servers.net. 353355 IN AAAA 2001:500:12::d0d h.root-servers.net. 234104 IN AAAA 2001:500:1::53 i.root-servers.net. 390219 IN AAAA 2001:7fe::53 j.root-servers.net. 463450 IN AAAA 2001:503:c27::2:30 k.root-servers.net. 37861 IN AAAA 2001:7fd::1 l.root-servers.net. 225301 IN AAAA 2001:500:9f::42 m.root-servers.net. 118907 IN AAAA 2001:dc3::35 ;; Query time: 18 msec ;; SERVER: 10.0.48.1#53(10.0.48.1) (UDP) ;; WHEN: Tue Jan 07 10:26:18 JST 2025 ;; MSG SIZE rcvd: 1109
Some other noteworthy things about the first DNS response:
- The opcode in the answer is
QUERY. The sender of the DNS query sets this value, in this casedig. Seeopcode: QUERYin line 2. - The DNS resolver set the
QUERYflag to1, which means that this an answer to a DNS query. You can see this in the second line inQUERY: 1. In the DNS protocol Request For Comments (RFC), RFC 1035 theQUERYfield is instead calledQR. - The resolver tells
digthat it includes 14 answer records in this response. You can see this in the second line inANSWER: 14. The DNS protocol specification calls this header valueANCOUNT. - The answer contains 27 additional records. The DNS protocol specification calls this value
ARCOUNT. These are values thatdighasn’t requested directly. Instead, the resolver still wantsdigto know about these. - If you manually count the records in the
ADDITIONALsection, you may only see 26 records. I don’t know why that’s the case. - The query response contains no authority records.
Finding the top-level domain name server
Proceeding with the next query, dig asks the root name server j.root-servers.net for the FQDN zombo.com.. The root name server returns 13 AUTHORITY records that dig can query next to continue resolving zombo.com.. Furthermore, the AUTHORITY section contains the DNSSEC records DS and RRSIG. A recent version of dig is able to check DNSSEC signatures using the +dnssec flag. See this Stack Exchange answer for more information.
root-servers.net doesn’t hold records for .com domains itself, so it points dig to ask gtld-servers.net. next instead. gtld-servers.net is responsible for resolving .com domains.
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1157 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 27 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1472 ;; QUESTION SECTION: ;zombo.com. IN A ;; AUTHORITY SECTION: com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20250119210000 20250106200000 26470 . DQQ9SqKUcniHKVr6zFNzs6wHLVZ6CdfSFMr3q8tCwh+mLPrKCTRlbnpS TmJy1M8YDEDvrrBO0EFx1rr+cGwcB2RiIfOnLl8c2942n5aOpR+3tZB0 sCP1KFv1+BhiD1RL8dff+rMNJ8+0BWNgsID8/MmI+y8UB/70YERAz/W0 AmOhbN/pHkfgvZfbtrOs6Msz+wcUR17wRCOLazyFnBE19EWnek9SYhj9 Jw440nEZ1Kopi+KqWXG0K+kt1HqZS3J2kkO/TmHyU780F/fOtRP/dWmX 06gSiBe4cCSe3Hs7aHlIe2LwH/ICioNdJj0WjzFJ8IDoC+vmLdRkXh4b NVJHoQ== ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 b.gtld-servers.net. 172800 IN A 192.33.14.30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 m.gtld-servers.net. 172800 IN A 192.55.83.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30 ;; Query time: 11 msec ;; SERVER: 192.58.128.30#53(j.root-servers.net) (UDP) ;; WHEN: Tue Jan 07 10:26:18 JST 2025 ;; MSG SIZE rcvd: 1169
Top-level domain name server
Here’s what happens when dig asks the Top Level Domain (TLD) name server d.gtld-servers.net for zombo.com.. Verisign operates the servers at gtld-servers.net. Here are some noteworthy things about the reply that d.gtld-servers.net gives back to dig:
- The response contains signed NSEC3 records. NSEC3 records are complex, and I don’t understand them well right now.
- Verisign tells
digthat the authoritative name servers are withliquidweb.com, specifically:ns.liquidweb.comandns1.liquidweb.com. digalso receives theArecords for the twoliquidweb.comname server
Here’s the DNS query response that dig prints out:
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29896 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;zombo.com. IN A ;; AUTHORITY SECTION: zombo.com. 172800 IN NS ns.liquidweb.com. zombo.com. 172800 IN NS ns1.liquidweb.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20250111002631 20250103231631 29942 com. HiG6TuJBV47MnPmttWN98zHscsehwlRhgzemiswIdlmKh993eKxhdUbB d4hhuK7piTIFoZ4Gi/THENgJJKuCmg== E5F0ON130HM3M2JQH41BK2763KA5559S.com. 900 IN NSEC3 1 1 0 - E5F126VHCT3KQ620F4OFQ11HB5BJBFRT NS DS RRSIG E5F0ON130HM3M2JQH41BK2763KA5559S.com. 900 IN RRSIG NSEC3 13 2 900 20250113013526 20250106002526 29942 com. 0SoW/r4xPtu4bnmOTSLtkwb9ezAyCHkI1XLAQPRWvu0x7xCBVwguEw8j eR+ZHeLU4x5n5q7d/3/1n/uH2x6kig== ;; ADDITIONAL SECTION: ns.liquidweb.com. 172800 IN A 69.16.222.254 ns1.liquidweb.com. 172800 IN A 69.16.223.254 ;; Query time: 10 msec ;; SERVER: 192.31.80.30#53(d.gtld-servers.net) (UDP) ;; WHEN: Tue Jan 07 10:26:18 JST 2025 ;; MSG SIZE rcvd: 472
Registrar name server
d.gtld-servers.net told dig that it should ask ns.liquidweb.com for zombo.com.. Here’s the response dig receives after querying zombo.com’s authoritative name server. The response contains a single A record for zombo.com’s IPv4 address.
Note that the previous DNS queries had no ANSWER section, not counting the query for . in the beginning. Every DNS query response before dig asks ns.liquidweb.com contained AUTHORITY and ADDITIONAL records.
;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37369 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1680 ;; QUESTION SECTION: ;zombo.com. IN A ;; ANSWER SECTION: zombo.com. 300 IN A 50.28.52.163 ;; Query time: 9 msec ;; SERVER: 69.16.222.254#53(ns.liquidweb.com) (UDP) ;; WHEN: Tue Jan 07 10:26:18 JST 2025 ;; MSG SIZE rcvd: 54
This illustrates the recursive nature of DNS name resolution. dig is able to query any DNS record from scratch. It can do so without needing to know each individual name server responsible for a single domain. Instead, dig figures out which name servers it has to ask on the way to reach the final authoritative name server.
In this example, the authoritative name server is with liquidweb.com. An authoritative name server for a domain name can change in the future. Being able to perform recursive queries and always retrieving accurate information is important for inter-networking.
The DNS security extensions (DNSSEC) further increase the reliability of this system. dig can verify the whole chain of DNS responses. You can see for yourself how dig utilizes DNSSEC by starting dig using the +dnssec flag.
Reference
This Stack Exchange answer has more information on how to query a domain name and receive a complete trace.
The section DNS message format in the Wikipedia article on the Domain Name System explains all the header flags in detail.
DNS zone transfer protocol
The Internet Engineering Task Force (IETF) published RFC 5936 in June 2010. This document specifies the DNS zone transfer protocol, also called Authoritative Transfer (AXFR).
The RFC says that there SHOULD be means to restrict sessions to specific clients, but doesn’t specify them further. Access controls are only RECOMMENDED. See section 5 of RFC 5936:
[...] A DNS implementation SHOULD provide means to restrict AXFR sessions to specific clients. [...] A general-purpose implementation is RECOMMENDED to implement access controls based upon "Secret Key Transaction Authentication for DNS (TSIG)" [RFC2845] and/or "DNS Request and Transaction Signatures ( SIG(0)s )" [RFC2931].
A CVE missing critical details
Check out CVE-1999-0532. It lists the following vulnerability:
A DNS server allows zone transfers.
The CVE doesn’t contain any other description, such as affected software or version. Judging by this Red Hat Solution, this affects the Berkeley Internet Name Domain (BIND) version 9 server on Red Hat Enterprise Linux (RHEL) 6 and 7. RHEL 6 was first released in 2010, and RHEL 7 is from 2013. The timelines don’t add up, since the CVE is from 1999.
This CVE reads like a CWE, since it describes an abstract vulnerability. Compare for example CWE-276: incorrect default permissions.