Subject: Re: EDNS0 (RFC-2671) questions

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Feb 2008 05:31:16 +0000

sorry for the late reply.

> Date: Thu, 18 Mar 2004 15:25:36 +0200
> From: Markku Savela <[email-masked]>
> To: [email-masked]
> Subject: EDNS0 (RFC-2671) questions
> Sender: [email-masked]
> 
> 1) assuming I send query, which includes the OPT RR (to increase the
>    packet length). If I receive a reply with TC=1 (truncation) and
>    don't find OPT RR in the reply, then I assume the RCODE is the
>    non-extended one?

yes.

>   [Just verifying, that I can trust all implementations do it right:
>   if they build an answer and run out of space before inserting the
>   OPT RR, they also fall back to old plain RCODE?]

i don't know if all implementations do this right.  but your interpretation
is correct, in the opinion of the author.  i will add the following text
to EDNS0-bis to cover this case.

.LP
5.4. If EDNS is used in a request, and the response arrives with TC set and
with no EDNS OPT RR, a requestor should assume that truncation prevented the
OPT RR from being appended by the responder, and further, that EDNS is not
used in the response.  Correspondingly, an EDNS responder who cannot fit all
necessary elements (including an OPT RR) into a response, should respond with
a normal (unextended) DNS response, possibly setting TC if the response will
not fit in the unextended response message's 512-octet size.

> This extended-RCODE makes it somewhat akward, to find RCODE, you have
> to traverse through all data in Question, Answer and Authority
> sections, then look OPT RR from Additional section. Doable, but still
> icky, just to get few extra bits of RCODE that are rarely used. Would
> have been easier if there was single RCODE value in fixed header to
> indicate that extended RCODE is in use.

yes, it would have been better, you're right.

> 2) Can UDP payload size be < 512?
> 
> I didn't see any mention of it. Maybe I missed it. I think RFC should
> state that attempting to use less than 512 is not allowed (and will be
> ignored). [If < 512 is accepted, there might be some DOS potential in
> it also]

agreed.  i've added two sentences to EDNS0-bis to cover this case.

.LP
4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
field) is the number of octets of the largest UDP payload that can be
reassembled and delivered in the sender's network stack.  Note that path
MTU, with or without fragmentation, may be smaller than this.  Values lower
than 512 are undefined, and may be treated as format errors, or may be
treated as equal to 512, at the implementor's discretion.

thank you VERY much for your review, your observations, and your suggestions.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>