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

["James Gilroy (Exchange)" <jamesg@Exchange.Microsoft.com>]

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:vixie@mibh.net]
Sent: Friday, September 10, 1999 7:36 PM
To: namedroppers@internic.net
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?