ixfr problem

[Kevin Darcy]

Cricket Liu wrote:

> > > I've never heard anything like that.  That would be completely non-
> > > RFC compliant behavior, to say nothing of the fact that it wouldn't
> > > generally work.
> >
> > Actually, it *does* generally work when the "preferred nameserver"s are
> all
> > MSDNS and the zone in question is "AD-integrated", because then all of
> them
> > are "multi-master"s capable of accepting updates to the zone.
>
> By "generally," I meant "in the general case," not "usually."  It certainly
> does not
> work in the general case.

Okay, point well taken. general != usual.

> > As for RFC-compliance, the RFC leaves a pretty big loophole when it says
> that
> > a client can try the nameservers in order of "reachability" instead of
> > unfailingly trying the SOA.MNAME nameserver first. It could be argued that
> > the "preferred nameserver" can be assumed to be more "reachable" than
> other
> > nameservers, since after all the client relies on it for name resolution.
>
> The RFC says a client can try *the authoritative name servers for the zone
> it's
> updating* in order of reachability, not just any old name server.  I have no
> qualms with an implementation that looks up the zone's NS RRs and then
> looks to see whether one of those is the resolver's default name server to
> determine reachability.

Not to pick nits, but the RFC never actually specifies that only
*published* authoritative nameservers can be used. It only says
"authoritative". So it would seem perfectly legitimate to send an update to a
stealth slave or a "hidden master".


- Kevin