Re: i'm concerned about some RFC 2136 interoperability problems

[Paul A Vixie <vixie@mibh.net>]

> I made the change to put the A record in the additional section simply for
> efficiency.  My reading of the RFC (more or less the "nothing forbids it"
> argument you note below) suggested it was ok, and it is a piece of
> information that will be immediately desired by the client to complete the
> update.

in the spirit of "make things as simple as possible, but not simpler", it is
my advice that you back out this optimization in two ways which should be
complementary and therefore leave you in the same single-round-trip position
you're in now -- but with inarguable compliance to all relevant standards.

1. server side change:

an soa answer can and should include an authority section.  these are the
NS RRs you're asking about, and yes, i think you should send them.  and you
should also send all of the relevant glue in the additional data section --
this means a full A RRset for each NS RR mentioned in the authority section.

2. client side change:

look through the SOA answer and consider the whole NS RRset as candidates
for DNS UPDATE transactions.  remember all of the glue addresses for these
NS RRs.  then and only then look at the SOA MNAME and if it matches the
NSDNAME of any NS RR, then either float the addresses of that NS to the top
of your candidate list or shorten your candidate list to just those addresses.

rationale:

if i were to answer your SOA query with an MNAME of "localhost" and some
additional data giving "127.0.0.1" as the address of "localhost" but never
mention "localhost" as an NS NSDNAME, then your current implementation would
suck the pigeon right into the rotor and you'd be going down in flames while
a more arguably correct client side implementation would sail onward and not
be fooled by this bad (but irrelevantly bad) SOA MNAME.

[RFC2136 4.3] says: "should arrange to try the primary master server (as
given by the SOA MNAME field if matched by some NS NSDNAME) first", and the
word "if" was carefully considered and was also the subject of WG debate.

> On the client side, the microsoft client will prefer to go to the primary
> name server given in the SOA, but if that seems to be unreachable it does
> the NS query and tries the update to each of the given servers in turn.  We
> have a couple of servers running recent BIND versions in the lab and the
> client has no trouble updating them.

see above, and consider the support headaches you'll face once the people who
select SOA MNAMEs are not your highly trained test lab operators.

> Paul, is your suggestion simply that I should include the NS records in the
> SOA response packet?  That may be doable even at this late date.  But does
> this solve the nsupdate issue?

yes, that is part of my recommendation, but i also think your client is wrong.
and yes, it would solve the 8.2.1 nsupdate issue, but i'm also fixing it to do
the right thing (which is to say, make the necessary NS queries) in response
to the (incorrect in my opinion) SOA responses you're sending now.

but think about that pigeon hitting your rotor, and consider your passengers.