[BALUG-Admin] AXFR failures from 198.144.194.238

Rick Moen rick@linuxmafia.com
Tue Aug 23 00:55:13 PDT 2016


Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):

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

Yes, I meant to check the SOA record in the auth nameservice, but ran
out of time because I was waiting for a 'plane back from Kansas City.
(I've arrived home, now.)

Anyway, I've annotated my named.conf.local so I'm not taken by surprise
again by a master nameserver that's not in the authoritative roster and
doesn't respond to ping.

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

Yeah, in this case, it was an artifact of the situation looking (from
available data) _very_ much like past situations where someone moved the
master DNS and failed to notify the slave nameserver admins.  Which has
happened to me repeatedly.  And, just a point:  Every time _that_
situation has gotten visited upon me as a volunteer provider of
secondary nameservice, I've not only been put to some avoidable and
unnecessary work, but also (for lack of a heads-up) my own nameservice
has continued to publish wrong, obsolete zone information for long
periods until I noticed the communication failure.  E.g., I and my users 
(in those cases) got left using obsolete DNS data.  _So_, I've become
quick to pull the trigger when something just doesn't look right at all.

For my part, I would strongly suggest that, when you get people to do
slave nameservice for you, you really ought to warn those systems'
admins if the master nameserver will neither respond to ping nor
(especially) be deliberately omitted from the authoritative roster.
Why?  Because otherwise there's an excellent chance they'll interpret
those data during the first downtime episode as meaning that you moved
the master and failed to tell them.  I did.




More information about the BALUG-Admin mailing list