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

From: Paul A Vixie <[email-masked]>
Date: Fri, 10 Sep 1999 19:36:25 -0700

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: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 12 Sep 1999 22:56:30 +0200

At 14:31 11.09.99 -0700, James Gilroy (Exchange) wrote:
> 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.

From a thread on the dnsop list: In some cases the owner of the zone does 
not *want* people to query the nameserver listed in the SOA.

In those cases, the SOA is not listed in the NS list when you ask for NS.

Quote from that debate (date Aug 23):

>> Do you know of any cases now where there is no overlap between SOA
>> and NS?
> li.org, slashdot.org, microsoft.com (!), for instance.
> more bizarre things happen - altavista.com uses a name in the SOA that
> has the same A as one of its NSes, but different name.
> microsoft looks as if it's round-robining its NS set, and my copy just
> happened not to include ns 1.
> the world is a strange place.

Not sure how this affects dynamic update.

                          Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]