[Smaug] scruz.org domain records and DNS: fixed

[Rick Moen]

With the kind help of Crawford Rainwater, our friend in Colorado who 
has personally underwritten Smaug's domain registration (for SCRUZ.ORG)
since December 2003, I've banged our DNS fully into shape:  Updates at
our registrar went through yesterday.  I thought y'all might be
interested in details:


After removing a few nameservers that had, somewhat disappointingly, 
stopped doing secondary for us without notice[1], we were down to these
three:

NS1.LINUXMAFIA.COM at 198.144.195.186 (Rick Moen's box)
NS1.PHOSPHOR.NET at 207.7.137.130 (Eric Cain's box)
NS.INFINITELOOPFILMS.COM at 68.165.1.187 (David A. Gatwood's box)

After a little work at Crawford's end with domain registrar
DomainDiscover, all our records were functional and consistent _both_ at
the primary scruz.org zonefile (on NS1.LINUXMAFIA.COM) and in our
parent .ORG domain's records, which Crawford adjusts at DomainDiscover.

As an aside:  The _biggest_ area of DNS errors by far, generally, is
forgetting to adjust the parent-zone (i.e., registrar) nameserver
records when you change those in your zonefile.


There remained one problem:  No glue records at the parent .ORG zone.
"What are glue records, and why should I care?", I hear you ask.  I'll
explain:

Consider the situation of someone out on the Net attempting to browse 
our Web site.  The user's Web browser wants to look up "www.scruz.org".
To do so, it must first find out where scruz.org's nameservers are.
so it hands off the request to the machine's DNS resolver library.
(In Linux, this is code borrowed from BIND8 that's been bundled into
glibc.)  The resolver library looks up (i.e., via /etc/resolv.conf
on Linux) a nearby caching nameserver, and passes the "Where are
scruz.org's nameserver, i.e., its NS records?" query to there.


Let's say the caching nameserver doesn't know, yet.  So, it has to ask
.ORG's (our parent zone's) nameservers.  If necessary, it looks _those_
nameservers up via the root nameservers, but probably already has them 
in cache, and let's say it decides to ask TLD6.ULTRADNS.CO.UK.[2]

It asks TLD6.ULTRADNS.CO.UK for the "NS" records of domain scruz.org, 
and hears back some return values that equate to 

NS1.LINUXMAFIA.COM
NS1.PHOSPHOR.NET
NS.INFINITELOOPFILMS.COM

...but _not_ their IP addresses (which it needs, to actual talk to
them).  So, the caching nameserver is obliged to come right back and
say, "OK, TLD6.ULTRADNS.CO.UK, what are the "A" records (IP addresses)
for those three names?"

The designers of DNS decided that routinely making such follow-up
queries was silly:  Since the querying nameserver is going to _need_ 
the matching "A" information every time it asks for an NS record, that
extra information might as well get sent along, the first time.


That's what glue records are.  It's the "A" (IP address) information 
that corresponds to NS names, sent back along with the latter
automatically:  Glue records make DNS faster, by averting the need for 
those follow-up "A" queries.  (In the special case of a nameserver whose
own name is in-zone, they also are necessary to avert a chicken-and-egg
problem where you cannot find ns1.foo.com in order to resolve foo.com
names because need to be able resolve foo.com names generically before
you can resolve ns1.foo.com.)

And we didn't have glue records.  Upon reflection, I realised that this
was because .ORG's nameservers _could not_ store glue records for .COM
and .NET hostnames, because .ORG's nameservers _lack authority_ over
those other namespaces.  This is called the "out-of-bailiwick" problem:
Glue names from outside a nameserver's authority are invalid and cannot
be permitted, because they could be used by malign nameservers (or
intruders who've compromised nameservers) to do "cache poisoning" on 
other nameservers.  (Cache poisoning is very bad, letting bad guys
effectively redirect entire domains' traffic to elsewhere.)


Many people ignore glue problems.  Either their glue records got created
automatically in their domains' parent zones (e.g., because all
nameservers are in .NET/.COM and so is the domain itself), or this gets
flubbed entirely and they never notice.  In the former case, many if not
most people _completely fail_ to realise that it needs fixing whenever
namservers' NS or A records change -- because they aren't even aware of
those records in the parent zone, in the first place.

If you _do_ notice a glue problem (as I did), and cannot fix it the
direct way because of bailiwick issues, you have to do an end-run, by
defining new, in-bailiwick names for affected nameservers and using
those, instead.  And that's what we did.  For each of the three, we
invented names _within scruz.org_, pointed to the same IP as before.
Here's our current zonefile at the master nameserver:


$TTL 86400
$ORIGIN scruz.ORG.
@       IN      SOA     ns1.scruz.ORG.     rick.deirdre.NET. (
                        2005112304              ; serial
                        10800                   ; refresh 3 hours
                        3600                    ; retry 1 hour
                        2419200                 ; expire 672 hours
                        86400                   ; minimum 24 hours
                        )
;
		IN	TXT	"v=spf1 a mx ~all"
		IN      A       198.144.195.186
                IN      MX      10      linuxmafia.COM.
		IN	NS	ns1.scruz.org.
		IN	NS	ns2.scruz.org.
		IN	NS	ns3.scruz.org.
; ns1 is aka ns1.linuxmafia.com, Rick Moen's box
ns1             IN      A       198.144.195.186
; ns2 is aka ns1.phosphor.net, Eric Cain's box.
ns2		IN	A	207.7.137.130
; ns3 is aka ns.infiniteloopfilms.com, David A. Gatwood's box.
ns3		IN	A	68.165.1.187
www		IN	CNAME	smaug.got.net.
ftp             IN	CNAME	smaug.got.net.
cvs		IN	CNAME	cvs.sourceforge.net.



Notice the three replacement "NS" lines.  Notice that each one also has
a corresponding "A" (forward-lookup) record, to go with it.  (As an
additional detail, notice that the name of the master nameserver in the
SOA record also had to change.)

The last detail, the one that Crawford recently took care of for us, was 
changing the NS records for our domain at DomainDiscover (and thus
editing our records in the parent .ORG zonefile), to use the new names
and in doing so, finally, create the desired glue records.

Getting back to our example of the caching nameserver, it would send
this "Where are scruz.org's nameservers?" to .ORG's TLD6.ULTRADNS.CO.UK
nameserver:

[rick at linuxmafia]
~ $ dig -t ns scruz.org @TLD6.ULTRADNS.CO.UK

; <<>> DiG 9.3.1 <<>> -t ns scruz.org @TLD6.ULTRADNS.CO.UK
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46077
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;scruz.org.                     IN      NS

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

;; ADDITIONAL SECTION:
ns3.scruz.org.          86400   IN      A       68.165.1.187
ns2.scruz.org.          86400   IN      A       207.7.137.130
ns1.scruz.org.          86400   IN      A       198.144.195.186

;; Query time: 62 msec
;; SERVER: 198.133.199.11#53(198.133.199.11)
;; WHEN: Wed Nov 30 13:16:56 2005
;; MSG SIZE  rcvd: 129

[rick at linuxmafia]
~ $ 

This confirms the results of my and Crawford's fixes.  Notice the
"AUTHORITY SECTION" bit, which has the (authoritative) answer, _and_ the
"ADDITIONAL SECTION" bit, which consists of matching glue records -- the
answer to two questions for the price of one.

Armed with this information, the caching nameserver can now ask any of
scruz.org's authoritative nameservers (now that it knows how to reach
them) what IP address "www.scruz.org" is at.


My thanks again to Crawford Rainwater, for his help.

If people have any interest, I can point out how badly other local 
Linux groups' DNS / domain records are screwed up, in comparison.  ;->


[1] These were David A. Gatwood's NS.GATWOOD.NET and NS.SONGCUE.COM, and 
Graham Freeman's NS1.CALTEG.ORG.  I now notice that NS.SONGCUE.COM is 
back online, but the other two _still_ don't even respond to ping, any
more.  I'm just now sending notes to their owners, thanking them for
past nameservice from those hosts, advising them of the changes, etc.

[2] http://www.iana.org/root-whois/org.htm

-- 
Cheers,             
Rick Moen                 "Anger makes dull men witty, but it keeps them poor."
rick at linuxmafia.com                                   -- Elizabeth Tudor