Re: Why does dig +trace ignore Additional Records?

2020-01-27 Thread Ttttabcd via bind-users 
> I am also interested in understanding the reasons behind this
> behaviour, especially after reading the following snippet from the
> official knowledge base [1]:

Thank you for pointing out the official documentation.

dig didn't even implement it according to its official documentation!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Why does dig +trace ignore Additional Records?

2020-01-23 Thread Garri Djavadyan 
Hello list,

I am also interested in understanding the reasons behind this
behaviour, especially after reading the following snippet from the
official knowledge base [1]:

   When following delegation iteratively as specified with the +trace
   option, dig will begin by requesting the NS records for the servers
   authoritative for root (".").  These may or may not be supplied with
   glue - that is A and  records that can be used for the next
   queries dig has to send.  When there is no glue provided, either on
   the initial query for the root nameservers, or later on when
   following delegation, dig will revert to recursively querying the
   servers listed in /etc/resolv.conf to obtain the needed A/
   RRsets.

Many thanks in advance!

Garri

[1] https://kb.isc.org/docs/aa-00208

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Why does dig +trace ignore Additional Records?

2020-01-10 Thread Ttttabcd via bind-users 
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 
 OPT
9 7.324926676  1.1.1.1 → 192.168.3.34 DNS 759 Standard query response 
0x6ab6 NS  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  
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  h.root-servers.net  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  
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  i.root-servers.net  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  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  
www.cloudflare.com OPT
88 21.458617752 202.12.27.33 → 192.168.3.34 DNS 1220 Standard query response 
0x6e00  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  2001:503:a83e::2:30  2001:503:231d::2:30  
2001:503:83eb::30  2001:500:856e::30  2001:502:1ca1::30  
2001:503:d414::30  2001:503:eea3::30  2001:502:8cc::30  
2001:503:39c1::30  2001:502:7094::30  2001:503:d2d::30  
2001:500:d937::30  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  
e.gtld-servers.net
92 21.788726811  1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 
0x413b  e.gtld-servers.net  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  
d.gtld-servers.net
97 22.105829404  1.1.1.1 → 192.168.3.34 DNS 106 Standard query response 
0xe26a  d.gtld-servers.net  2001:500:856e::30
...

But why does dig ask the recursive name server for A records and  records 
after getting the NS records of the gTLD server? There are already A records 
and  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  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  2400:cb00:2049:1::a29f:21  
2400:cb00:2049:1::a29f:7e2 A 162.159.2.9 A 162.159.9.55  
2400:cb00:2049:1::a29f:209  2400:cb00:2049:1::a29f:937 A 162.159.1.33 A 
162.159.8.55  2400:cb00:2049:1::a29f:121  2400:cb00:2049:1::a29f:837 A 
162.159.3.11 A 162.159.5.6  2400:cb00:2049:1::a29f:30b  
2400:cb00:2049:1::a29f:506 A 162.159.4.8 A 162genius.159.6.6  
2400:cb00:2049:1::a29f:408