[Smaug] (Linux ETC: scruz.org) Re: Domain updates for Smaug's scruz.org, which you own

Rick Moen rick at linuxmafia.com
Wed May 18 21:11:44 PDT 2011


----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----

Date: Wed, 18 May 2011 21:00:52 -0700
From: Rick Moen <rick at linuxmafia.com>
To: Crawford Rainwater <crawford.rainwater at linux-etc.com>
Subject: Re: (Linux ETC: scruz.org) Re: Domain updates for Smaug's
	scruz.org, which you own
Organization: If you lived here, you'd be $HOME already.

Quoting Crawford Rainwater (crawford.rainwater at linux-etc.com):

> Rick:
> I am getting that NS7.SCRUZ.ORG does not exist.  Could you verify that one?

Verified.  Thus:

 $ dig ns7.scruz.org @ns1.scruz.org +short

Here are the lines in the master zonefile:

 ; ns7 is aka ns.portalpotty.net, Max Baker's box
 ns7             IN      A

However, hold that thought about 'does not exist', because you're right,
but it's at a different level.  I'll get back to that in a moment.

> Also I see NS1.SCRUZ.ORG is still on the list.  Keep or remove it?

Keep!  That is the master nameserver.

Please find at the end the current master zonefile, which possibly will

About 'I am getting that NS7.SCRUZ.ORG. does not exist':  My guess is
that you're saying that the Domain Discover administrative interface is
telling you that when you attempt to reference it in the authoritative
roster.  If so, that is exactly the thing I was warning about in my
prior message.  Quoting:

   You may need to use a feature in the Domain Discover Web interface to
   'create' those nameservers (which makes glue records for them in the
   org. parent zone), before you're allowed to add them to the domain's
   authoritative roster.

A lot of people seem to stumble over that:  You go years in adding new
nameservers to authoritative rosters without problems, but then suddenly
the domain registrar's software balks at one and says you may not use it 
because it doesn't exist.   What gives?

Think about the process for delegating authority.  A nameserver
elsewhere on the Internet attempting to resolve names in the scruz.org.
domain first needs to find out what nameservers are authoritative for
that domain.  As the initial step in that process, it needs to know
where to get org. information, so it requests (and caches) from the root
nameservers the names and IPs of authoritative nameservers for org.
Armed with those, it asks one of the org. nameservers what the names
and IPs of authoritative servers for scruz.org. are.  

Where do the authoritative nameservers for org. get that information? 
Such a org. nameserver can't say 'I know, I'll ask org. for that',
because that would mean asking itself, an infinite regress problem.  To
get out of that paradox, TLD nameservers like the org. ones have 'glue
records':  For every second-level domain (SLD) like scruz.org., the TLD
(e.g., org.) nameservers keep in _its_ zone records 'NS' lines
identifying the names and IPs of the authoritative nameservers for all
SLDs within its bailiwick.  

The 'glue records' within the parent zone are what make any domain's
nameserver authoritative for its domain.  That is also the data shown as
'Name Server' lines when you do a whois.  This is _not_ the same as just
adding an NS line to the SLD's zonefile.  Those are different records,
existing at different levels of the DNS hierarchy:  The parent zone
(org. in this case) has glue 'NS' records.  The SLD zone (scruz.org., in
this case) has separate 'NS' records.

It is important that the two sets of records match.  Every time one
changes, one must change the other.

One changes the SLD 'NS' records via editing the zonefile on the master
nameserver, which in this case is ns1.scruz.org., my nameserver, better
known as ns1.linuxmafia.com. or as linuxmafia.com.  One changes the TLD 
(parent zone) 'NS' records covering the domain in question (in this
case, the 'NS' lines concerning scruz.org. at the nameservers for org.)
by editing the parent zone's zonefile.  Because the operators of TLDs 
cannot afford to let thee and me muck about using vi in org. (and other
TLD) zonefiles, instead they let us submit change requests via our
registrar, which are sent to the shared back-end registry via a set of
protocols called the Shared Registry System (SRS).  That typically
involves interacting with the registrar's Web pages.

And, as part of that mechanism, the SRS cannot allow you to add a new NS
line in your domain's parent zone until the FQDN in question has been
defined by an 'A' record within the parent (org., in this case) zone.
If someone has already used a given FQDN combination for an 'NS'
line within that TLD in the past, then such an 'A' record already
exists, and the registrar's interface won't object when you say 'Hey, 
please put an 'NS' line pointing to this FQDN in the org. zone for doing
DNS for domain scruz.org.'.  If nobody has done that before, however,
then the software is going to balk because it refuses to point an NS 
line to a nonexistent 'A' record.

What you need to do, in those cases, is find the registrar (Domain
Discover) subpage where you can 'create' a nameserver in its records,
prior to referencing it.  That's what I was trying to get across in my
earlier message.  And I'm _very_ sure that's the issue with
ns7.scruz.org., because it's never been defined or used before.

Here is an example, using my own domain linuxmafia.com.:

First, I need to look up where com.'s nameservers are:

$ dig -t ns com. +short

Now, I can ask any of those TLD nameservers what glue records ('NS'
type) it has in _its_ com. zonefile for SLD linuxmafia.com.:

$ dig -t ns linuxmafia.com. @a.gtld-servers.net. +nocmd +noquestion +nostats   
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20482
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6

linuxmafia.com.         172800  IN      NS      ns1.linuxmafia.com.
linuxmafia.com.         172800  IN      NS      ns.primate.net.
linuxmafia.com.         172800  IN      NS      ns1.thecoop.net.
linuxmafia.com.         172800  IN      NS      ns.tx.primate.net.
linuxmafia.com.         172800  IN      NS      ns3.linuxmafia.com.

