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.).