[BALUG-Admin] (forw) Re: [sf-lug] balug.org DNS (was: sf-lug.com web site accessibility)

[Rick Moen]

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

Date: Sat, 28 Feb 2009 16:56:46 -0800
From: Rick Moen <rick@linuxmafia.com>
To: sf-lug@linuxmafia.com
Subject: Re: [sf-lug] balug.org DNS (was: sf-lug.com web site accessibility)

Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

> No changes regarding balug.org DNS that I'm aware of ... at least that
> are or would be problematic.

As an additional exercise, I'll now show you how I might check out
whether balug.org DNS is OK.  This is something _anyone_ can do, 
even MS-Windows sufferers.  (There's a free-of-charge download of 
"whois" and "dig" programs in MS-Windows executable format on the Web.)

In my former e-mail, I was launching shell commands inside of vi, while 
composing my mailing list reply in that editor -- indicating so doing by
typing ":r! " at the beginning of a line to show a vi shell escape.  In
the following, for clarity's sake, I'll just show "$" to indicate a bash
prompt, OK?

First, we want to identify balug.org's _authoritative_ nameservers. 
Anyone can set up a DNS nameserver that claims to be publishing reliable
balug.org DNS information, but the only ones people will _consult_ are
the ones the parent zone -- that would be .org in the case of balug.org
-- identifies as having authority over balug.org.  

There are two ways to do this.  One is to ask the shared "WHOIS"
registries that all of the domain registrars communicate with and share.
One can do that with the "whois" command, looking specifically for the
lines starting with "Name Server":

$ whois balug.org | grep "Name Server"
Name Server:NS1.DREAMHOST.COM
Name Server:NS2.DREAMHOST.COM
Name Server:NS3.DREAMHOST.COM
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:


The other way is to ask the nameservers for "org." directly -- which
makes this as two-step process, because you first have to find one of
the six nameservers that serve up "org."'s information, and then ask one
of them "What are the nameservers for balug.org?"  The best
tool, as for just about any other DNS query, is "dig":

$ dig  -t ns  org.  +short  #What are org.'s nameservers?
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 that you have the list of org nameservers, you can ask _them_ about
balug.org's nameservers.  I had to do a little fiddling, because it
turns out that the people who now operate org aren't returning exactly
correct results any more.  (They should be giving data in the Answer
Section, not just in the Authority Section that is omitted if you query
using the "+short" flag.)

$ dig  -t ns  balug.org  @a0.org.afilias-nst.info. 
[...]
;; AUTHORITY SECTION:
balug.org.		86400	IN	NS	ns3.dreamhost.com.
balug.org.		86400	IN	NS	ns2.dreamhost.com.
balug.org.		86400	IN	NS	ns1.dreamhost.com.


Please note:  The _order_ in which authoritative nameservers (or, for
that matter, "NS" lines in zonefiles) are listed is _not_ significant.  
You have absolutely no idea which server will get used/consulted during 
normal DNS operations.  dig's "@", by contrast, allows you to send a
query directly to a specific nameserver, but DNS generally goes first to
wherever that machine's DNS gets shoveled off to, eventually getting to
data originated some time back by an unpredictably selected
authoritative server and then cached for some period of time (with the
result that you can't predict where it came from, and it might be
obsolete).

You might be thinking, "Hey, wait, what about the fact that one of the
authoritative servers for the zone is the master, and all others are
slaves?"  Master/slave relationship for zonefiles has nothing to do with
_serving_ of DNS.  It solely concerns which of the authoritative servers 
publishes the master copy to the others -- and actually isn't essential
to DNS at all, as there are other ways of propagating zone information
(e.g., having several machines in dispersed locations all drawing data
from a single database, as back-end data).


Anyway, now that we know what three machines have authority for
balug.org we ask them for the SOA record, which includes the zonefile
S/N:

$ dig  -t soa  balug.org  @ns1.dreamhost.com  +short
ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400
$ dig  -t soa  balug.org  @ns2.dreamhost.com  +short
ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400
$ dig  -t soa  balug.org  @ns3.dreamhost.com  +short
ns1.dreamhost.com. hostmaster.dreamhost.com. 2008070600 16991 1800 1814400 14400

All of them report zonefile serial number "2008070600", which by
convention means that it was last updated on 2008 07 06 (July 6, 2008)
and was update #00 on that day.   The fact that the three nameservers
all report the _same_ S/N is encouraging, as it makes it very likely
that they are in proper communication.

Incidentally, one of the other SOA subfields, "ns1.dreamhost.com", is 
supposed to be where you declare the location of the master zonefile
copy.  However, the field value is strictly informational, and often 
(for many zones) lacks correct and useful data.  (As noted above, the 
very notion that there's necessarily a master server for each zone
doesn't necessarily apply.)

Last, there's some merit to actually asking each of the nameservers
about some record that's genuinely of interest, such as "www.balug.org"
or "lists.balug.org":

$ dig  www.balug.org  @ns1.dreamhost.com  +short
208.113.160.236
$ dig  www.balug.org  @ns2.dreamhost.com  +short
;; Truncated, retrying in TCP mode.
208.113.160.236
$ dig  www.balug.org  @ns3.dreamhost.com  +short
208.113.160.236

Notice that Dreamhost is being a bit of a screwup, concerning
"ns2.dreamhost.com":  It's not giving useful, complete responses to
UDP-based queries -- e.g., fragmenting them across multiple packets,
which UDP doesn't support -- so, dig went back and tried again using a
TCP-type query, which worked.

Trying again a moment later worked without switching to TCP, so it was
probably a temporary glitch.  However, this underscores why it's
important that you _not_ firewall off 53/tcp, when you're operating a
nameserver.

In an ideal world, I'd be in a position to know whether
"208.113.160.236" is really the correct IP for www.balug.org, which I'm
not, but someone actually running the domain (and especially its DNS) no
doubt would.

One last point about the SOA record:  "hostmaster.dreamhost.com." is
supposed to indicate the e-mail address of the administrative person
responsible for the contents of the master zonefile, expressed with the
"@" turned into a period on account of an antique software limitation
that was in place when the RFC was written.  So, the e-mail address is
"hostmaster@dreamhost.com".

It may or may not be in BALUG's interest for (theoretical) queries about
the zone's contents to go to Dreamhost's DNS administrator.  Does BALUG 
edit its own DNS?  If it does, it might wish to put someone else's
e-mail address there.

(Note:  However, hardly anyone ever uses that data, which is likewise an
informational record only, and often doesn't have a useful e-mail
address at all.  Most often, people will contact the Administrative,
Technical, or Registrant contacts from the WHOIS record, or just go
straight for the webmaster as indicated on the Web site (if
accessible).)


_______________________________________________
sf-lug mailing list
sf-lug@linuxmafia.com
http://linuxmafia.com/mailman/listinfo/sf-lug

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