[sf-lug] sf-lug.com web site accessibility
rick at linuxmafia.com
Fri Feb 27 18:52:09 PST 2009
Quoting jim (jim at well.com):
> dig ns1.sf-lug.com shows an internet A record of
> 184.108.40.206 (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 220.127.116.11 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" .
More information about the sf-lug