Re: [dnsext] BADVER/FORMERR

[Olafur Gudmundsson <[e-mail]>]

On 12/11/2011 17:14, Mark Andrews wrote:
> In message<[e-mail]>, Olafur Gudmundsson writes:
>> On 10/11/2011 21:50, Mark Andrews wrote:
>>>
>>> I was looking for a good way to test for EDNS support and hacked
>>> dig to send out a empty question section when the EDNS version was
>>> set to 255 and got what I believe to be incorrect responses from K
>>> and L.  EDNS version processing is supposed to take precedence over
>>> examining the query section as the EDNS version can influence the
>>> interpretion of the question section.  I believe the correct response
>>> should be BADVERS.  Adding a question elicited BADVERS.
>>>
>>> Do others agree with my interpretion of rcode precedence?
>>>
>>
>> <no hat>
>> Formerr is perfectly valid return code.
>> It is the first error you detect and you can stop processing
>> right then.
>> (This assumes that the QR=0)
>>
>> Reasoning: You sent a question that is not a real question
>> I see nothing in ENDS0 rfcs that say you need to look into the
>> opt record if the DNS packet is malformed, QR=0 and QDCOUNT=0
>> is malformed packet IMHO.
>
> Even if FORMERR is returned, the response is also missing the OPT
> record which is required to be sent by EDNS aware servers.  If you
> can't parse the packet to get to the OPT record then a 12 octet
> FORMERR is appropriate.  This packet is parsable.
>
>     VERSION         Indicates the implementation level of whoever sets
>                     it.  Full conformance with this specification is
>                     indicated by version "0."  Requestors are encouraged
>                     to set this to the lowest implemented level capable
>                     of expressing a transaction, to minimize the
>                     responder and network load of discovering the
>                     greatest common implementation level between
>                     requestor and responder.  A requestor's version
>                     numbering strategy should ideally be a run time
>                     configuration option.
>
>                     If a responder does not implement the VERSION level
>                     of the request, then it answers with RCODE=BADVERS.
>                     All responses will be limited in format to the
>                     VERSION level of the request, but the VERSION of each
>                     response will be the highest implementation level of
>                     the responder.  In this way a requestor will learn
>                     the implementation level of a responder as a side
>                     effect of every response, including error responses,
>                     including RCODE=BADVERS.
>

<no-hat>
#1 I can reason that it is OK to stop parsing a packet after an format 
error is detected .
The text above does not clearly support your interpretation nor mine.
(I might even be tempted to say, randomly dropping the packet is also 
acceptable).
Sending Refused is also in contention, but not helpful.

#2 From your original message you seemed to be asking about the error 
code, not if the missing OPT record was appropriate.

Strictly speaking given how narrow the error reporting channel in DNS is 
either interpretation is acceptable i.e. First Error detected or Most 
Significant error, responders should be ready to handle both.
But at the same time I understand your desire to have an easy way to 
detect the ENDS0 version.

	Olafur