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

From: [email-masked]
Date: Mon, 02 Sep 2002 09:52:43 +1000

> 
> on 8/22/2002 8:28 PM Paul Vixie wrote:
> 
> > more later.
> 
> I'm going to assume that you've reach a state of torture over the higher
> processing demands from multiple queries, where fallback processing always
> requires two questions to the delegation tree, the first of which always
> results in SERVFAIL.
> 
> Since this is a general problem whenever any new features are added to the
> message by the end-nodes, one way out of this may be to define a
> standardized caching scheme for SERVFAIL (defined as a separate document)
> which tells querying agents how long they should keep track of SERVFAIL
> errors. With this information, a querying agent would only need to
> discover once that a server did not support some feature, and could then
> use this information to avoid making the first query multiple times (at
> least for the duration of the timer value).
> 
> In the context of multiple questions in EDNS1, this would mean that a
> cache which had learned that (say) the root servers did not support EDNS1
> would be able to remember this for a certain amount of time, and that
> cache would be able to proceed directly to the fallback step, without
> having to get the SERVFAIL error first.
> 
> As a first stab towards such an algorithm, I would suggest that the TTL
> for the NS RR query target be used for the seed value, with a reasonable
> upper limit of (say) ~48 hours.
> 
> Example, an EDNS1 query for foo.vix.com is sent to a.root-servers.net, but
> triggers a SERVFAIL error. Upon receipt of this error, the querying node
> examines its cache for the TTL of a.root-servers.net (3,600,000 seconds in
> the default root-cache database, assuming that some other value has not
> yet been learned from an authoritative NS RRset), reduces this value to 48
> hours, and applies the resulting value to the root zone. For the duration
> of that time, the querying node "remembers" not to issue the failing query
> and proceeds to the fallback step in the logic for any subsequent queries.
> So, if another EDNS1 query arrives for www.example.com which would
> normally be sent to f.root-servers.net, the server does not issue the
> query, but instead acts as if a SERVFAIL response has already been
> received for that query.
> 
> This still leaves open the EDNS1-specific question of serialized
> (high-TTL) versus parallel (high-load) fallback queries, but it gets us to
> that point in the logic without having contributed to root meltdown.
> 
> -- 
> Eric A. Hall                                        http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

	Eric,
	      discover of EDNS rev is easy compared with discover of
	EDNS support.  The latter is done by probing and look for
	SERVFAIL or NOTIMP or FORMERR or lack of a OPT record in
	the response of timeouts from servers that don't talk RFC 103[45].
	The former is built into the EDNS spec.

	Note you can't use SERVFAIL by itself to determine if a
	server supports EDNS as it generates too many false positives.
	Similarly lack of response is not a good indication of lack
	of EDNS response.

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

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2002 00:13:31 +0000

> requires two questions to the delegation tree, the first of which always

nope.  i'm just giving up on pleasing you, for now at least.  if i hear from
anyone else i'll assume that EDNS1 is worth pursuing.  otherwise it's dead
and you should just repost the ADDR draft.  i cannot keep up with such high
argument-volume from a single participant unless there is some evidence from
someone else in the community that the effort of continuing would be
worthwhile.

---

From: Derek Atkins <[email-masked]>
Date: 04 Sep 2002 23:06:29 -0400

> someone else in the community that the effort of continuing would be

I think multiple queries is a good idea, if we can work out all
the corner cases.

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Greg Hudson <[email-masked]>
Date: 04 Sep 2002 23:22:10 -0400

> I think multiple queries is a good idea, if we can work out all

Agreed.  And there are a couple of 90% answers to the initial-overhead
problem:

  1. Wait a few years before taking advantage of multiple queries on a
large scale.  Most name servers will have upgraded for other reasons.

  2. Cache (by IP address) whether a name server supports EDNS1. 
Particularly at the stub resolver, this can effectively reduce the
overhead.

---

From: Rob Austein <[email-masked]>
Date: Wed, 04 Sep 2002 23:58:57 -0400

At Thu, 05 Sep 2002 00:13:31 +0000, Paul Vixie wrote:
> 
> if i hear from anyone else i'll assume that EDNS1 is worth pursuing.
> otherwise it's dead and you should just repost the ADDR draft.  i
> cannot keep up with such high argument-volume from a single
> participant unless there is some evidence from someone else in the
> community that the effort of continuing would be worthwhile.

I don't know whether EDNS1 is worth pursuing at this time, and "don't
know" isn't a euphemism for "it's not", I really don't know.

If the caching system is hopelessly screwed and we need to do
something else to let the application forcibly optimize the query
process, I think that EDNS1 is the right "something else" to pursue.

However, since the available evidence to date has not convinced me
that the caching system is hopelessly screwed, I'd rather just let the
caching system do its thing and avoid another nontrivial protocol
change while we're trying to finish DNSSEC.

Not blaming anybody for the lack of hard evidence or running down
Paul's EDNS1 proposal, BTW, just trying to answer Paul's implied
question.