ixfr problem

[Kevin Darcy]

Cricket Liu wrote:

> > > 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".
>
> You're not picking nits with me, because I never said that the update had to
> be sent to a published authoritative name server.

I'm not sure why you brought up NS records then. I read your comment as
implying that only nameservers in the NS records ("published" authoritative
servers) were appropriate targets for Dynamic Updates.

> In fact, Microsoft's
> routines send updates to the name server listed in the MNAME field
> regardless of whether that name server also appears in an NS record.
>
> This is all irrelevant to the notion of sending the update to the resolver's
> first name server, though, since the fact that a name server is listed in
> the
> resolver's configuration says nothing about what zones it's authoritative
> for.

Apparently I haven't been making myself very clear. My understanding of
Microsoft's vision of the future is that *all* DNS servers are "multi-masters"
for *all* relevant DNS zones. So then it doesn't matter where the update goes,
and, all other things being equal -- and they *are* equal at that point -- you
may as well use the same nameserver which is first in your resolver
configuration, aka your "preferred nameserver". While I may not agree with this
approach, I can't really say that it clearly violates the RFC, because of all
of that fuzzy language in there about "reachability".


- Kevin