Justus: Created page with "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..."

2026-01-30T04:54:21Z

Created page with "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 <code>zombo.com</code> using <code>dig</code>: <syntaxhighlight lang="bash">dig +trace +all zombo.com</syntaxhighlight> When you run a full DNS request, <code>dig</code> retrieves the <code>A</code> DNS record for a domain by..."

New page

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 <code>zombo.com</code> using <code>dig</code>:

<syntaxhighlight lang="bash">dig +trace +all zombo.com</syntaxhighlight>
When you run a full DNS request, <code>dig</code> retrieves the <code>A</code> DNS record for a domain by querying the whole chain of the '''Fully Qualified Domain Name''' (FQDN) <code>zombo.com.</code>. When a DNS client queries a FQDN, it starts at the root <code>.</code>, and recursively work its way down to query <code>.com.</code>, and then <code>.zombo.com</code>. The precise sequence of queries that <code>dig</code> 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, <code>dig</code> prints some general information, like the command that received, or its version:

<pre>; <<>> DiG 9.18.28 <<>> +trace +all zombo.com
;; global options: +cmd</pre>

== Root name server ==

Next, <code>dig</code> queries the '''DNS resolver''' configured for the network this computer runs in. The DNS resolver has the IP address <code>10.0.48.1</code> and runs on a Ubiquiti Dream Router.

<code>dig</code> asks for the <code>NS</code> record for the name <code>.</code>. It receives a long list of <code>NS</code> records in the answer section. Each of these records starts with a single lowercase letter and ends on <code>.root-servers.net.</code>. Each of these names represent a '''root name server''' that <code>dig</code> can then ask for <code>zombo.com</code>.

Furthermore, the querying the name <code>.</code> also gives us back a few <code>A</code> and <code>AAAA</code> records for each of these root name servers. This tells <code>dig</code> what the IPv4 and IPv6 addresses of each of these root name servers are.

<pre>;; 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</pre>
Some other noteworthy things about the first DNS response:

* The '''opcode''' in the answer is <code>QUERY</code>. The sender of the DNS query sets this value, in this case <code>dig</code>. See <code>opcode: QUERY</code> in line 2.
* The DNS resolver set the <code>QUERY</code> flag to <code>1</code>, which means that this an '''answer''' to a DNS query. You can see this in the second line in <code>QUERY: 1</code>. In the DNS protocol Request For Comments (RFC), [https://datatracker.ietf.org/doc/html/rfc1035#section-4.1.1 RFC 1035] the <code>QUERY</code> field is instead called <code>QR</code>.
* The resolver tells <code>dig</code> that it includes 14 '''answer records''' in this response. You can see this in the second line in <code>ANSWER: 14</code>. The DNS protocol specification calls this header value <code>ANCOUNT</code>.
* The answer contains 27 '''additional records'''. The DNS protocol specification calls this value <code>ARCOUNT</code>. These are values that <code>dig</code> hasn’t requested directly. Instead, the resolver still wants <code>dig</code> to know about these.
* If you manually count the records in the <code>ADDITIONAL</code> section, 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, <code>dig</code> asks the root name server <code>j.root-servers.net</code> for the FQDN <code>zombo.com.</code>. The root name server returns 13 <code>AUTHORITY</code> records that <code>dig</code> can query next to continue resolving <code>zombo.com.</code>. Furthermore, the <code>AUTHORITY</code> section contains the DNSSEC records <code>DS</code> and <code>RRSIG</code>. A recent version of <code>dig</code> is able to check DNSSEC signatures using the <code>+dnssec</code> flag. See [https://serverfault.com/a/154075 this Stack Exchange answer] for more information.

<code>root-servers.net</code> doesn’t hold records for <code>.com</code> domains itself, so it points <code>dig</code> to ask <code>gtld-servers.net.</code> next instead. <code>gtld-servers.net</code> is responsible for '''resolving .com domains'''.

<pre>;; 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</pre>

== Top-level domain name server ==

Here’s what happens when <code>dig</code> asks the '''Top Level Domain (TLD) name server''' <code>d.gtld-servers.net</code> for <code>zombo.com.</code>. Verisign operates the servers at <code>gtld-servers.net</code>. Here are some noteworthy things about the reply that <code>d.gtld-servers.net</code> gives back to <code>dig</code>:

* The response contains signed NSEC3 records. [https://dnsinstitute.com/documentation/dnssec-guide/ch06s02.html NSEC3 records are complex], and I don’t understand them well right now.
* Verisign tells <code>dig</code> that the authoritative name servers are with <code>liquidweb.com</code>, specifically: <code>ns.liquidweb.com</code> and <code>ns1.liquidweb.com</code>.
* <code>dig</code> also receives the <code>A</code> records for the two <code>liquidweb.com</code> name server

Here’s the DNS query response that <code>dig</code> prints out:

<pre>;; 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</pre>

== Registrar name server ==

<code>d.gtld-servers.net</code> told <code>dig</code> that it should ask <code>ns.liquidweb.com</code> for <code>zombo.com.</code>. Here’s the response <code>dig</code> receives after querying <code>zombo.com</code>’s '''authoritative name''' server. The response contains a single <code>A</code> record for <code>zombo.com</code>’s IPv4 address.

Note that the previous DNS queries had no <code>ANSWER</code> section, not counting the query for <code>.</code> in the beginning. Every DNS query response before <code>dig</code> asks <code>ns.liquidweb.com</code> contained <code>AUTHORITY</code> and <code>ADDITIONAL</code> records.

<pre>;; 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</pre>
This illustrates the recursive nature of DNS name resolution. <code>dig</code> 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, <code>dig</code> 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 <code>liquidweb.com</code>. 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. <code>dig</code> can verify the whole chain of DNS responses. You can see for yourself how <code>dig</code> utilizes DNSSEC by starting <code>dig</code> using the <code>+dnssec</code> flag.


== Reference ==

This [https://serverfault.com/a/1045018 Stack Exchange answer] has more information on how to query a domain name and receive a complete trace.

The section [https://en.wikipedia.org/wiki/Domain_Name_System#DNS_message_format 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 [https://datatracker.ietf.org/doc/html/rfc5936 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 [https://datatracker.ietf.org/doc/html/rfc5936#section-5 section 5] of RFC 5936:

<pre>[...]
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].</pre>

== A CVE missing critical details ==

Check out [https://nvd.nist.gov/vuln/detail/CVE-1999-0532 CVE-1999-0532]. It lists the following vulnerability:

<blockquote>A DNS server allows zone transfers.
</blockquote>

The CVE doesn’t contain any other description, such as affected software or version. Judging by this [https://access.redhat.com/solutions/3173331 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 [https://cwe.mitre.org/data/definitions/276.html CWE-276: incorrect default permissions].

DNS things - Revision history