9.2.3 EDNS0 incompatibility

[Mark Andrews]

	It's a bug in nsupdate.  It should cope with this sort of
	NXDOMAIN.  Use server and zone commands to workaround the
	problem.

	server pm-members.mac.com.
	zone csharp.members.mac.com.
	<rest of update commands>

> Your response indicates that I could have done a better job at 
> articulating the problem. Here is what I think the client-server-server 
> communication looks like:
> client query SOA ? ---> 9.2.3 Server query SOA + OPT RR ---> Authority 
> for members.mac.com
> Authority for members.mac.com responds FormErr ---> 9.2.3
> 9.2.3 Server query SOA ? ---> Authority for members.mac.com
> Authority for members.mac.com responds with NXDOMAIN (see dig below).
> 
> When the 9.2.3 server receives the answer to the second SOA query which 
> does not include the OPT RR it most certainly does contain an SOA in 
> the authority statement. Functionally, it would be equivalent to:
> dig -t soa computer.csharp.members.mac.com. @17.250.248.161
> 
> ; <<>> DiG 9.2.2 <<>> -t soa computer.csharp.members.mac.com. 
> @17.250.248.161
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46632
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
> 
> ;; QUESTION SECTION:
> ;computer.csharp.members.mac.com. IN    SOA
> 
> ;; AUTHORITY SECTION:
> csharp.members.mac.com. 3600    IN      SOA     pm-members.mac.com. 
> postmaster.mac.com. 1507 10800 3600 604800 10
> csharp.members.mac.com. 3600    IN      NS      pm-members.mac.com.
> 
> ;; ADDITIONAL SECTION:
> pm-members.mac.com.     3600    IN      A       17.250.248.161
> 
> ;; Query time: 133 msec
> ;; SERVER: 17.250.248.161#53(17.250.248.161)
> ;; WHEN: Sun Sep 12 10:22:27 2004
> ;; MSG SIZE  rcvd: 137
> 
> The dig command you reference below is received from the 9.2.3 
> "forwarder" and does not contain the SOA and hence the problem. Let me 
> restate the question (carefully stated in the initial posting), is it 
> possible that the first Formerr response is being cached and
> causing the empty SOA response to the client?
> 
> Regards,
> 
> Chris
> 
> On Sep 11, 2004, at 8:43 AM, Jonathan de Boyne Pollard wrote:
> 
> > CS> $ dig -t soa computer.csharp.members.mac.com.
> > CS> [...]
> > CS> The 9.2.3 server then re-issues the query without the OPT RR and
> > CS> gets an NXDOMAIN with the SOA record in the authority section.
> >
> > No, it doesn't.  Read the output _carefully_.
> >
> Hello,
> Since upgrading from 9.2.1 we are seeing some strange behavior on our
> 9.2.3 server. When I issue:
> 
> csharp6:~/bin csharpl$ dig -t soa computer.csharp.members.mac.com.
> 
> ; <<>> DiG 9.2.2 <<>> -t soa computer.csharp.members.mac.com.
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23436
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;computer.csharp.members.mac.com. IN    SOA
> 
> ;; Query time: 33 msec
> ;; SERVER: 17.128.100.12#53(17.128.100.12)
> ;; WHEN: Fri Sep 10 13:58:12 2004
> ;; MSG SIZE  rcvd: 49
> 
> the 9.2.3 server responds this way. This causes nsupdate to fail
> "response to SOA query didn't contain an SOA". Note, the 17.128.100.12
> address is internal and forwards to 17.254.0.35 (9.2.3 server).
> 
> We turned logging all the way up to 99 on the 9.2.3 server and did not
> see anything out of the ordinary - or at least to my eyes.
> 
> A network trace comparing the new server with the old shows that the
> new server is issuing the SOA lookup with an OPT resource record:
> SOA? computer.csharp.members.mac.com. ar: . OPT UDPsize=2048 (60)
> 
> where the old server:
> SOA? computer.csharp.members.mac.com. (49)
> 
> The custom dynamic DNS server responding (17.250.248.161) to the first
> query responds with a FormErr. The 9.2.3 server then re-issues the
> query without the OPT RR and gets an NXDOMAIN with the SOA record in
> the authority section.
> 
> Is it possible that the first Formerr response is being cached and
> causing the empty SOA response to the client?
> 
> Regards,
> 
> Chris Sharp
> 
> -- Binary/unsupported file stripped by Ecartis --
> -- Type: application/pkcs7-signature
> -- File: smime.p7s
> 
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org