[sf-lug] DNS, testing/troubleshooting ... (Re: Looks great, thanks! Re: linuxmafia.com/svlug.org DNS slaves for sf-lug.{com, org}! :-))

[Michael Paoli]

Rick,

Hoping you don't mind that I take some of this on-list.  :-)

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: Looks great, thanks! Re: linuxmafia.com/svlug.org DNS  
> slaves for sf-lug.{com,org}!  :-)
> Date: Mon, 20 Jul 2015 23:43:00 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

NSD ...
> (http://linuxmafia.com/faq/Network_Other/dns-servers.html#nsd), a
> wonderful -- fast, small, secure -- authoritative-only DNS daemon
> from the people who run the .nl TLD.

Yes, you'd mentioned earlier - an excellent alternative to BIND.
I think one of the few reasons/excuses SF-LUG (and likewise parts of
BALUG) have BIND (bind9) is being used there, is more Linux(/Unix)
sysadmins are more familiar with BIND than NSD or other DNS server
software.  Not exactly a great reason to use BIND ... but certainly a
factor of consideration.  And thanks too for all the great DNS & related
information you provide (on your web site, on lists, etc.).

>> ... and now for upstream authority bits ...
>> $ dig -t ns sf-lug.com. +trace | sed -ne '/^sf-lug/,/;;

Actually, slightly more complete context, I'd done:
$ dig -t ns sf-lug.com. +trace | sed -ne '/^sf-lug/,/;;  
Received/{p;/;; Received/q;}'

> I usually just query for the name of one of the parent zone's
> authoritative nameservers and then query it for the NS RRs of interest
> via a second 'dig', but just using the +trace option is both logical and
> less typing / faster.

Ah, well, but ... I often do what you'd suggested, rather than use
+trace.  Actually, *not* using +trace certainly has its advantages -
notably not unnecessarily hitting root nameservers, etc. with traffic.
Had I been dealing with or suspecting an upstream DNS problem at/near
root servers, +trace probably would've been more justified, but that
having not been the scenario here, ... probably slightly better to skip
the use of trace.  Let's see ... what I might commonly do in such
scenario (looking up authority records just upstream of the domain),
would be something like this:
$ (tld=com; dig @$(dig -t ns "$tld". +short | head -n 1) -t ns  
sf-lug."$tld". +noall +authority +norecurse) | grep '^[^;]'
sf-lug.com.             172800  IN      NS      ns1.linuxmafia.com.
sf-lug.com.             172800  IN      NS      ns.primate.net.
sf-lug.com.             172800  IN      NS      ns1.svlug.org.
sf-lug.com.             172800  IN      NS      ns.tx.primate.net.
sf-lug.com.             172800  IN      NS      ns1.sf-lug.com.
$

That's probably a slightly better "optimized" command sequence ... for
the scenario involved ... and if one is optimizing for getting the
desired information while minimizing unneeded/excess traffic (it likely
even gets the "$tld" ns records from cache, rather than getting those as
authority from root servers and then from "$tld" server) and ... not
(quite) optimizing for shortest bit of typing (it's only slightly longer
... but it is also logically slightly easier to compose for the desired
information).  Again, however, had I been troubleshooting a suspected
issue at/near root servers, or needing/wanting to confirm those bits on
down through their delegation, then yes, the +trace bit I used probably
would've been the better choice.  But either way gets the desired info
on this - mostly slight question of optimizing for what particularly.

Random ... I wish dig(1) had an option to turn off *all* its commenting.
In many case I *just* want the data, and nothing else.  It does have
+nocomment, but that doesn't (quite) suffice.  The +short option is
handy, but that's often *too* short for what I want - often I also want
the TTL values - and may also prefer the data in same format as it might
appear in a zone file (to be less ambiguous, etc.).

And ... never hurts to (re)read the man page.  :-)  While I don't find
any option that would do precisely that, I do find a nice handy option
I could've used for some of the DNS ns checks, notably +nnsearch:

            ... Recursion is automatically disabled when the
            +nssearch or +trace query options are used.

        +[no]nssearch
            When this option is set, dig attempts to find the authoritative
            name servers for the zone containing the name being looked up and
            display the SOA record that each name server has for the zone.

$ dig +nssearch sf-lug.com.
SOA ns1.sf-lug.com. jim.well.com. 2015072000 10800 3600 1209600 10800  
from server 198.144.194.12 in 14 ms.
SOA ns1.sf-lug.com. jim.well.com. 2015072000 10800 3600 1209600 10800  
from server 208.96.15.252 in 16 ms.
SOA ns1.sf-lug.com. jim.well.com. 2015072000 10800 3600 1209600 10800  
from server 64.62.190.98 in 19 ms.
SOA ns1.sf-lug.com. jim.well.com. 2015072000 10800 3600 1209600 10800  
from server 72.249.38.88 in 56 ms.
SOA ns1.sf-lug.com. jim.well.com. 2015072000 10800 3600 1209600 10800  
from server 198.144.195.186 in 2024 ms.
;; connection timed out; no servers could be reached
$ dig +nssearch sf-lug.org.
SOA ns1.sf-lug.org. jim.well.com. 113020527 10800 3600 1209600 3600  
from server 64.62.190.98 in 14 ms.
SOA ns1.sf-lug.org. jim.well.com. 113020527 10800 3600 1209600 3600  
from server 198.144.194.12 in 15 ms.
SOA ns1.sf-lug.org. jim.well.com. 113020527 10800 3600 1209600 3600  
from server 208.96.15.252 in 23 ms.
SOA ns1.sf-lug.org. jim.well.com. 113020527 10800 3600 1209600 3600  
from server 72.249.38.88 in 60 ms.
SOA ns1.sf-lug.org. jim.well.com. 113020527 10800 3600 1209600 3600  
from server 198.144.195.186 in 393 ms.
;; connection timed out; no servers could be reached
$

Hmmm...
;; connection timed out; no servers could be reached
I'll likely investigate further if that persists (I have guess(es) as to
what it may be).  Perhaps someone *besides* myself or Rick Moen would
first like to take a stab at it and determine why it's indicating
;; connection timed out; no servers could be reached
and what is or may (presumably) be awry.
Some random data points which may and/or may not be relevant (leaving it
as an exercise at least for now):
I noticed the two dig(1) commands exited with a non-zero exit value.
Changes may soon be afoot for DNS master server(s) for sf-lug.com.
and/or sf-lug.org.