Subject: Time to make some progress: EDNS0

From: Robert Elz <[email-masked]>
Date: Wed, 19 May 1999 05:47:40 +1000

I expect that everyone knows by now that ends0 was bounced by the
IESG, partly due to some last call comments, and partly because of
some of their own concerns.

Some of that has been made to just "go away", but there is one
issue that we do need to get fixed before we send edns0 back to
the IESG.

That's the question of how the version field should be handled.
Or perhaps more correctly, how we should explain how it should
be handled, as the problem seems mostly to be of clarity of
what is in the draft, rather than anything of great substance
that needs any real technical discussions.

But just in case, let me state the protocol, as I understand it...

If the resolver knows nothing about edns, it sends queries as now,
and regardless of what the server knows, it is required to answer
just like now - no edns additions in the packets.

If the resolver groks edns, it sends the query with its edns version
in the version field.   Actually, as it has been pointed out (off
line), it should probably be configurable as to which version to
send, up to the highest version it understands, so resolvers which
support high versions can be deployed before any servers that
understand them, and without havng all queries done twice.   And even
more, resolvers probably ought send only the version number required
for the query and options it needs to send.   That is, even if it knows
edns7, it should send version==1 in the packet if there is nothing else
there which requires any of edns2..7.   This way maximises the chances
that the server will cope.

If the server gets a query with an edns version it doesn't understand,
it returns a BADVERS error, and indicates which version it can handle.
Or, if it doesn't know edns at all, it indicates that by returning an
answer wthout the OPT RR.  Resolvers might cache server edns version
information if they feel inclined - classic trade off between memory
consumed for the cache, and bandwidth (and processing) required if a
later query also neds to be retransmitted because too high a version
was used.

Otherwise, the server answers, and includes its version (>= the
version in the query) in the response.

If there anyone who disagrees that this is the protocol intended in edns0?

