9.2.3 EDNS0 incompatibility

[Chris Sharp]

Thank you for your reply. Doesn't this change necessitate additional 
network traffic? Why wouldn't the forwarder (9.2.3) return the record 
as sent from the authority, is there some standards reason that 
outweighs the reduced interoperability and network load?
Regards,

Chris

On Sep 12, 2004, at 3:13 PM, Mark Andrews wrote:

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


-- Binary/unsupported file stripped by Ecartis --
-- Type: application/pkcs7-signature
-- File: smime.p7s