cc nameserver records in .com zone

Nate Campi nate at wired.com
Wed Jan 23 07:10:59 UTC 2002


On Tue, Jan 22, 2002 at 10:42:35PM -0500, Matthew SAMS wrote:
> 
> I believe that all authoritative name servers
> in the .com domain must have glue records
> in the .com zone. That is, if the authoritative
> nameservers for foo.com are ns1.foo.com and
> ns2.foo.com, there must be two records in the
> .com zone for each of those nameservers. An A 
> record and an NS record. For example,
> 
> foo in ns ns1.foo.com.
> ns1.foo.com. in a 127.0.0.1
> 
> Please correct me if I'm wrong.

This is correct. If the gTLD nameservers (the servers for com, net and
org) delegate a domain to a nameserver that is in the com, net or org 
domains, a glue "A" record is needed. Otherwise the IP address for the 
nameserver being delegated *to* would never be known.

> So what happens when the authoritative nameservers
> for a domain are from a different parent tld.
> For example, the authoritative nameservers for
> foo.com are ns1.foo.ca and ns2.foo.ca.
> 
> Are only NS records required and the A record
> lookup will be forwarded to the .ca root servers?

Be careful with the term "root" servers. What you mean here is simply
the nameservers that are delegated the ca domain *from* the root servers.

> Perhaps forwarded is a poor choice of words but 
> it's the only one I can think of at this hour.

The term you're reaching for is "referred" - but you certainly grasp the
concept well. Ask a nameserver that has the cc domain delegated to it
from the roots who the nameservers are for campi.cc:

  $ dig campi.cc. ns @NS1.SEATTLE.US.NETDNS.com.
  
  ; <<>> DiG 9.2.0 <<>> campi.cc. ns @NS1.SEATTLE.US.NETDNS.com.
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2477
  ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
  
  ;; QUESTION SECTION:
  ;campi.cc.                      IN      NS
  
  ;; ANSWER SECTION:
  campi.cc.               3600    IN      NS      SKITZO.CAMPIN.NET.
  campi.cc.               3600    IN      NS      SCAMPI.CAMPIN.NET.
  
  ;; Query time: 23 msec
  ;; SERVER: 206.253.214.13#53(NS1.SEATTLE.US.NETDNS.com.)
  ;; WHEN: Tue Jan 22 22:46:01 2002
  ;; MSG SIZE  rcvd: 78
  
The above response contains no A records, since
NS1.SEATTLE.US.NETDNS.com has recursion disabled (not all the cc
nameservers are configured this way, though). The idea here is that a
querying nameserver will send a new query in order to resolve
skitzo.campin.net and scampi.campin.net. This may start at the root
nameservers, the gTLD nameservers, or even be served from the querying
server's cache, but will never actually go to skitzo or scampi. Asking
a nameserver for it's own IP addresses is a chicken and egg problem.
That's why glue A records are needed in the net zone for skitzo and
scampi.campin.net.

Contrast the glueless campi.cc delegation with the delegation of
campin.net from the gTLD nameservers:

  $ dig @E.GTLD-SERVERS.NET. campin.net. ns
  
  ; <<>> DiG 9.2.0 <<>> @E.GTLD-SERVERS.NET. campin.net. ns
  ;; global options:  printcmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13425
  ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
  
  ;; QUESTION SECTION:
  ;campin.net.                    IN      NS
  
  ;; ANSWER SECTION:
  campin.net.             172800  IN      NS      SKITZO.campin.net.
  campin.net.             172800  IN      NS      SCAMPI.campin.net.
  
  ;; ADDITIONAL SECTION:
  SKITZO.campin.net.      172800  IN      A       209.209.45.48
  SCAMPI.campin.net.      172800  IN      A       216.15.60.24
  
  ;; Query time: 12 msec
  ;; SERVER: 192.12.94.30#53(E.GTLD-SERVERS.NET.)
  ;; WHEN: Tue Jan 22 22:39:37 2002
  ;; MSG SIZE  rcvd: 102
  
This has the necessary glue, included with the lookup for the NS
records. This way no more queries are need to get the IPs of skitzo and
scampi.
-- 
Nate Campi | Terra Lycos DNS | WiReD UNIX Operations

"A computer scientist is someone who fixes things that aren't broken."



More information about the bind-users mailing list