9.2.3 EDNS0 incompatibility

[Chris Sharp]

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