>Ok.. so if I am following this the domain academy.edu
>(http://www.dnsreport.com/tools/dnsreport.ch?domain=academy.edu) means
>that the top level dns servers do not have the proper records to supply
>both the ns and A records.
the servers that are the parent for .edu zone are:
# dig @A.ROOT-SERVERS.NET edu. ns
; <<>> DiG 8.2 <<>> @A.ROOT-SERVERS.NET edu. ns
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 9
;; QUERY SECTION:
;; edu, type = NS, class = IN
;; ANSWER SECTION:
edu. 6D IN NS E.ROOT-SERVERS.NET.
edu. 6D IN NS D.ROOT-SERVERS.NET.
edu. 6D IN NS A.ROOT-SERVERS.NET.
edu. 6D IN NS H.ROOT-SERVERS.NET.
edu. 6D IN NS C.ROOT-SERVERS.NET.
edu. 6D IN NS G.ROOT-SERVERS.NET.
edu. 6D IN NS F.ROOT-SERVERS.NET.
edu. 6D IN NS B.ROOT-SERVERS.NET.
edu. 6D IN NS I.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
ie, the root-servers.net are parents for the .edu child zone
Now we ask for academy.edu's NS's:
# dig @D.ROOT-SERVERS.NET academy.edu ns
; <<>> DiG 8.2 <<>> @D.ROOT-SERVERS.NET academy.edu ns
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; academy.edu, type = NS, class = IN
;; ANSWER SECTION:
academy.edu. 2D IN NS DBRU.BR.NS.ELS-GMS.ATT.NET.
academy.edu. 2D IN NS DMTU.MT.NS.ELS-GMS.ATT.NET.
The root-servers.net are not the parent for the .net zone, so they do not
have the glue for the .net zone. The querying DNS must itself go "fetch
glue" for the .net NS's from the .net parent, but which NS's are parent for
.net?
# dig net. ns
; <<>> DiG 8.2 <<>> net. ns
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; net, type = NS, class = IN
;; ANSWER SECTION:
net. 14h26m29s IN NS B.GTLD-SERVERS.net.
net. 14h26m29s IN NS D.GTLD-SERVERS.net.
net. 14h26m29s IN NS L.GTLD-SERVERS.net.
net. 14h26m29s IN NS F.GTLD-SERVERS.net.
net. 14h26m29s IN NS J.GTLD-SERVERS.net.
net. 14h26m29s IN NS K.GTLD-SERVERS.net.
net. 14h26m29s IN NS E.GTLD-SERVERS.net.
net. 14h26m29s IN NS M.GTLD-SERVERS.net.
net. 14h26m29s IN NS A.GTLD-SERVERS.net.
net. 14h26m29s IN NS G.GTLD-SERVERS.net.
net. 14h26m29s IN NS H.GTLD-SERVERS.net.
net. 14h26m29s IN NS C.GTLD-SERVERS.net.
net. 14h26m29s IN NS I.GTLD-SERVERS.net.
;; ADDITIONAL SECTION:
B.GTLD-SERVERS.net. 17h25m53s IN A 192.33.14.30
D.GTLD-SERVERS.net. 17h25m53s IN A 192.31.80.30
L.GTLD-SERVERS.net. 17h25m53s IN A 192.41.162.30
F.GTLD-SERVERS.net. 17h25m53s IN A 192.35.51.30
J.GTLD-SERVERS.net. 17h19m16s IN A 210.132.100.101
K.GTLD-SERVERS.net. 17h19m16s IN A 213.177.194.5
E.GTLD-SERVERS.net. 17h19m16s IN A 192.12.94.30
M.GTLD-SERVERS.net. 17h19m16s IN A 202.153.114.101
A.GTLD-SERVERS.net. 17h51m35s IN A 192.5.6.30
G.GTLD-SERVERS.net. 17h25m53s IN A 192.42.93.30
H.GTLD-SERVERS.net. 17h25m53s IN A 192.54.112.30
C.GTLD-SERVERS.net. 17h25m53s IN A 192.26.92.30
I.GTLD-SERVERS.net. 17h25m53s IN A 192.36.144.133
So we, the querying DNS missing some glue, go "fetch the missing glue" from
the .net parent for att.net NS's:
dig @a.gtld-SERVERS.NET DBRU.BR.NS.ELS-GMS.ATT.NET a
; <<>> DiG 8.2 <<>> @a.gtld-SERVERS.NET DBRU.BR.NS.ELS-GMS.ATT.NET a
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUERY SECTION:
;; DBRU.BR.NS.ELS-GMS.ATT.NET, type = A, class = IN
;; ANSWER SECTION:
DBRU.BR.NS.ELS-GMS.ATT.NET. 2D IN A 199.191.128.106
;; AUTHORITY SECTION:
ATT.NET. 2D IN NS MACU.MA.MT.NP.ELS-GMS.ATT.NET.
ATT.NET. 2D IN NS OHCU.OH.MT.NP.ELS-GMS.ATT.NET.
ATT.NET. 2D IN NS ORCU.OR.BR.NP.ELS-GMS.ATT.NET.
ATT.NET. 2D IN NS WYCU.WY.BR.NP.ELS-GMS.ATT.NET.
;; ADDITIONAL SECTION:
MACU.MA.MT.NP.ELS-GMS.ATT.NET. 2D IN A 199.191.145.136
OHCU.OH.MT.NP.ELS-GMS.ATT.NET. 2D IN A 199.191.144.75
ORCU.OR.BR.NP.ELS-GMS.ATT.NET. 2D IN A 199.191.129.139
WYCU.WY.BR.NP.ELS-GMS.ATT.NET. 2D IN A 199.191.128.43
In the ;;ANSWER SECTION above is the A record "glue" that was "missing"
from *.root-servers.net, because the root-servers.net are not the parent
for the .net zone. (We would have to make a second query to get the A for
the second att.net NS.)
>They are supplying the ns record but not the A record?
yep. and that's correct behavior.
>And in this case ATT does not have the record properly set up
>for the client?
There nothing improper here. There is no error anywhere. Scott just needs
to remove his error msg.
Len (I'm teaching in Newark this week, then in Maidenhead, Frankfurt, & London)
________________________________________________________________________
Men & Mice: QuickDNS - DNS Expert - DNS Training - DNS Consulting
DNS Classes: Newark Sep 27-28, Toronto Oct 18-19, Frankfurt Nov 21-23,
London Nov. 26-28, Maidenhead Oct 31-Nov 2
http://MenAndMice.com/DNS-training
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
