[sf-lug] sf-lug.{org,com} DNS

[Michael Paoli]

More comments/updates in-line:

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: Re: [sf-lug] sf-lug.{org,com} DNS (and whois, etc.)
> Date: Fri, 10 Jul 2015 04:45:03 -0700

> My comments/thanks in-line:
>
>> From: "Rick Moen" <rick at linuxmafia.com>
>> Subject: Re: [sf-lug] sf-lug.{org,com} & Network Solutions / Web.com
>> Date: Fri, 10 Jul 2015 00:44:47 -0700
>
>> I did a quick check on the contents of the zonefiles, verifying that all
>> nameservers respond, that they give the same answers, that there are no
>> stealth or lame nameservers, that all nameservers accept TCP (and not
>> just UDP) queries, that the NS list in the served zone matches the NS list
>> in the parent zone, that all nameservers are (now) authoritative, that
>> none of the nameservers accept recursive queries from the public (which
>> is bad security practice), and that the SOA values are reasonable.
>
> Ah, yes, thanks for those additional checks (I'm sure I checked *much*
> earlier, but hadn't checked recently).
>
>> For sf-lug.com, the SOA RETRY and REFRESH values are both 3600, which is
>> wrong.  RETRY needs to be less than or equal to half the REFRESH.`
>>
>> For sf-lug.org, the SOA EXPIRE value is 604800.  RFC1912 suggests a
>> value between 1209600 to 2419200.
>
> Nice catch!  Yep, I ought get around to adjusting those.  Not sure where
> those non-optimal values may have snuck in from ... some of them I may
> have just carried forward from earlier values in DNS for those zones.
>
>> Those are minor problems at worst (though they should be fixed).

And tweaking those SOA values (and verifying), should be significantly
better now:
$ (for domain in sf-lug.org. sf-lug.com.; do for ns in $(dig -t NS  
"$domain" +short); do echo "$ns $domain": $(dig @"$ns" -t SOA  
"$domain" +short); done; done)
ns.tx.primate.net. sf-lug.org.: ns1.sf-lug.org. jim.well.com.  
113020526 10800 3600 1209600 3600
ns1.sf-lug.org. sf-lug.org.: ns1.sf-lug.org. jim.well.com. 113020526  
10800 3600 1209600 3600
ns.primate.net. sf-lug.org.: ns1.sf-lug.org. jim.well.com. 113020526  
10800 3600 1209600 3600
ns.tx.primate.net. sf-lug.com.: ns1.sf-lug.com. jim.well.com.  
2015071400 10800 3600 1209600 10800
ns.primate.net. sf-lug.com.: ns1.sf-lug.com. jim.well.com. 2015071400  
10800 3600 1209600 10800
ns1.sf-lug.com. sf-lug.com.: ns1.sf-lug.com. jim.well.com. 2015071400  
10800 3600 1209600 10800
$

And, as for zone serial, I mistakenly thought sf-lug.org was using seconds
since the (Unix) epoch - but that's not the case.  Typically (a) most
recommended format is:
YYYYMMDDnn
Which allows up to 100 distinct sets of zone data in any given day.  But
there are also other conventions, e.g. seconds since the (Unix) epoch (that's
also commonly used for dynamic DNS, and is less ambiguous about when the zone
was presumably updated - but not as human-friendly for reading/updating).
There are other schemes/possibilities, as long as one stays within what
DNS allows and the issues regarding updates and how a zone serial number
is determined to be "larger"/newer - that's covered in detail on
RFC-1982 http://www.rfc-editor.org/rfc/rfc1982.txt
Also, DNS serial numbers are only 32 bits (regardless of your operating
system and DNS software, the data field that holds the serial number in
the DNS communications is only 32 bits wide).
So ... one can use:
YYYYMMDDnn
but one can't use:
YYYYMMDDnnn
nor
YYYYMMDDHHMM
etc.
Why?  Only 32 bits allowed.
$ echo  
'2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2-1' | bc
4294967295
$
That's as big as it gets.  Put in something larger and it will either
fail, or gives some possibly quite unexpected result.  (once upon a
time I saw some old DNS software, that given value larger than
4294967295, would silently interpret and serve that up modified to whatever
decimal integer was in the zone file, mod 4294967296).

So ... what scheme is that 113020526 zone serial number?  I mistakenly was
earlier thinking it was seconds since the (Unix) epoch.  But no, it's about
a digit short for that.  It's thus far continuation from what was present
earlier when DNS for that domain was provided by a hosting provider and we
had no real control over the zone serial numbers (other than changing the
data would guarantee it would increase it).  I'll probably eventually get
the two domains using the same schemes for zone serial numbers - but takes
a wee bit of care and time to do that properly, and in the meantime it's
not a problem.  Some other domains I administer DNS on are using seconds
since the (Unix) epoch ... but those also have nice clear comments in
the master zone files - and probably even handy commented out bits of
program handy for generating those, and converting to more human readable
time data - but alas, that's not the case for sf-lug.org. - it's just
"inherited" a continuation of what a service/hosting provider had been
using for the zone.  Some of that earlier stuff (including 113020522 zone
serial number from hosting provider at that time can be seen here:
http://linuxmafia.com/pipermail/sf-lug/2015q1/010716.html
)

> And yes, as always, excellent points.  Hopefully we'll get most or all of
> that cleaned up and set as it should be (or at least much closer to how
> it should be).