Subject: EDNS standard clarification

From: Michael Sawyer <[email-masked]>
Date: Fri, 6 Oct 2000 14:38:26 -0700 (PDT)

Brian Wellington and myself are working on a personal draft which proposes
two new EDNS option codes, and have encountered an issue with RFC2671
which we believe needs addressing.

RFC2671 appears to be totally silent on the issue of how an EDNS-aware
server should handle the situation where it gets a query with an EDNS OPT
record containing one or more option codes which it doesn't know how to
handle.  Section 5.3 of 2671 doesn't appear to apply in this case, since I
read that as talking about servers which don't speak EDNS at all, not ones
which speak EDNS but not all of the options which it is sent.

My first impression of what should be done (which is what Bind9 does, and
appears to be what most people I've spoken to feel is correct) is to
ignore the unrecognized option records.  As the standard is written now,
it is unclear whether servers should behave this way, reply with FORMERR,
NOTIMPL, or take some other course of action.

Is it the opinion of the rest of the working group that the correct
behavior is to ignore the unknown options, leaving it up to the authors of
the option standards to define what behavior is required if the server
needs to indicate that it did understand and accept the passed option?

						Mike

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bill Manning <[email-masked]>
Date: Tue, 10 Oct 2000 11:05:17 -0700 (PDT)

% My first impression of what should be done (which is what Bind9 does, and
% appears to be what most people I've spoken to feel is correct) is to
% ignore the unrecognized option records.  As the standard is written now,
% it is unclear whether servers should behave this way, reply with FORMERR,
% NOTIMPL, or take some other course of action.

	I would expect the behaviour to be "NOTIMPL" instead of a
	"silent" ignore. Its not a FORMERR, is it? :)

--bill

---

From: Michael Sawyer <[email-masked]>
Date: Tue, 10 Oct 2000 11:19:38 -0700 (PDT)

> 	"silent" ignore. Its not a FORMERR, is it? :)

The problem I forsaw with something like that was what to do on getting
the NOTIMPL reply back, if you sent out a query with (for example) 10 OPT
attributes.  Unless you have something which indicates *which* of the 10
you didn't recognize, the client has no way of knowing which ones to turn
off, and turning all off just because one isn't implimented seems like a
bad idea.

Also, as Brian pointed out when we were discussing this the other day,
some of the OPTs may be just fine to ignore (key or encryption types we
understand, etc...).

I can think of arguments both ways, actually.  It may work to extend the
EDNS definition of the opt codes such that the upper bit means "you MUST
understand me or fail," or something along those lines.  I know that's
kind of ugly, but it may one way to deal with this.

					Mike

---

From: Bill Manning <[email-masked]>
Date: Tue, 10 Oct 2000 13:01:48 -0700 (PDT)

% On Tue, 10 Oct 2000, Bill Manning wrote:
% 
% > 	I would expect the behaviour to be "NOTIMPL" instead of a
% > 	"silent" ignore. Its not a FORMERR, is it? :)
% 
% The problem I forsaw with something like that was what to do on getting
% the NOTIMPL reply back, if you sent out a query with (for example) 10 OPT
% attributes.  Unless you have something which indicates *which* of the 10
% you didn't recognize, the client has no way of knowing which ones to turn
% off, and turning all off just because one isn't implimented seems like a
% bad idea.

	So... perhaps the "right" thing is to update NOTIMPL with a
	array-index... :)  But for legecy code, the right thing is
	a "blanket" NOTIMPL.

--bill

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 10 Oct 2000 12:08:00 -0700

the original intent of EDNS was that the version number would have to be
revved to introduce any REQUIRED opt codes, and that version negotiation
would be used to level set.

EDNS0.5 seems to change all of that, though.

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 10 Oct 2000 18:02:25 -0400

Bill Manning wrote:
>         array-index... :)

Or, following the lead of EDNS0.5, how about the server returns an option list
in its reply including just those requested options it understands and honors?

If it is ever necessary for the client to distinguish between a server's
"don't understand" and "don't honor", then allocate another option code for
the server to use as an explicit NAK -- "understand but don't honor".

Unless, of course, we are running low on available option codes :-)

- Kevin