[sf-lug] -->ON-LIST minorish DNS fixes/cleanup: Re: Correct address for ns1.sf-lug.org? ...

[Michael Paoli]

(and ... back onto list)

> From: "John Strazzarino" <jstrazzarino at gmail.com>
> Subject: Re: [sf-lug] -->ON-LIST minorish DNS fixes/cleanup: Re:  
> Correct address for  ns1.sf-lug.org? ...
> Date: Sun, 9 Jan 2022 11:12:52 -0800

> Thanks for all the work you do for the website and our club.
>
> However, I am totally in the dark about the need for all to know.   
> Can you elaborate?

"need"?  Not much "need"s be on list.  Mostly for those that may wish to
know, be informed, and/or have more opportunity to learn.
There's probably close to nothing that "need"s or "has" to be on
the list ... but then again, what's the list for?  :-)
http://www.catb.org/~esr/faqs/smart-questions.html#noprivate

Elaborate ... well, in brief(ish),

Al had done some improved DNS checking, found an error/inconsistency,
and informed myself (and CCed Rick).  After having reviewed and gone
through the correction of that, I posted summary to the list - and
including a bit more background information (including links).

There were two items:

Most notably there was a discrepancy in nameserver (DNS server) related
records, not in the NS (NameServer) records themselves, but in related
AAAA ("quad A" - IPv6 IP address) records.
The authority and authoritative matched up on NS records.
Authority is essentially what the parent does - delegating to
(generally another) nameserver.  The authoritative - that on the
delegated to nameserver(s) actually takes precedence,
however that needs be found via the authority, so both are
important - and they should be consistent.
Essentially authority mostly delegates to authoritative and
authoritative is from whence the final definitive answer is obtained.
That part was okay for the NS records themselves.  However, for the NS
records, they'll often have associated A (IPv4 IP Address(es)) and/or
AAAA records.  In the case of the AAAA records, there was an error.
Notably incorrect information in the "glue" record.
And ... what's a glue record ("additional")?
That's what the delegating authority nameserver must also make
available to break what would otherwise be a recursion/loop problem.
E.g. let's say we have ... well, let's use bit of the actual,
domain: sflug.org. (. itself would be the root domain,
having a trailing . on the end makes it absolute relative to the
root - removing any ambiguity.  In any case, best to generally
use the complete fully qualified domain names, to generally
remove any ambiguity ... with or without trailing . on end.
But note that, e.g. in browser with HTTPS, generally won't work
with that trailing . on the end (as such names generally won't
properly match with the certificate), however more generally
one can typically include that trailing . - notably for DNS).
Note also that sflug.org. is a non-canonical domain for SF-LUG,
basically just a nice to additionally have, but not the
canonical/main/primary - which is sf-lug.org.  In any case ...
So, parent domain, org. also has nameservers.
And it, as delegating authority, gives NS authority records.
Here, I'd earlier shown just the names of the nameservers for org.:
>>>>> $ dig +short org. NS
>>>>> b2.org.afilias-nst.org.
>>>>> b0.org.afilias-nst.org.
>>>>> a2.org.afilias-nst.info.
>>>>> c0.org.afilias-nst.info.
>>>>> d0.org.afilias-nst.org.
>>>>> a0.org.afilias-nst.info.
Then, checking against one of those, I looked up the "glue" records
$ dig @b0.org.afilias-nst.org. +noall +additional +norecurse  
ns1.sflug.org. AAAA
ns1.sf-lug.org. 86400 IN AAAA 2001:470:1f04:19e::3
ns1.sf-lug.org. 86400 IN A    96.86.170.229
$
Actually, I could've looked up most anything sflug.org. in the above,
and gotten those "additional" records, as they're the needed glue for
the NS record:
sflug.org. IN NS ns1.sf-lug.org.
but since I didn't also ask for the authority record(s), those weren't
included in the results.  Anyway, only 3 of SF-LUG's domains
include ns1.sf-lug.org. as NS:
sflug.com. 172800 IN NS ns1.sf-lug.org.
sflug.net. 172800 IN NS ns1.sf-lug.org.
sflug.org. 86400  IN NS ns1.sf-lug.org.
so essentially only those domains would've been affected, and only
slightly at that, as each has multiple nameservers and many of those
nameservers also have multiple IP addresses.  SF-LUG's other
domains include:
sf-lug.org. 86400  IN NS ns0.sf-lug.org.
sf-lug.com. 172800 IN NS ns0.sf-lug.com.
sf-lug.net. 172800 IN NS ns0.sf-lug.net.
and those do not include:
IN NS ns1.sf-lug.org.
so no impact to those three domains - including sf-lug.org. which is the
canonical.
Anyway, notably, the IPv6 address
was incorrect:                         2001:470:1f04:19e::3
and should have instead been:          2001:470:1f05:19e::3
Al managed to find that in his improved DNS checks, notably
in finding that the "glue" ("additional") from the parent
didn't match the authoritative from the delegated to
nameserver(s), which gave the correct: 2001:470:1f05:19e::3
So, after checking/verifying, I corrected that "glue" record.
So, to illustrate why we need "glue" in many cases.
So, nameserver for org. gives us authority NS records for sflug.org. and
sf-lug.org.:
$ dig @b0.org.afilias-nst.org. +noall +authority +norecurse sflug.org.  
NS sf-lug.org. NS
sflug.org.  86400 IN NS ns.primate.net.
sflug.org.  86400 IN NS nsy.sunnysidex.com.
sflug.org.  86400 IN NS nsx.sunnyside.com.
sflug.org.  86400 IN NS ns1.linuxmafia.com.
sflug.org.  86400 IN NS ns1.sf-lug.org.
sf-lug.org. 86400 IN NS ns.primate.net.
sf-lug.org. 86400 IN NS ns0.sf-lug.org.
sf-lug.org. 86400 IN NS nsx.sunnyside.com.
sf-lug.org. 86400 IN NS nsy.sunnysidex.com.
sf-lug.org. 86400 IN NS ns1.linuxmafia.com.
But to be able to use those nameservers, one needs to know the IP
address(es).  And, where is the information on the IP address(es) for,
e.g. ns0.sf-lug.org. and ns1.sf-lug.org.?  Well, they're on the
sf-lug.org. nameserver - but to get there, first need the IP
address(es).  Hence we need "glue" records on the delegating parent org.
nameserver to get the IP address(es) for the sf-lug.org. nameserver
to be able to contact that nameserver.  So the org. namservers provide
that as "additional" ("glue") records:
$ dig @b0.org.afilias-nst.org. +noall +additional +norecurse  
sf-lug.org. NS sflug.org. NS | sort -u
ns0.sf-lug.org. 86400 IN A    96.86.170.229
ns0.sf-lug.org. 86400 IN AAAA 2001:470:1f05:19e::3
ns1.sf-lug.org. 86400 IN A    96.86.170.229
ns1.sf-lug.org. 86400 IN AAAA 2001:470:1f05:19e::3
And that's what's presently there for the relevant glue records,
whereas earlier it had incorrect IPv6 address for ns1.sf-lug.org.
And the authoritative ("answer") had the correct IPv6 address all along:
$ dig @ns0.sf-lug.org. +noall +answer +norecurse ns1.sf-lug.org. AAAA
ns1.sf-lug.org. 86400 IN AAAA 2001:470:1f05:19e::3
... and I believe that's where Al picked up the discrepancy in his
checks - notably discrepancy between "glue" earlier:
ns1.sf-lug.org. 86400 IN AAAA 2001:470:1f04:19e::3
(and since corrected:
ns1.sf-lug.org. 86400 IN AAAA 2001:470:1f05:19e::3)
and authoritative:
ns1.sf-lug.org. 86400 IN AAAA 2001:470:1f05:19e::3
when they should in fact have matched all along.
Anyway, impact would've been pretty minor.  A non-canonical domain (3
non-canonical domains, but among them only sflug.org. would need and use
the glue record that had been incorrect), so not much depended upon
that, and also redundant - there are of course multiple namservers and
IP addresses:
$ dig +short sflug.org. NS
nsx.sunnyside.com.
ns1.linuxmafia.com.
nsy.sunnysidex.com.
ns1.sf-lug.org.
ns.primate.net.
$ (for d in nsx.sunnyside.com. ns1.linuxmafia.com. nsy.sunnysidex.com.  
ns1.sf-lug.org. ns.primate.net.; do dig +noall +answer +nottl "$d" A  
"$d" AAAA | sed -e 's/$/ ;@'"$d"'/'; done)
nsx.sunnyside.com.  IN A    50.242.105.52 ;@nsx.sunnyside.com.
nsx.sunnyside.com.  IN A    192.147.248.10 ;@nsx.sunnyside.com.
nsx.sunnyside.com.  IN AAAA 2001:1890:1672:1a00:8192:147:248:10  
;@nsx.sunnyside.com.
ns1.linuxmafia.com. IN A    96.95.217.99 ;@ns1.linuxmafia.com.
nsy.sunnysidex.com. IN A    192.147.248.11 ;@nsy.sunnysidex.com.
nsy.sunnysidex.com. IN A    50.242.105.53 ;@nsy.sunnysidex.com.
nsy.sunnysidex.com. IN AAAA 2001:1890:1672:1a00:8192:147:248:11  
;@nsy.sunnysidex.com.
ns1.sf-lug.org.     IN A    96.86.170.229 ;@ns1.sf-lug.org.
ns1.sf-lug.org.     IN AAAA 2001:470:1f05:19e::3 ;@ns1.sf-lug.org.
ns.primate.net.     IN A    198.144.194.12 ;@ns.primate.net.
ns.primate.net.     IN AAAA 2001:470:1f04:51a::2 ;@ns.primate.net.
And of the above, only if formerly incorrect AAAA glue record for
ns1.sf-lug.org. was attempted would it (initially) fail (timeout, or
other ICMP error), after which client would generally try one of the
other IP addresses and generally succeed.  Also, in general, responses
would also be cached per (up to) TTL (Time To Live) value (in seconds)
so even if/when there was an error from not getting the desired DNS data
from the earlier incorrect IP address, good responses from functioning
DNS nameserver IP address(es) would generally be cached for a fair
while, so between that and the redundancy, it would even further reduce
the impact of the failure ... heck, DNS is sufficiently redundant it
took us ... nearly 2 years to even notice that incorrect data.  So, yes,
DNS is pretty robust/redundant - at least properly implemented.  But
also good to at least occasionally check the DNS configurations and
data, etc. - as errors may reduce that redundancy ... and when it's
broken to the point that there's not only no remaining redundancy that
functions, but nothing at all that functions - well, then DNS
experiences a hard failure - and that's not good.

