Subject: RE: i'm concerned about some RFC 2136 interoperability problems

From: "James Gilroy (Exchange)" <[email-masked]>
Date: Sat, 11 Sep 1999 14:31:47 -0700

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.

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.

I believe there was a full dynamic update interop between various vendors at
one of the recent (this year) industry blabfests and everything looked good
(all vendors clients\servers able to update one another).  But I don't
actually have any data available.  Maybe someone who was there does.

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?

	jim

-----Original Message-----
From: Paul A Vixie [mailto:[email-masked]]
Sent: Friday, September 10, 1999 7:36 PM
To: [email-masked]
Subject: i'm concerned about some RFC 2136 interoperability problems

Someone from Microsoft sent me mail the other day saying:

> When nsupdate sends a query for a SOA record of a non-existing name and
the
> Windows 2000 is authoritative for that name, the nsupdate fails to parse
the
> servers response.
>
> Windows 2000 DNS server returns NXDOMAIN with
> SOA record of an authoritative zone (in Authority section) and
> A record of the primary name server specified in the SOA record (in the
> Additional section).
> 
> It looks like the nsupdate can't parse this Additional section.
> Since nsupdate fails to parse the response, it fails the update. Thus,
> nsupdate cannot be used to update a Windows 2000 DNS server.

Now, at some level these are BIND problems and I'm working on fixing them.
But
here's a query against Microsoft's own authoritative corporate nameserver:

|;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
|;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
|;; QUERY SECTION:
|;;      microsoft.com, type = SOA, class = IN
|
|;; ANSWER SECTION:
|microsoft.com.        15M IN SOA      dns.cp.msft.net.
msnhst.microsoft.com. (
|                                        99090902        ; serial
|                                        15M             ; refresh
|                                        10M             ; retry
|                                        11w6d8h         ; expiry
|                                        15M )           ; minimum
|
|;; ADDITIONAL SECTION:
|dns.cp.msft.net.        1D IN A         207.46.138.10

This is a problem.  According to [RFC1035 3.3.13]:

|RFC 1035        Domain Implementation and Specification    November 1987
|...
|SOA records cause no additional section processing.
|...
|Mockapetris                                                    [Page 20]

In other words, if you want to include an A RR here, you're somewhat
obligated
to include the zone's top NS RRset, and *all* of the related glue.  Of
course,
nsupdate as shipped in BIND 8.2.1 would still crap out on this, but that's a
BIND problem.  The above protocol violation is, however, a Microsoft
problem.

In considering this, [ibid] only says there is no requirement for additional
data, which is different from a requirement that there be no additional
data.
After all, additional data is, well, additional -- a requestor is almost
always
free to ignore it.  So I checked back on [RFC2136 4.3] which says:

|   4.3. If the requestor has reasonable cause to believe that all of a
|   zone's servers will be equally reachable, then it should arrange to
|   try the primary master server (as given by the SOA MNAME field if
|   matched by some NS NSDNAME) first to avoid unnecessary forwarding
|   inside the slave servers.  [...]

This bolsters my view that the NS RRset ought to be present.  Microsoft's
DNS
client appears to be prepared to use the SOA.MNAME and the additional data
as
the appropriate destination for an UPDATE transaction, where [RFC2136] says
that only NS.NSDNAMEs are potential UPDATE responders and recommends
priority
be given to the one that matches the zone's SOA.MNAME.

Is anybody testing for this kind of stuff in the IETF DNSIND test-a-thons?

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 11 Sep 1999 23:06:26 -0700

> information that will be immediately desired by the client to complete the

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.

> 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.

> 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.