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

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

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/

--
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: [email-masked]
Date: Mon, 02 Sep 2002 09:52:43 +1000

> that point in the logic without having contributed to root meltdown.

	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]

---

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

> 	record in the response to a EDNS query.

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

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

---

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.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2002 08:20:09 +0000

> Agreed.

gentlemen, thank you for those affirmations, let's keep pushing EDNS1 then.

i'll ask eric to find an intermediary -- rob a. would be ideal -- to try
to collate and communicate his (eric's) concerns, since i'm having a LOT
of trouble digesting them directly.

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

i thought that kre's analysis of this was on point -- there is no problem.

> large scale.  Most name servers will have upgraded for other reasons.

i wish that i agreed with that second sentence, but the surveys still show
an awful lot of bind4.8.1 servers out on the net, plus others more recent.

> Particularly at the stub resolver, this can effectively reduce the

this is mentioned, obliquely, in EDNS0:

   5.3. Responders who do not understand these protocol extensions are
   expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL.
   Therefore use of extensions should be ``probed'' such that a responder
   who isn't known to support them be allowed a retry with no extensions if
   it responds with such an RCODE.  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.

i think this is the part rob a. had trouble with, that begat edns0.5.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2002 08:37:35 +0000

> Paul's EDNS1 proposal, BTW, just trying to answer Paul's implied

i think kre's analysis applies here, so i won't repeat it, but i will
put in my own two bits.  caching, specifically negative caching, can
speed up the total dns transaction time and thus cut down the interval
between "when you know where you want to go" and "when you can initiate
your session".  this is critical for overall "internet" performance,
perhaps more significant than the bits per second per flow will be in
the average case.

i won't quibble about the lack of negative caching deployment, since
EDNS1 would have a similar deployment mountain to climb.

however, the cost of a cache miss will be higher with two full round
trips from the intermediate server to the authority server than it is
with one.  if we expect AAAA and A, or MX and A, or all three, to be a
common query pattern in the future, and if we expect any diversity among
query patterns (such that some clients might query in one order while
others query in some other order), then new successful flows will remain
expensive due to the (positive) cache misses and new error flows will
remain expensive due to the (negative) cache misses.  forever.

i see multiple queries as (1) an intended part of the original
architecture which was left underspecified, and (2) a necessary feature
in the long run if we don't want dns to remain a significant part of our
total transaction or session initiation times.

---

From: Derek Atkins <[email-masked]>
Date: 05 Sep 2002 09:37:53 -0400

> total transaction or session initiation times.

When I first started playing with DNS implementations in '95 I was
very surprised to find out that one could not send multiple queries in
one message.  What's the point of the query count if the value _must_
be 1?

At the time, I was working on a Secure Dynamic Update implementation
and, as I recall having multiple queries would have helped me
significantly.

In other words, I agree COMPLETELY that multiple queries were an
intended part of the original archicture, but I also believe that (at
the time) there were too many potential issues (corner cases) so
people didn't want to cope.

-derek

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2002 14:28:51 +0000

> people didn't want to cope.

i don't think they were de-coped at specification time.  older versions
of bind did not even check QDCOUNT at query time -- they just decoded a
single QNAME, QCLASS, and QTYPE and assumed that this left them pointing
at the first thing in the answer section.  in one of my early sweeps, i
chose to put in "if (qdcount != 1) fail" rather than a "for" loop, since
the meaning of "(qdcount > 1)" was completely unclear in RFC 1035.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 05 Sep 2002 10:58:12 -0500

on 9/5/2002 3:20 AM Paul Vixie wrote:

> i'll ask eric to find an intermediary

Suggesting that I be filtered to avoid your problem with ~too many
questions is absurd.

A reminder seems in order here, EDNS1 was dead *before* I restarted the
discussion on multiple questions (see <[email-masked]>). You
can either answer the questions I ask or answer them when they are asked
by somebody else or let EDNS1 die again, but if you kill it again or if it
is killed again, it certainly won't be my fault.