nsupdate querying Windows 2000 DNS server

Paul Vixie vixie at mibh.net
Fri Sep 10 03:47:28 UTC 1999


I'm going to slightly modify my previous response to this:

levone at Exchange.Microsoft.com ("Levon Esibov (Exchange)") writes:

> Hi,
> 
> Just wanted to bring to your attention the following interop issue:
> 
> 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.

Yes.  This is a failure of robustness on our part, and I'm fixing it.  Thanks!

However:

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

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 our
problem.  The above protocol violation is Microsoft's problem.  Can you submit
a bug report against whatever software runs the MICROSOFT.COM servers?  Thanks.

(In your stated example, the RCODE is NXDOMAIN, which also has this problem.
The fact that nsupdate would work if your servers were RFC 1034 compliant is
unrelated to the fact that nsupdate should work even though they are not.)
-- 
Paul Vixie <vixie at mibh.net>

	>> But what *IS* the internet?
	> It's the largest equivalence class in the reflexive transitive
	> symmetric closure of the relationship "can be reached by an IP
	> packet from".		--Seth Breidbart


More information about the bind-workers mailing list