[BALUG-Admin] AXFR failures from 198.144.194.238

[Michael Paoli]

Excellent, thanks for the quick turn-around.

And also, more info for your notes
(e.g. /etc/named.conf.local comments)
further below.

references/excerpts:

> From: "Rick Moen" <rick@linuxmafia.com>
> Subject: Re: AXFR failures from 198.144.194.238
> Date: Mon, 22 Aug 2016 16:05:26 -0700

> Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
>
>> Try again, and please reenable.
>
> Done, and successful.
>
> So, is 198.144.194.238 a 'hidden master' for domains balug.org,
> sf-lug.org, and sf-lug.com (providing AXFR to slave nameservers but not
> declared publicly authoritative)?
>
> Let me know if so, and I'll annotate that in my /etc/named.conf.local
> file.

Well, yes, 198.144.194.238 is (partially?) "hidden master".
I believe it is, however, well listed in the SOA origin, though ...
to at least provide some clue(s):
$ dig -t SOA sf-lug.org. +short
ns1.sf-lug.org. jim.well.com. 1463887991 10800 3600 1209600 3600
$ dig -t SOA sf-lug.com. +short
ns1.sf-lug.com. jim.well.com. 1463887991 10800 3600 1209600 10800
$ dig +short ns1.sf-lug.org. A ns1.sf-lug.org. AAAA
198.144.194.238
2001:470:1f04:19e::2
$ dig +short ns1.sf-lug.com. A ns1.sf-lug.com. AAAA
198.144.194.238
2001:470:1f04:19e::2
$
... of course those IPv6 addreses would've been likely also unresponsive
(on same host that was wedged as is also 198.144.194.238)

A reminder on the balug.org situation, as it's wee bit more complex,
bit of expert - more fully context further below:
> Do note, however, that at present time,
> balug.org is NOT (yet) Internet delegated to those IPs - I don't expect
> that to happen until we extricate ourselves from DreamHost.com

Also, prefer if/whenever there might be issue contacting
master, that slaves don't drop merely, or quickly on account
of just that, and nothing else having changed ... as that
semi-defeats one of the purposes of having slaves, and also
a fairly long expire time (e.g. if disaster strikes and it takes
some fair while to get things in operation again - at least if
DNS slaves are still operating, the situation is a bit more
clear for those entities trying to figure out what's going on).

Thanks.

More full background on balug.org, from earlier:
> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
> To: "Rick Moen" <rick@linuxmafia.com>
> Cc: BALUG-Admin <balug-admin@lists.balug.org>
> Subject: [BALUG-Admin] DNS slaves for BALUG?  :-)
> Date: Fri, 19 Feb 2016 03:16:35 -0800

> Rick,
>
> If you could please, and would be willing,
> could you cover DNS slave services for BALUG,
> notably these zones:
> e.9.1.0.5.0.f.1.0.7.4.0.1.0.0.2.ip6.arpa
> balug.org
> master(s) (all for each of the above):
> 198.144.194.238
> 2001:470:1f04:19e::2
> Do note, however, that at present time,
> balug.org is NOT (yet) Internet delegated to those IPs - I don't expect
> that to happen until we extricate ourselves from DreamHost.com - however
> in the meantime it is maintained quite highly alike to the balug.org.
> DNS data on DreamHost.com - I check periodically, and only differences
> I'm aware of are SOA MNAME, RNAME, and often the REFRESH (I don't know
> where they get their REFRESH number from - it seems to vary some fair
> bit, with no particular discernible pattern) and I tend to keep the
> serial # one ahead of DreamHost.com (at least most of the time when I
> check/notice it).  If you'd prefer, for balug.org, could also
> just set up as "warm standby" - verify (to-be) slaves can do
> AXFR pull, and put most of the configuration in place, but just
> don't actually activate it until DNS is fully and properly Internet
> delegated (or we're free from DreamHost.com and about to so delegate).
>
> I'm presuming you could do/offer this on both ns1.linuxmafia.com. and
> also ns1.svlug.org.?  That would be great, if you're able to.
>
> I'm also presuming the various IP information and out-of-band
> communication information is still the same as when we set up
> slaves for sf-lug.org (plus any relevant updates received since then).
>
> Just let me know, thanks (can also email just me directly for any bits
> that ought not get publicly archived, etc.).