The other item was very minor. ns00.sf-lug.org. was still present
in DNS, but no longer needed.  It had been used years ago to
work around a problem with Joker.com - former registrar for
sf-lug.org.  So after checking there was no longer any need
for ns00.sf-lug.org., went ahead and removed it from DNS.

>> On Jan 9, 2022, at 9:41 AM, Michael Paoli  
>> <Michael.Paoli at cal.berkeley.edu> wrote:
>>
>> And --> ON-LIST
>> ... because why not?  :-)
>>
>> Also some earlier regarding Joker.com & ns00.sf-lug.org., etc.:
>> http://linuxmafia.com/pipermail/sf-lug/2020q2/014726.html
>> http://linuxmafia.com/pipermail/sf-lug/2020q2/014728.html
>> http://linuxmafia.com/pipermail/sf-lug/2020q2/014825.html
>> and some more related in:
>> http://linuxmafia.com/pipermail/sf-lug/2020q2/date.html
>>
>> And the earlier 2001:470:1f04:19e::3 booboo was almost certainly mine.  8-O
>> I probably updated from the earlier
>> 2001:470:1f04:19e::2 to
>> 2001:470:1f04:19e::3
>> while the intended was:
>> 2001:470:1f05:19e::3
>>
>> Can also see the IPv6 addresses on the actual host, e.g.:
>> $ hostname && ip -6 a s | fgrep inet6 | sort
>> balug-sf-lug-v2.balug.org
>>    inet6 2001:470:1f04:19e::2/64 scope global
>>    inet6 2001:470:1f05:19e::2/64 scope global
>>    inet6 2001:470:1f05:19e::3/64 scope global
>>    inet6 2001:470:1f05:19e::4/64 scope global
>>    inet6 2001:470:1f05:19e::5/64 scope global
>>    inet6 2001:470:1f05:19e::6/64 scope global
>>    inet6 2001:470:1f05:19e::7/64 scope global
>>    inet6 ::1/128 scope host
>>    inet6 fe80::5054:ff:fe13:5199/64 scope link
>>    inet6 fe80::6056:aae5/64 scope link
>> $
>> And 2001:470:1f04:19e::3
>> would never have functioned - as could also be tested easily enough.
>>
>> references/excerpts:
>>
>>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>>> Subject: Re: Correct address for ns1.sf-lug.org?
>>> Date: Sun, 09 Jan 2022 08:52:07 -0800
>>
>>> Okay ... possibly notwithstanding TTL (and other slight
>>> delays/latencies) ...
>>> glue record corrected:
>>> ns1.sf-lug.org.         86400   IN      AAAA    2001:470:1f05:19e::3
>>> And checked and found ns00.sf-lug.org. to be fully vestigial and
>>> entirely unneeded and effectively unused at this point,
>>> so went ahead and dropped ns00.sf-lug.org.
>>>
>>> Thanks.
>>>
>>> Turns out authoritative - but not additional (glue) - was correct
>>> on ns1.sf-lug.org. ... authoritative takes precedence, but the
>>> incorrect additional would've caused some additional DNS lookups
>>> and latencies.
>>>
>>>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>>>> Subject: Re: Correct address for ns1.sf-lug.org?
>>>> Date: Sun, 09 Jan 2022 08:18:32 -0800
>>>
>>>> Oh, ... spotted it ...:
>>>> $ dig @b0.org.afilias-nst.org. +noall +additional +norecurse  
>>>> ns1.sflug.org. AAAA
>>>> ns1.sf-lug.org.         86400   IN      AAAA    2001:470:1f04:19e::3
>>>> ns1.sf-lug.org.         86400   IN      A       96.86.170.229
>>>> $
>>>> Yeah, that IPv6 is incorrect.  I'll correct it.
>>>> TTL's 'n all that, may take a wee bit to be 100% better
>>>> across all of the working Internet.
>>>>
>>>>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>>>>> Subject: Re: Correct address for ns1.sf-lug.org?
>>>>> Date: Sun, 09 Jan 2022 08:13:53 -0800
>>>>
>>>>> 2001:470:1f05:19e::3 would be the correct IPv6 for SF-LUG,
>>>>> at least insofar as anything of SF-LUG's on the VM host
>>>>> balug-sf-lug-v2.balug.org,
>>>>> So ... where exactly are you seeing
>>>>> 2001:470:1f04:19e::3 come up?  That would be incorrect.
>>>>> I'm not seeing it, at least in any public DNS "glue" records,
>>>>> e.g.:
>>>>> $ dig +short org. NS
>>>>> b2.org.afilias-nst.org.
>>>>> b0.org.afilias-nst.org.
>>>>> a2.org.afilias-nst.info.
>>>>> c0.org.afilias-nst.info.
>>>>> d0.org.afilias-nst.org.
>>>>> a0.org.afilias-nst.info.
>>>>> $ dig @b0.org.afilias-nst.org. +noall +additional +norecurse  
>>>>> ns1.sf-lug.org. AAAA
>>>>> ns0.sf-lug.org.         86400   IN      AAAA    2001:470:1f05:19e::3
>>>>> ns0.sf-lug.org.         86400   IN      A       96.86.170.229
>>>>> $
>>>>>
>>>>> ns00.sf-lug.org.
>>>>> That (notably DNS name) is probably fully vestigial at this point,
>>>>> but I'd have to check a bit further to be sure.
>>>>> I was once-upon-a-time work-around for a registrar who's glue
>>>>> record management sucked - I believe it was on joker.com - it wasn't
>>>>> possible to change IP address of an existing glue record.  Their
>>>>> (horrible) support said the only way to do it was to delete the glue
>>>>> record, then create it again with the correct IP address - which was
>>>>> not only much more disruptive - but also didn't work.
>>>>> Anyway, as I recall, got off of Joker.com (sf-lug.org was there per
>>>>> Jim Stockford's choice), but that was one of more than one serious
>>>>> technical issues with Joker.com and Jim wasn't really doing
>>>>> diddly with registrar stuff (and had screwed it up significantly
>>>>> multiple times in the past) so ... moved it off of Joker.com, as
>>>>> I recall.
>>>>>
>>>>> Anyway, I'll check further on ns00.sf-lug.org.
>>>>> and see if that DNS names is still needed for anything that still
>>>>> exists.
>>>>>
>>>>>> From: Al
>>>>>> Subject: Correct address for ns1.sf-lug.org?
>>>>>> Date: Sat, 8 Jan 2022 10:47:33 -0800
>>>>>
>>>>>> Michael,
>>>>>> I just finished some improvements in my chk_ns.sh script, and  
>>>>>> got this output which I wanted to ask you about:
>>>>>>
>>>>>> c2.sh-main[775]|scanallns[712]|chkaddl[649]|dodiff[453]: ERROR:  
>>>>>> DNS info comparison FAILED, Domain = sflug.org, Glue RRs for  
>>>>>> sflug.org <<< >>> Publicly available RRs
>>>>>> c2.sh-main[775]|scanallns[712]|chkaddl[649]|dodiff[454]: Domain  
>>>>>> sflug.org DIFF Glue RRs for sflug.org <<< >>> Publicly  
>>>>>> available RRs
>>>>>> 2c2
>>>>>> < ns1.sf-lug.org.       IN      AAAA    2001:470:1f04:19e::3
>>>>>> ---
>>>>>>> ns1.sf-lug.org.       IN      AAAA    2001:470:1f05:19e::3
>>>>>> c2.sh-main[775]|scanallns[712]|chkaddl[649]|dodiff[456]: Domain  
>>>>>> sflug.org DIFF Glue RRs for sflug.org <<< >>> Publicly  
>>>>>> available RRs
>>>>>>
>>>>>> My DNS Slave configs all use the 1f05 address, and that's what  
>>>>>> is in the auth nameservers so I'm assuming that's the right one.
>>>>>>
>>>>>> I am assuming the GLUE record in sf-lug.org for ns1 is out of whack.
>>>>>> I think that you are maintaining that record.
>>>>>>
>>>>>> I looked on Gandi.net where I have shared access to the domain  
>>>>>> and see these glue records:
>>>>>> ns0.sf-lug.org
>>>>>> 2001:470:1f05:19e::3
>>>>>> 96.86.170.229
>>>>>>
>>>>>> ns00.sf-lug.org
>>>>>> 2001:470:1f05:19e::3
>>>>>> 96.86.170.229
>>>>>>
>>>>>> ns1.sf-lug.org
>>>>>> 2001:470:1f04:19e::3
>>>>>> 96.86.170.229
>>>>>>
>>>>>> The setup smacks of some unfinished migration and / or experimentation.
>>>>>>
>>>>>> Rather than "fix"(?) it myself, I thought it would be best to  
>>>>>> raise this for discussion, especially since I don't know what  
>>>>>> you are up to with these records.
>>>>>> I assume ns00 is 'cruft', left over from something or other.
>>>>>>
>>>>>> I also notice that the same setup with ns1.sf-lug.org as an  
>>>>>> authoritative name server is used for sflug.net and sflug.com.
>>>>>>
>>>>>> As for being tidy, I see we're using different name server  
>>>>>> lists for sflug.{com,net.org} and sf-lug.{com,net.org}
>>>>>> Doesn't necessarily need to be fixed.