[conspire] penlug DNS seems to be down...

Rick Moen rick at linuxmafia.com
Mon Dec 12 01:29:02 PST 2005

Quoting Peter Knaggs (peter.knaggs at gmail.com):

>    Being a mere DNS newbie, I followed Rick's
>    suggestion of using dnsreport to check the
>    penlug.org domain's nameservers
> http://www.dnsreport.com/tools/dnsreport.ch?domain=penlug.org

Now that joker.com's nameservice is back up, we can see how they do

The only significant problem is an error that's extremely common among
one-stop Internet providers: no glue records, because they're lazy with
choice of nameserver hostnames.  Result:  unnecessarily slow DNS

To explain that, I have to explain glue records.

When someone out on the Internet tries to connect to host
linuxmafia.com, he generates a burst of DNS queries:  The user's
nameserver needs to find out (1) what nameserver(s) to ask for all
"linuxmafia.com" name information, and then (2) asks one of those
nameservers the actual IP address for host linuxmafia.com.

To do the first step, the user's nameserver asks .COM's nameservers 
about the "linuxmafia.com" domain's "NS" (nameserver) records, like this
(snipping irrelevant stuff):

  ~ $ dig -t ns linuxmafia.com @k.gtld-servers.net

  linuxmafia.com.         172800  IN      NS      ns.on.primate.net.
  linuxmafia.com.         172800  IN      NS      ns.primate.net.
  linuxmafia.com.         172800  IN      NS      ns1.linuxmafia.com.
  linuxmafia.com.         172800  IN      NS      ns1.thecoop.net.
  linuxmafia.com.         172800  IN      NS      ns2.linuxmafia.com.

  ns.on.primate.net.      172800  IN      A
  ns.primate.net.         172800  IN      A
  ns1.linuxmafia.com.     172800  IN      A
  ns1.thecoop.net.        172800  IN      A
  ns2.linuxmafia.com.     172800  IN      A

(Please just take my word for it that "k.gtld-servers.net" is one of the
.COM top-level domian's nameservers.  I can explain, but would rather
skip that, here.)

The "ANSWER SECTION" lines give the literal answers to the posed question 
"What are the NS records for domain linuxmafia.com?" -- but please
notice _also_ the matching "ADDITIONAL SECTION" lines sent _along with_
that requested information.  That's the "glue" -- sent in anticipation of,
and in answer to, the user's nameserver's obvious _next_ question.

That is, notice that each "NS" line says, in effect, "Here's a
_hostname_ of an 'authoritative' nameserver machine you can ask about
name information within the 'linuxmafia.com' domain."  But the querying
nameserver uses IP addresses to open remote connections, so it thus has
to look up the _IP_ of one of those nameservers, before it can ask
questions.  That would be a second DNS lookup.

Sending the "glue" information -- the IP addresses corresponding to each
of those NS records -- avoids the querying nameserver's need to ask the
"What's the IP for that nameserver hostname" question immediately after
its "What's the nameserver hostname?" question, by anticipating the
second question and sending both answers at the same time.

And, in penlug.org's case, the parent .ORG zone's nameservers aren't
sending glue information.  Imagine, again, that a user's nameserver (a "querying
nameserver") wants to look up penlug.org names, and therefore asks .ORG
where to find the domains nameservers.   Again, please just take my word
that nameserver "tld6.ultradns.co.uk" is authoritative for .ORG

  ~ $ dig -t ns penlug.org @tld6.ultradns.co.uk

  penlug.org.             86400   IN      NS      c.ns.joker.com.
  penlug.org.             86400   IN      NS      b.ns.joker.com.
  penlug.org.             86400   IN      NS      a.ns.joker.com.

The .ORG namservers didn't send any "A" (glue) records for nameservers
{c,b,a}.ns.joker.com -- just the hostnames.  Therefore, the querying
nameserver has to turn around and ask the .COM hierarchy what the IP 
addresses of _those_ names are, before it can go further:

  ~ $ dig -t a c.ns.joker.com @k.gtld-servers.net

  c.ns.joker.com.         172800  IN      A

Thus, two queries required instead of one, just to find the nameservers 
-- ergo, unnecessarily slow nameservice.

And, if you're still with me, you might wonder _why_ .ORG's nameservers
aren't sending glue information for c.ns.joker.com and its two brothers.
Simple:  They're in a name hierarchy that .ORG's nameservers don't know
anything about, namely .COM .  That's really all there is to it.

.ORG's nameservers have no _authority_ in that namespace -- and it's
really important, in order to prevent "cache poisoning" (injection of
fraudulent name information into nameservers), that DNS software reject
that sort of "out-of-bailiwick" responses, including glue records.
Thus, joker.com's .COM-based nameserver names simply _can't_ be used in
an .ORG domain's glue records:  They wouldn't be valid.

So, you might ask, why is joker.com, a supposedly professional service
provider, specifying .COM nameserver names inside an .ORG domain --
given that it's an obvious and avoidable error?  Because they're being
lazy and, well, unprofessional.

What they _should_ have done -- and this would have taken them maybe
twenty lines of Perl -- is noticed the problem, and created "A"
(IP-lookup) records pointing to their same nameserver IP addresses,
except using new hostnames ns1.penlug.org, ns2.penlug.org, and
ns3.penlug.org.  And then use _those_ in the parent .ORG records for
penlug.org, in place of that "c.ns.joker.com" name and the other two.  

Doing that would have allowed proper glue information to flow out of
.ORG, and everything would have been just a wee bit faster and more
reliable.  joker.com's doing that would honestly have been _no harder_
for them -- but they didn't bother.

Judging by joker.com's recent downtime, they probably have a lot bigger
problems, but I just thought I'd mention that glue records are one of
those things that you can use to distinguish those who bother to do
things properly from those who don't, and why.

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

More information about the conspire mailing list