kcd at daimlerchrysler.com
Tue Oct 9 19:31:55 UTC 2001
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
> > MSDNS and the zone in question is "AD-integrated", because then all of
> > 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
> > 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
> > 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
> 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".
More information about the bind-users