ns1.linuxmafia.com.     172800  IN      A
ns.primate.net.         172800  IN      A
ns.primate.net.         172800  IN      AAAA    2001:470:1f00:ffff::6b7
ns1.thecoop.net.        172800  IN      A
ns.tx.primate.net.      172800  IN      A
ns3.linuxmafia.com.     172800  IN      A

Notice that the 'glue' response provides the IPs (the matching A and
IPv6 A = AAAA records) in addition to the NS lines, even though I asked 
only for the NS lines.  It is necessary for 'glue' to furnish this
additional data in order to avoid a chicken-and-egg problem for
in-domain names used for NS references, and also speeds DNS generally by
averting the need for querying nameservers to follow up 'NS' queries
with 'A' ones to get the IPs.  (Essentially, the need for the second
query is anticipated and met in advance.)

Now that I know that one of the authoritative servers is
ns1.linuxmafia.com. (IP, I can query _it_ to find out
what NS lines the zone itself serves, at the SLD level:

$ dig -t ns linuxmafia.com. @ns1.linuxmafia.com. +nocmd +noquestion +nostats 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49004
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2

linuxmafia.com.         86400   IN      NS      ns.tx.primate.net.
linuxmafia.com.         86400   IN      NS      ns.primate.net.
linuxmafia.com.         86400   IN      NS      ns1.linuxmafia.com.
linuxmafia.com.         86400   IN      NS      ns3.linuxmafia.com.
linuxmafia.com.         86400   IN      NS      ns1.thecoop.net.

ns1.linuxmafia.com.     86400   IN      A
ns3.linuxmafia.com.     86400   IN      A

The 'NS' lines are an exact match between the records at the TLD level
and the zone's own records at the SLD level.  _That_ is the way things
are supposed to be.

For comparison's sake, compare the mildly broken situation at scruz.org
that we're about to remedy:

First, ask what nameservers have org. TLD data:

$ dig -t ns org. +short

Now, ask the first (or any) of those what 'glue' NS data it currently
has in the org. zonefile for domain scruz.org.:

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

scruz.org.              86400   IN      NS      ns1.scruz.org.
scruz.org.              86400   IN      NS      ns1.svlug.org.

ns1.scruz.org.          86400   IN      A
ns1.svlug.org.          86400   IN      A

Now, ask one of _those_ what NS lines the zone itself serves, at the SLD

$ dig -t ns scruz.org. @ns1.scruz.org. +nocmd +noquestion +nostats 
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35925
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5

scruz.org.              86400   IN      NS      ns6.scruz.org.
scruz.org.              86400   IN      NS      ns3.scruz.org.
scruz.org.              86400   IN      NS      ns7.scruz.org.
scruz.org.              86400   IN      NS      ns1.svlug.org.
scruz.org.              86400   IN      NS      ns1.scruz.org.

ns1.scruz.org.          86400   IN      A
ns1.svlug.org.          86400   IN      A
ns3.scruz.org.          86400   IN      A
ns6.scruz.org.          86400   IN      A
ns7.scruz.org.          86400   IN      A

You'll notice that the difference is that the SLD has these, 
which the TLD (the org. zone edited via Domain Discover) doesn't:


I retained ns3.scruz.org. speculatively because it's the guy whose
nameserver is still working and its IP is unchanged, but he just swiched
off scruz.org nameservice, apparently.  I also added ns6.scruz.org.
speculatively, because it's the new IP of a nameserver that used to do
scruz.org nameservice, moved to a new IP, and shut off service for us.
He _may_ re-enable service now that I asked.  I also eliminated
ns4.scruz.org. because it's likely that its operator, one Paul Hall,
simply shut down nameservice and doesn't offer it any more, but I'll
find out if/when he writes back.

So, that's why I requested addition of ns7.scruz.org. and ns1.svlug.org.
immediately, and said I'd eventually follow up with request #2of2 when
three guys got back to me.

I hope that clarifies things.  If it's mysterious how to 'create' a
nameserver in Domain Discover, their staff can help you, I'm sure.

Here's the current zonefile at the master nameserver, ns1.scruz.org:

$TTL 86400
$ORIGIN scruz.ORG.
@       IN      SOA     ns1.scruz.ORG.     rick.deirdre.NET. (
                        2011051804              ; serial
                        10800                   ; refresh 3 hours
                        3600                    ; retry 1 hour
                        2419200                 ; expire 672 hours
                        86400                   ; negative TTL 24 hours
		IN	TXT	"v=spf1 a mx ~all"
		IN      A
                IN      MX      10      linuxmafia.COM.
		IN	NS	ns1.scruz.org.
;		IN	NS	ns2.scruz.org.
		IN	NS	ns3.scruz.org.
;		IN	NS	ns4.scruz.org.
;		IN	NS	ns5.scruz.org.
		IN	NS	ns6.scruz.org.
		IN	NS	ns7.scruz.org.
		IN	NS	ns1.svlug.org.
; ns1 is aka ns1.linuxmafia.com, Rick Moen's box
ns1             IN      A
; ns2 (obsolete) is aka ns1.phosphor.net, old IP of Eric Cain's box.
ns2		IN	A
; ns3 is aka ns.infiniteloopfilms.com, David A. Gatwood's box.
ns3		IN	A
; ns4 is Paul Hall's box
ns4		IN	A
; ns5 (obsolete) is aka ns.portalpotty.net, old IP of Max Baker's box.
ns5		IN	A
; ns6 is aka ns1.phosphor.net, Eric Cain's box.
ns6		IN	A
; ns7 is aka ns.portalpotty.net, Max Baker's box
ns7		IN	A
; In case it moves: "www" is aka smaug.got.net.
www		IN	A
ftp             IN	A
cvs		IN	CNAME	smaug-web.cvs.sourceforge.net.

----- End forwarded message -----

More information about the Smaug mailing list