[Smaug] Eric, David, Paul, and Mox: Problem at your nameservers

Rick Moen rick at linuxmafia.com
Thu May 19 17:33:59 PDT 2011


Quoting Eric Cain (ecain at phosphor.net):

> While it is beneficial to have the nameserver in the .org domain, it
> becomes a small administrative headache to remember "nsX.scruz.org" when
> we renumber. Not a big deal really. Just easy to overlook.

There's actually a minor DNS-performance advantage, which is why we
provide a org. name for all secondaries whose customary names aren't in
org.  The reason's a little subtle, but I'll explain.  

It has to do with glue records, again.  The short-but-cryptic
explanation is that a TLD (top-level domain) will keep and furnish glue
records for NS lines pointing to in-bailiwick names but never for NS
lines pointing to out-of-bailiwick names.

I'll unpack that.  

Sacramento Linux User Group owns saclug.org.  The parent zone for that
domain is of course org., which is where glue records for its
nameservice would have to live.  However, notice that both of its
authoritative nameservers are in 'net.', as follows:

$ whois saclug.org | grep 'Name Server'
Name Server:MARS.WEBAPPCABARET.NET
Name Server:VENUS.WEBAPPCABARET.NET
Name Server: 
[...]
$

Glue NS records being present in the parent zone is always A Very Good
Thing, because they permit the parent-zone nameservers to carry out this
one-transaction conversation:

remote nameserver:  What are saclug.org.'s NS entries?
org. nameserver:  mars.webappcabaret.net. and venus.webappcabaret.net., 
                  and, by the way, those are at IPs 174.36.254.80
                  and 174.36.254.80, respectively.[1]

...instead of this two-transaction conversation:

remote nameserver:  What are saclug.org.'s NS entries?
org. nameserver:  mars.webappcabaret.net. and venus.webappcabaret.net.
remote nameserver:  OK, then, what are the 'A' records for those?
org. nameserver:  174.36.254.80 and 174.36.254.80, respectively.

So, one query and one response, averting the need for a followup query
about the 'A' record.


Unfortunately, org.'s nameservers are prohibited by security
considerations from storing and using glue records outside its
'bailiwick' -- the set of domains over which it has authority.
org.'s nameservers have only *.org. within its bailiwick.  
The ones for com. and net. happen to be the same nameservers, so that's
a joint bailiwick.  However, org.'s nameservers cannot store and serve
glue pointing to *.net. names, or it would be vulnerable to abuse for 
DNS poisoning.

Thus, you query org.'s nameservers for saclug.org glue, and get... no glue.

(Find org.'s nameservers first, to determine where to ask:)

$ dig -t ns org. +short
a0.org.afilias-nst.info.
a2.org.afilias-nst.info.
b0.org.afilias-nst.org.
b2.org.afilias-nst.org.
c0.org.afilias-nst.info.
d0.org.afilias-nst.org.
$

(Now, ask for NS records for saclug.org in the parent zone:)

$ dig -t ns saclug.org. @a0.org.afilias-nst.info. +nocmd +noquestion
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14953
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0

;; AUTHORITY SECTION:
saclug.org.             86400   IN      NS      mars.webappcabaret.net.
saclug.org.             86400   IN      NS      venus.webappcabaret.net.

;; Query time: 173 msec
;; SERVER: 199.19.56.1#53(199.19.56.1)
;; WHEN: Thu May 19 17:24:31 2011
;; MSG SIZE  rcvd: 84
$ 

Notice that the reply provided the NS names, but did not also throw in
the 'A' answers along with the names -- which is what we mean when we
say 'glue records'.


By way of comparison, see the same data for svlug.org:

$ dig -t ns svlug.org. @a0.org.afilias-nst.info. +nocmd +noquestion
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50572
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4

;; AUTHORITY SECTION:
svlug.org.              86400   IN      NS      ns1.svlug.org.
svlug.org.              86400   IN      NS      ns3.svlug.org.
svlug.org.              86400   IN      NS      ns1.nylug.org.
svlug.org.              86400   IN      NS      ns2.svlug.org.

;; ADDITIONAL SECTION:
ns1.nylug.org.          86400   IN      A       66.114.81.152
ns1.svlug.org.          86400   IN      A       64.62.190.98
ns2.svlug.org.          86400   IN      A       198.144.194.12
ns3.svlug.org.          86400   IN      A       198.144.195.186

;; Query time: 174 msec
;; SERVER: 199.19.56.1#53(199.19.56.1)
;; WHEN: Thu May 19 17:26:17 2011
;; MSG SIZE  rcvd: 169
$

Each of the four NS lines returned is accompanied by a matching glue 'A'
record -- because those are in-bailiwick for org.'s nameservers.



Getting back to the recent mishaps:  I have a simple suggestion:  As a
secondary nameservice provider, I always inform _all_ of my primarys
if I re-IP my nameserver.  I always inform the relevant primary if I
drop service for a domain.

If you do that, it makes no difference whatsoever what A-record name
someone else uses for your nameserver, and nobody gets taken by
surprise.


[1] The eagle-eyed will notice that these are the same IP, which
practice (i.e., sleazing by with just a single nameserver, referred 
to in two different ways) is very close to the top among Things To Never
Do when doing DNS nameservice.  Oh well.




More information about the Smaug mailing list