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