Why does dig +trace ignore Additional Records?

Sat Jan 11 02:01:06 UTC 2020

As we all know, dig +trace can perform iterative queries, starting from the root name server, to the top-level name server, and then to the name server of the second-level domain name.

8 7.158512318 192.168.3.34 → 1.1.1.1      DNS 82 Standard query 0x6ab6 NS <Root> OPT
9 7.324926676      1.1.1.1 → 192.168.3.34 DNS 759 Standard query response 0x6ab6 NS <Root> NS h.root-servers.net NS i.root-servers.net NS j.root-servers.net NS k.root-servers.net NS l.root-servers.net NS m.root-servers.net NS a.root-servers.net NS b.root-servers.net NS c.root-servers.net NS d.root-servers.net NS e.root-servers.net NS f.root-servers.net NS g.root-servers.net RRSIG OPT
10 7.326414937 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0xa368 A h.root-servers.net
11 7.326424674 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0xc77b AAAA h.root-servers.net
15 7.489976046      1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0xa368 A h.root-servers.net A 198.97.190.53
16 7.490044390      1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0xc77b AAAA h.root-servers.net AAAA 2001:500:1::53
17 7.490363812 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0x700e A i.root-servers.net
18 7.490372381 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0x5b1e AAAA i.root-servers.net
19 7.657436455      1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0x700e A i.root-servers.net A 192.36.148.17
36 12.819844666     1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0x5b1e AAAA i.root-servers.net AAAA 2001:7fe::53
...

After obtaining the NS record of the root domain name server, it is right for dig to request each A record and AAAA record. After all, the NS record is only a domain name, not an IP, and cannot communicate directly.

87 21.395051005 192.168.3.34 → 202.12.27.33 DNS 101 Standard query 0x6e00 AAAA www.cloudflare.com OPT
88 21.458617752 202.12.27.33 → 192.168.3.34 DNS 1220 Standard query response 0x6e00 AAAA www.cloudflare.com NS e.gtld-servers.net NS d.gtld-servers.net NS j.gtld-servers.net NS b.gtld-servers.net NS h.gtld-servers.net NS g.gtld-servers.net NS m.gtld-servers.net NS f.gtld-servers.net NS c.gtld-servers.net NS i.gtld-servers.net NS l.gtld-servers.net NS a.gtld-servers.net NS k.gtld-servers.net DS RRSIG A 192.5.6.30 A 192.33.14.30 A 192.26.92.30 A 192.31.80.30 A 192.12.94.30 A 192.35.51.30 A 192.42.93.30 A 192.54.112.30 A 192.43.172.30 A 192.48.79.30 A 192.52.178.30 A 192.41.162.30 A 192.55.83.30 AAAA 2001:503:a83e::2:30 AAAA 2001:503:231d::2:30 AAAA 2001:503:83eb::30 AAAA 2001:500:856e::30 AAAA 2001:502:1ca1::30 AAAA 2001:503:d414::30 AAAA 2001:503:eea3::30 AAAA 2001:502:8cc::30 AAAA 2001:503:39c1::30 AAAA 2001:502:7094::30 AAAA 2001:503:d2d::30 AAAA 2001:500:d937::30 AAAA 2001:501:b1f9::30 OPT
89 21.459649253 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0x2d29 A e.gtld-servers.net
90 21.624062287      1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0x2d29 A e.gtld-servers.net A 192.12.94.30
91 21.624138369 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0x413b AAAA e.gtld-servers.net
92 21.788726811      1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0x413b AAAA e.gtld-servers.net AAAA 2001:502:1ca1::30
93 21.789030810 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0xd55b A d.gtld-servers.net
94 21.947950886      1.1.1.1 → 192.168.3.34 DNS 94 Standard query response 0xd55b A d.gtld-servers.net A 192.31.80.30
95 21.948005357 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0xe26a AAAA d.gtld-servers.net
97 22.105829404      1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 0xe26a AAAA d.gtld-servers.net AAAA 2001:500:856e::30
...

But why does dig ask the recursive name server for A records and AAAA records after getting the NS records of the gTLD server? There are already A records and AAAA records in Additional Records. What is the significance of repeated acquisition?

In fact, this repeated fetching behavior may also cause errors, because the recursive name server is a cache, which may be inconsistent with the authoritative name server.

This issue has been mentioned before, you can read the link below.

https://serverfault.com/questions/482913/is-dig-trace-always-accurate
https://serverfault.com/questions/707706/why-does-dig-trace-seem-to-ignore-the-dns-glue-records

150 30.817289485 192.31.80.30 → 192.168.3.34 DNS 862 Standard query response 0x1dc4 AAAA www.cloudflare.com NS ns3.cloudflare.com NS ns5.cloudflare.com NS ns4.cloudflare.com NS ns6.cloudflare.com NS ns7.cloudflare.com DS RRSIG A 162.159.0.33 A 162.159.7.226 AAAA 2400:cb00:2049:1::a29f:21 AAAA 2400:cb00:2049:1::a29f:7e2 A 162.159.2.9 A 162.159.9.55 AAAA 2400:cb00:2049:1::a29f:209 AAAA 2400:cb00:2049:1::a29f:937 A 162.159.1.33 A 162.159.8.55 AAAA 2400:cb00:2049:1::a29f:121 AAAA 2400:cb00:2049:1::a29f:837 A 162.159.3.11 A 162.159.5.6 AAAA 2400:cb00:2049:1::a29f:30b AAAA 2400:cb00:2049:1::a29f:506 A 162.159.4.8 A 162genius.159.6.6 AAAA 2400:cb00:2049:1::a29f:408 AAAA 2400:cb00:2049:1::a29f:606 OPT
157 35.823185904 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0x506f A ns3.cloudflare.com
158 35.988619665      1.1.1.1 → 192.168.3.34 DNS 110 Standard query response 0x506f A ns3.cloudflare.com A 162.159.7.226 A 162.159.0.33
159 35.988678618 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0xa681 AAAA ns3.cloudflare.com
161 36.154329052      1.1.1.1 → 192.168.3.34 DNS 134 Standard query response 0xa681 AAAA ns3.cloudflare.com AAAA 2400:cb00:2049:1::a29f:21 AAAA 2400:cb00:2049:1::a29f:7e2
162 36.154653899 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0xb343 A ns5.cloudflare.com
163 36.315750932      1.1.1.1 → 192.168.3.34 DNS 110 Standard query response 0xb343 A ns5.cloudflare.com A 162.159.9.55 A 162.159.2.9
164 36.315805776 192.168.3.34 → 1.1.1.1      DNS 78 Standard query 0x9f52 AAAA ns5.cloudflare.com
165 36.483346686      1.1.1.1 → 192.168.3.34 DNS 134 Standard query response 0x9f52 AAAA ns5.cloudflare.com AAAA 2400:cb00:2049:1::a29f:209 AAAA 2400:cb00:2049:1::a29f:937

The behavior after getting the name server of www.cloudflare.com was even more incredible, dig actually ignored the glue records, oh my gosh, this violates the DNS query rules.

Who wrote the code to ignore the glue record and request it again? This is really a genius.

In fact, if there is no recursive name server, this kind of query cannot be performed at all, this is not an iterative query at all.

In conclusion, I really don't understand the significance of dig doing this? This is an obvious bug and definitely not the behavior that a standard DNS resolver should have.