Subject: Re: draft-dnsext-edns1-04.txt

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 01 Sep 2002 23:19:19 -0500

on 9/1/2002 6:52 PM [email-masked] wrote:

> 	FORMERR and NOTIMP are good indications as is the lack of a OPT
> 	record in the response to a EDNS query.

Yeah, I meant to include FORMERR and NOTIMPL in the SERVFAIL category.

> 	      discover of EDNS rev is easy compared with discover of
> 	EDNS support.

This does bring up another point however, which is that the heuristics for
failure are different for each different feature/extension. For example,
consider an application which used an extended label type. That particular
application would have its own heuristics apart from the other kinds of
failures which might emerge.

There is also the ugly condition where multiple failures are preventing
progress. In this scenario, multiple fallback conditions may have to be
exercised simultaneously by the requester, although detecting multiple
failures from a single SERVFAIL [...] may not be practical.

In the short term, a generalized protocol for caching errors may make some
sense, as a sister spec to the negative caching spec. Separately, each
application would also have to define its own heuristics as part of any
fallback processing that it also defines (eg, detecting version failure
versus no-EDNS failure).

There is another issue with the proposed use of discrete NS RRs as an
input, which is that a single failing server will mean that all of the
servers for that zone will be marked as non-compliant with the spec in
question. If one of the servers refuses an extension, then that extension
would not be used for any of them for the duration of the error cache.
Whether this is a problem or a feature, I haven't yet decided.

In the loooong term, a mechanism for reporting multiple failures would be
a nice feature (something like a pointer to the problematic field in the
original question, or an array of pointers when multiple problems are
found). I don't think this is feasible currently.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

--
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/>