[SPAM]Re: Malformed response asking for SRV records

[Kevin Darcy]

Barry Margolin wrote:

>In article <caqgmj$mo2$1 at sf1.isc.org>,
> "Humes, David  G." <David.Humes at jhuapl.edu> wrote:
>
>  
>
>>We've noticed a situation recently where a remote name server is sending
>>what appear to be malformed response to queries for external SRV records.
>>Here's an example:
>>
>>1.  Our DNS server sends request for SRV record
>>08:32:00.828185 128.244.197.32.53 > 216.52.184.230.53:  [udp sum ok] 44929
>>[1au] SRV ?
>>_ldap._tcp.3c73ad35-bf08-471e-b10e-4445085745b7.domains._msdcs.chemimage.com
>>. . OPT  UDPsize=2048 (105) (DF) (ttl 252, id 57663, len 133)
>>
>>2.  Remote server responds.  Transaction ID=0, QR=0, RCODE=02
>>08:32:00.875685 216.52.184.230.53 > 128.244.197.32.53:  [udp sum ok] 0
>>[b2&3=0x2] [0q] (12) (ttl 112, id 38777, len 40)
>>    
>>
>
>It looks like your server is making use of EDNS0 extensions, but this is 
>confusing the remote server.  Try turning this off and see if it helps.
>
Shouldn't really matter, since a failed EDNS0 query should be followed 
up by a non-EDNS0 version of the query automatically.

I have to admit being pretty confused by those traces, though: some of 
the so-called "responses" show "QR=0" with a non-zero RCODE (???); plus 
is "id" supposed to be query ID, if so, why don't they match up, and 
what is "Transaction ID" then; why do some of the entries show the QR 
value, and others not; why is the RCODE sometimes shown in symbolic form 
(e.g. "FormErr-"), and other times not???? Looks like the packet-tracing 
tool is trying to be smarter about interpreting DNS packets than it 
really is.

Perhaps raw packet dumps would be less ambiguous.

                                                                         
                                    - Kevin