-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The root servers do not maintain glue for .net name servers. That
glue is in the gtld-servers.net servers.
However, .edu glue is still maintained in the root servers.
Therefore, you got all the information about the query you made that
the root server you queried had available. A followup query to the
gtld-servers.net servers would have given you the glue you are
looking for:
This gets you a referral to the gtld servers:
[root@ahns2 root]# dig DNS.UW-MAD.WISCNET.NET @a.root-servers.net
; <<>> DiG 9.3.0s20020722 <<>> DNS.UW-MAD.WISCNET.NET
@a.root-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60551
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; QUESTION SECTION:
;DNS.UW-MAD.WISCNET.NET. IN A
;; AUTHORITY SECTION:
NET. 172800 IN NS A.GTLD-SERVERS.NET.
NET. 172800 IN NS G.GTLD-SERVERS.NET.
NET. 172800 IN NS H.GTLD-SERVERS.NET.
NET. 172800 IN NS C.GTLD-SERVERS.NET.
NET. 172800 IN NS I.GTLD-SERVERS.NET.
NET. 172800 IN NS B.GTLD-SERVERS.NET.
NET. 172800 IN NS D.GTLD-SERVERS.NET.
NET. 172800 IN NS L.GTLD-SERVERS.NET.
NET. 172800 IN NS F.GTLD-SERVERS.NET.
NET. 172800 IN NS J.GTLD-SERVERS.NET.
NET. 172800 IN NS K.GTLD-SERVERS.NET.
NET. 172800 IN NS E.GTLD-SERVERS.NET.
NET. 172800 IN NS M.GTLD-SERVERS.NET.
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 172800 IN A 192.5.6.30
G.GTLD-SERVERS.NET. 172800 IN A 192.42.93.30
H.GTLD-SERVERS.NET. 172800 IN A 192.54.112.30
C.GTLD-SERVERS.NET. 172800 IN A 192.26.92.30
I.GTLD-SERVERS.NET. 172800 IN A 192.43.172.30
B.GTLD-SERVERS.NET. 172800 IN A 192.33.14.30
D.GTLD-SERVERS.NET. 172800 IN A 192.31.80.30
L.GTLD-SERVERS.NET. 172800 IN A 192.41.162.30
F.GTLD-SERVERS.NET. 172800 IN A 192.35.51.30
J.GTLD-SERVERS.NET. 172800 IN A 210.132.100.101
K.GTLD-SERVERS.NET. 172800 IN A 192.52.178.30
E.GTLD-SERVERS.NET. 172800 IN A 192.12.94.30
M.GTLD-SERVERS.NET. 172800 IN A 192.55.83.30
;; Query time: 23 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Fri Aug 23 10:01:32 2002
;; MSG SIZE rcvd: 469
Here is your glue:
[root@ahns2 root]# dig DNS.UW-MAD.WISCNET.NET @a.gtld-servers.net
; <<>> DiG 9.3.0s20020722 <<>> DNS.UW-MAD.WISCNET.NET
@a.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25122
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;DNS.UW-MAD.WISCNET.NET. IN A
;; ANSWER SECTION:
DNS.UW-MAD.WISCNET.NET. 172800 IN A 205.213.108.100
;; AUTHORITY SECTION:
WISCNET.NET. 172800 IN NS
DNS.UW-MAD.WISCNET.NET.
WISCNET.NET. 172800 IN NS
DNS.UW-MIL.WISCNET.NET.
;; ADDITIONAL SECTION:
DNS.UW-MAD.WISCNET.NET. 172800 IN A 205.213.108.100
DNS.UW-MIL.WISCNET.NET. 172800 IN A 205.213.163.100
;; Query time: 22 msec
;; SERVER: 192.5.6.30#53(a.gtld-servers.net)
;; WHEN: Fri Aug 23 10:01:44 2002
;; MSG SIZE rcvd: 127
Hope this helps a bit.
Dave...
> -----Original Message-----
> From: bind9-users-bounce@xxxxxxx
> [mailto:bind9-users-bounce@xxxxxxx] On Behalf Of Robert Lowe
> Sent: Friday, August 23, 2002 10:21 AM
> To: bind9-users@xxxxxxx
> Subject: Auth ns's in different TLD and no glue
>
>
> Hi!
>
> We have two slaves for our domain, but each of them is in the .net
> TLD. It
> seems that EDUcause does not store glue records for these, which is
> something
> I am sure Network Solutions did for us before EDUcause became the
> .edu registry
> operator. I am wondering exactly what effect this will have. When
> a nameserver
> is charged with finding a record from our domain, it asks the root
> nameservers,
> one of which will return the round-robin ordered list of NS
> records, and in the
> additional section it hands back the A RR for the one that it knows
> about, but
> nothing about the other two since there are no glue records. For
> example:
>
> ; <<>> DiG 9.2.0 <<>> @a.root-servers.net www.lawrence.edu
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49597
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;www.lawrence.edu. IN A
>
> ;; AUTHORITY SECTION:
> lawrence.edu. 172800 IN NS
> DNS.UW-MAD.WISCNET.NET. lawrence.edu. 172800 IN NS
> DNS.UW-MIL.WISCNET.NET. lawrence.edu. 172800 IN
> NS NS1.lawrence.edu.
>
> ;; ADDITIONAL SECTION:
> NS1.lawrence.edu. 172800 IN A 143.44.128.1
>
> ;; Query time: 34 msec
> ;; SERVER: 198.41.0.4#53(a.root-servers.net)
> ;; WHEN: Fri Aug 23 09:16:43 2002
> ;; MSG SIZE rcvd: 129
>
> So what exactly happens at that point? Does the querying
> nameserver happily
> go to the NS for which it already has an A RR (which does have the
> glue records and would return those in the additional section), or
> does it start
> querying for A RR's of the two for which it has nothing, starting
> over at the root nameservers? I am also assuming that BIND wants
> complete information
> about the nameservers before seeding its RTT algorithm. Is this
> true? It's
> hard for me to test without having a non-authoritave nameserver
> with additional-from-cache turned off (is there such a nameserver
> with RA somewhere
> for public diagnostic purposes?). Should EDUcause hold the glue
> records, even
> though they are not absolutely required to?
>
> -Robert
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4
iQA/AwUBPWZJvVq85iiiMQ4EEQI+/QCghqJoN3B6mfjf/RSmRkwanZOINtYAn2GZ
WHtVLrkSv1dgnPQRGWO14kzB
=Gv73
-----END PGP SIGNATURE-----
|