Assuming not for now, I ahve been sent the following strawman text
by Thomas Narten for our consideration ...

  VERSION:

  In a query, VERSION indicates a level that the requestor supports and
  the level the responder should use while processing the request.  Full
  conformance with this specification is indicated by version ``0.''
  Responders must process each request according to the rules associated
  with the request's VERSION or send back RCODE=BADVERS if unable to do
  so. The responder always sets the VERSION in the response to the
  highest level it supports. If requestors receive an RCODE=BADVERS and
  a responder VERSION lower than that in their request, they should
  retry using the responder's version.

  If the requestor knows the VERSION level of the server to which it is
  sending a query, it sets the VERSION field in the request to the lower
  of its own and the server's values. If the requestor does not know
  what VERSION level a server supports, it sets the VERSION field of the
  request to the highest level it supports. If the server does not
  support that version, it will return a RCODE=BADVERS error, and the
  requestor can retry using the lower version. The resolver should
  retain knowledge of whether the server supports EDNS, and if so, what
  version, for future queries. If a responder's capability level is
  cached by a requestor, a new probe should be sent periodically to test
  for changes to responder capability.

  [the last sentence is already in the draft in another place, and
  doesn't need to be in both places.]

  To avoid having a server return a version number error for a simple
  query that can be satisfied without the use of extended DNS
  facilities, a resolver might send a query with a lower version number
  than it supports for certain queries.

  Resolvers and servers should provide a configuration capability for
  disabling the use of the EDNS mechanism or specifying the higest level
  that is to be used.

In that, I would not include the "a new probe should be sent..." stuff.
It gives the wrong impression (suggesting that resolvers should send
probe queries even if there is no information needed, which is clearly
not a good idea, and unncessary anyway - if the resolver needs anything
from the server, it can send a query using the version it thinks the
server supports - if that is out of date, the reply from the server will
impart that information (the only exception being where the resolver
believes the server does not support edns at all - there the resolver
would have to try an edns query every N'th query, just to find out
whether the server has been updated.   For this, "N" probably relates
to about once an hour (or perhaps a few), which suggests that a resolver
need not remember server status when it is not sending queries for
longer than this).   If the resolver doesn't need anything from the
server than it cannot possibly care what version the server is at, and
so does not need to probe.   When a new query is eventually to go to
this little used server, the resolver will just treat it like any other
server about which it has no knowledge.

I'd also omit the "and servers" in the final paragraph, there's no
reason I can see for preventing a server from announcing the highest
version it knows (assuming the resolver is doing edns at all).
I'd probably also allow resolvers to automatically ignore the configured
limit and send any version they have positive knowledge (from a previous
answer) that a server supports.   In any case, all of this config stuff
is possibly just an implementation issue and could be omitted entirely?

So, with those adjustments, any objectionsto including the strawman
text in the draft?    Or better, any submissions for even better
text to explan what is going on with this value?

kre

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 18 May 1999 16:08:34 -0700

So far, EDNS0-02 has the RFC2026 stuff added.

> that the server will cope.

Once we're using the lowest number capable of expressing a request, then
there is no way to minimize it against either a local administrative
preference or against the server's implementation level.  So at the moment:

.IP VERSION
Indicates the implementation level of whoever sets it.  Full conformance with
this specification is indicated by version ``0.''  Requestors should set this
to the lowest level capable of expressing a request.
.IP
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 the RCODE=BADVERS response.

> later query also neds to be retransmitted because too high a version

That was the original intent, yes.

> version in the query) in the response.

Yes.  But EDNS0-01 was unclear about the fact that the response's format
was limited by the request's VERSION.  The above-shown text fixes that.

>   retry using the responder's version.

This is fine until the last sentence.  If we're truly going to have
requests use the lowest version number which can express a request, then
there's no alternative if the server doesn't understand it.  So to meet the
desire we would have to express versions in terms of "network optimization"
or "preference", as in "A request should be formatted using the requestor's
highest implemented version level, unless minimized by local administrative
preference or by prior RCODE=BADVERS experience with that version and the
prospective responder.  In response to (possibly cached) RCODE=BADVERS, a
requestor should consider retrying the request using a version number at or
below that of the responder, so long as the correctness of the transaction
is not impinged thereby."  You see how sticky this whole thing gets?

>   for changes to responder capability.

All this is fine, subject only to the concerns stated above.

>   than it supports for certain queries.

This isn't testable so I'm for wording it more strongly or leaving it out.

> server about which it has no knowledge.

Sounds like a good optimization.

> version it knows (assuming the resolver is doing edns at all).

No argument from me on that point.

> is possibly just an implementation issue and could be omitted entirely?

This part of the limiting logic just isn't thought out yet at all, though.

> text to explan what is going on with this value?

I think this is going to be a long haul if folks here are convinced that
the version minimization logic needs that extra term in it.  To prove me
wrong, someone here would submit p-code and nobody else here would flame it.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 19 May 1999 10:06:59 +0200

>to the lowest level capable of expressing a request.

I'm probably shooting from far below the hip here, but....
in EDNS versions 1...255, will there never be an extension added so that
the client can ask for something that can be expressed in either an "old"
or a "new" reply, but the choice between the two can only be made at the
server end?

For instance, if someone were to implement a multipacket answerback to UDP
queries that actually made sense, and support was mandatory for EDNS23.

A query could be expressed using EDNS0, but the answer would be more efficient
if the server knew that the client supported EDNS23, but the client couldn't
know whether the answer was large enough that this mechanism might be
required.

Only obfuscating the question....I liked the "send whatever I support,
unless I have a reason not to" better....

(only 415 lame servers in my syslog today. Must be a good day for the DNS...
another retry for version downgrade won't kill us, IMHO)

                       Harald

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Robert Elz <[email-masked]>
Date: Wed, 19 May 1999 19:24:11 +1000

Date:        Tue, 18 May 1999 16:08:34 -0700
    From:        Paul A Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | This is fine until the last sentence.  If we're truly going to have
  | requests use the lowest version number which can express a request, then
  | there's no alternative if the server doesn't understand it.

Yes, if you interpret that very strictly, and always use the oldest possible
form.   Eg: if you (the resolver) want to do a query that you expect might
result in several KB of response (keys and such perhaps) (or which you know
will not fit in a 512 byte UDP response, because of an earlier truncated
response), then you could do edns0 and indicate the buffer size you support,
or you could use traditional dns, and simply do a TCP query.   "the lowest
version which can express a request" would be t-dns, so that would require
TCP.   I don't think that's rational.   On the other hand, if the server
doesn't support edns at all, then TCP is all you can do to get a big response.

Similarly, if you're querying for one of these misc new RR's that are
being created about now, which contain domain names, but can't be compressed
with edns0 (or t-dns) then you probably want to indicate that you support
edns1 (or whatever it takes) to allow the server to compress the names if
it knows the response.   But the "lowest version that can express the
request" is t-dns, the names will just have to be uncompressed in the response.

So, I think there is a middle position here, it isn't "always send the
version number that you support, even if that version adds nothing useful
for this query" nor is it "always use the lowest possible version by which
an answer might be obtained" - more like "use the lowest dns version which
allows an optimal reply to the particular query".

Then we can have fall back in some cases - if an earlier dns version would
allow a less optimal reply containing the same data (uncompressed names, or
making use of TCP as transport).

I don't think we need to enumerate the possible cases, nor to prescribe which
optimisations should be used by default, and which should not, other than
the suggestion that implementations should provide a way to limit the edns
version which is the highest that will be used (which would automatically
inhibit some optimisations).

  | is not impinged thereby."  You see how sticky this whole thing gets?

Yes, if you attempt to set out all the details in a long sentence like
that.   Some of this is just "implementation common sense" though.

  | >   To avoid having a server return a version number error for a simple
  | >   query that can be satisfied without the use of extended DNS
  | >   facilities, a resolver might send a query with a lower version number
  | >   than it supports for certain queries.
  | 
  | This isn't testable so I'm for wording it more strongly or leaving it out.

I would make it stronger.... this is just another way of saying that
resolvers should not send an arbitrarily higher version number than
it needs for a query, just because it has implemented that version
(showing off is not necessary...)

But we don't have to have everything testable, in fact, many things aren't.
We can't actually test that a server sets the version in its responses to
the highest it supports, as long as it sets it to a constant and doesn't use
any features of a higher version.    Thus even though it does no good to
implement a "restrict version number to N" option for servers, there's no
way to tell from outside whether a server has done that or not.   That doesn't
mean that we shouldn't require servers to send the highest version they
support in the spec.

Similarly, we can give some implementation advice, from actual experience
with implementations of the spec, or from general expectation as to what
ought work well.   None of this is testable either, but that doesn't mean
it cannot be included - if it helps make the spec clearer, or helps
implementors avoid common mistakes, then it can be a good idea.

  | > I'd probably also allow resolvers to automatically ignore the configured
  | > limit and send any version they have positive knowledge (from a previous
  | > answer) that a server supports.   In any case, all of this config stuff
  | > is possibly just an implementation issue and could be omitted entirely?
  | 
  | This part of the limiting logic just isn't thought out yet at all, though.

Then we (all) ought be doing some thinking on this, and get something down
we can agree on, so we can get edns0 out the door asap.   In the above though
(which need not go in the spec at all), what I was meaning was just that
a configured resolver "don't send higher than this version" need not be
obeyed by a resolver (if it doesn't want to) if it knows from a previous
reply that a server supports a higher version.   The limit on version to
send is (as I understand it) intended as an optimisation to allow new
resolvers to be deployed efore there are any (or many) servers around that
support their new version (and thus which might tend to have to sometimes
send twice as many queries as really needed, depending upon how it actually
picks what version to send).    The problem with this is that there's no
good way to know when the servers have (mostly) been upgraded, so a resolver
that is installed early, and is then configured not to use its new features,
is quite likely to remain configured that way forever.   If it is permitted
to ignore its configuration and simply send higher versions once it has
learned from a response that the server supports the higher number, then
some of the impacts of this woudl be lessened.

This is all just implementation detail though really, and shouldn't affect
the protocol.

kre

---

From: Thomas Narten <[email-masked]>
Date: Fri, 21 May 1999 11:35:37 -0400

Robert Elz <[email-masked]> writes:

> not a good idea,

Agreed. 

> version it knows (assuming the resolver is doing edns at all).

My thinking here was that if there end up being some sort of
interoperabilty problem with an EDNS server at level N, being able to
specify that they use level N-1 might be a good thing (i.e, disable a
feature that is causing deployment problems). Perhaps servers will
already do that without adding such a suggestion. 

> is possibly just an implementation issue and could be omitted

My thinking again here was if in deployment there are problems with
using EDNSN, for some N, it might be useful to be able to control the
maximum level that gets used. Having the default be to use highest
version supported, is fine. Again, my thinking was that this would be
a safety value in case of deployment problems. Obviously, if resolvers
are able to ignore the configured limit, having one doesn't do much
good.

So if folks feel like the deployment safety valve is unnecessary,
let's just yank it.

> there's no alternative if the server doesn't understand it.

I don't think we really want to say "use the lowest-version number
that expresses a request". It sounds like we don't really know quite
what to do here yet in a lot of detail. What I think would be a good
compromise would be for the text to make it clear that using a lower
version number than the server implements may actually be a good thing
in some cases and leave it at that. I.e., not get into too much detail
about what to do, other than suggest some specific examples where it
might be useful to do something other than send using the highest
level (e.g., to avoid the need to send two queries). The original
wording seemed to disallow using a lower value in a request, and that
seems too strict.

> to the lowest level capable of expressing a request.

The problem with the first sentence is that the nit pickers can argue
that its not 100% correct. I think there is agreement that we don't
want to _disallow_ an implementation from sending different queries
(to the same server) using different version numbers, but the above
wording could be misread to suggest that. Hence, I suggested:

  In a query, VERSION indicates a level that the requestor supports and
  the level the responder should use while processing the request.

Here's an update of the previous proposed text. Barbs/alternate text
encouraged (well the latter anyway).

VERSION:

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 the RCODE=BADVERS response.

If the requestor knows the VERSION level of the server to which it is
sending a query, it sets the VERSION field in the request to the lower
of its own and the server's values. If the requestor does not know
what VERSION level a server supports, it sets the VERSION field of the
request to the highest level it supports. If the server does not
support that version, it will return a RCODE=BADVERS error, and the
requestor can retry using the lower version (assuming the query can be
expressed using a VERSION level implemented by both the requestor and
responder).

To avoid having each new DNS query result in multiple queries to a
server due to version number mismatches, a resolver should maintain a
cache of the servers with which it has recently communicated and the
version numbers they support. To detect changes in server
capabilities, the correctnes of cached entries should be verified
every few hours (e.g., by deleting an entry and allowing a followup
query to an update of the entry).

When a resolver doesn't know the VERSION a server supports, an
implementation might want to avoid having a server return a version
number error for a simple query that can be satisfied without the use
of specific extended DNS facilities. In such cases, a resolver might
send a query with a lower version number than it supports. Further
experience is needed to determine the exact set of circumstances where
using lower version number is recommended.

Resolvers and servers should provide a configuration capability for
disabling the use of the EDNS mechanism or specifying the higest level
that is to be used. [delete this line????]

Thomas