Re: [DNSOP] Terminology: "primary master"

[Paul Vixie <[e-mail]>]

Joe Abley wrote:
> Hi Paul,
> ...
> I presume you mean existing, not extant. ...

yes. thanks for understanding what i mean in spite of what i said.

> The principal challenges I have seen using a non-trivial transfer
> graph with NOTIFY and [AI]XFR are when a pair of candidate masters for a
> particular slave each receive a new revision of a particular zone at a
> different time. The one that receives it first sends NOTIFY messages to
> its slaves; if slaves don't use the NOTIFY source to select the master
> subsequently used to send SOA queries and [AI]XFR requests to (and it is
> normal not to in many/most/all widely-used implementations) there is a
> chance they will talk to the master that hasn't yet been updated and
> hence not retrieve the new revision of the zone. Presumably all masters
> update eventually, however, so normality will eventually be restored.

first let's clarify that this can't happen between the PM and its DM's,
because in my example, the PM was HA. i do know that not all NOTIFY
responders will try-first the server who sent them the NOTIFY, and that 
this can result in not learning a new serial number after a NOTIFY. the
BIND4 version of the NOTIFY code did this correctly, but i'm guessing
that RFC 1996 was not as clear on this topic as it might have been.

my preferred solution to this woe is to fix the NOTIFY responders, but 
as we know this is often outside our powers. my actual solutions to this 
have been to either delay all NOTIFY's for some amount of time that's 
long enough to get the DM's to all settle, and make sure that the 
settle-time is as short as i can make it. or better still, give the 
slave-operators only one address for "zone master", and anycast that one 
to get redundancy.

as an aside, the computed random delay-before-notify was not specified 
as a way to get a longer settling time; it was just to prevent all of 
the recipients of a NOTIFY-burst from doing their AXFR's in parallel. 
this was damnfoolishness related to BIND4's "fork on AXFR" logic, and i 
deeply regret it. 1996 was my first RFC and it shows.

> The state involved in processing NOTIFY messages, especially when
> there's loss in a path somewhere which triggers timeouts, back-off and
> retransfer, can be painful to manage at scale. I have seen some abuse of
> the specification in the form of fire-and-forget NOTIFYs to avoid the
> state problem (discard NOTIFY responses received and never attempt to
> retry sending, assuming that if ours didn't get through a NOTIFY from
> another master probably will).

alas, many operators solve only the problem they know they're having, 
without regard to the ones they don't know about, and without regard for 
the problems their solutions might cause for others. "monkey DNA".

> Davey Song described a scenario that played out in the Yeti project
> where multiple masters each serving zones that were equivalent but
> different caused problems to downstream IXFR clients. The zones were
> equivalent in the sense that they only differed in RRSIGs -- each server
> used a local ZSK, corresponding properly to an RR in the DNSKEY RRSet,
> to sign all the non-DNSKEY RRSets -- but different in the sense that the
> RRSIGs were different, so really they were different zones with the same
> origin. IXFR clients got confused, which I think in retrospect was
> probably to be expected. This feels like the kind of scenario that Tony
> was talking about in his earlier message in this thread.

yeti is probably a degenerate non-teaching corner case. since it deals
with the root zone, we had to politicize the design -- there are three
DM's whose only shared data is the IANA source zone they start with, and 
the KSK they sign ZSK's with. we had to avoid annointing any one party 
as having a special relationship to root-like zone data. this is 
unlikely to be a problem for anyone else or for any other zone.

>>see http://family.redbarn.org/~vixie/mz.pdf ...

> I used an earlier version of that back in the day, as you might
> remember. Pretty much everything I've been involved in since then has
> used out-of-band provisioning of zone targets though, using devopsy
> automation tools (ansible, chef, puppet) or provisioning databases that
> were replicated independently of the DNS.

that's what a lot of the professionals do. however, i won't recommend 
technology that hasn't been documented and tested for interoperability, 
portability, and lack of IPR encumbrance.

> One notable exception used
> supermasters in PowerDNS, which you could call in-band (but still a
> different approach from
> metazones)

MZ was influenced by BIND, and only implemented for BIND, but was meant 
to be name-server independent. i would like to see something like this 
gain broad industry traction, so that we can all spend our time solving 
things that somebody else hasn't already solved.

-- 
P Vixie