i'm concerned about some RFC 2136 interoperability problems

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

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?