[sf-lug] sf-lug.com web site accessibility

[Rick Moen]

Quoting jim (jim at well.com):

>    dig ns1.sf-lug.com shows an internet A record of 
> 208.96.15.252 (this dns server is on the box itself). 

In case my point was not clear, the root cause is that the nameserver
daemon in question (BIND9 or whatever) on ns1.sf-lug.com AKA
www.svlug.com AKA IP address 208.96.15.252 appears to be either 
not running at all or (for some reason) not responding to queries.

My guess:  BIND9 isn't running.  (Could be other things, e.g., hung
processes, firewalling error, etc., but that'd be my bet.)

I mostly wanted to teach a few folks how to do nameserver debugging:
You follow the chain from looking up the authoritative servers in the
whois records, and then use "dig" to send _specifically_ to them 
("@" qualifier) queries about what they know.  Querying for type = soa
within a zone is often useful because SOA records include zonefile S/N
values.  If not all the authoritative servers have the same S/N, then
that's often the smoking gun, as you can often spot quickly which slave
is either not bothering to consult the master or being refused at the
master, and then can use other methods to figure out why.

If you run one or more of the nameservers, then it's also extremely 
handy to watch new additions to /var/log/messages.

Also, at the command line of any slave nameserver, you should be able to 
similate the client end of a zone transfer operation by typing
"dig  -t axfr  zonename  @master-ip" .