Subject: [Question] What is an accurate meaning of "A server MAY cache a dead server indication"?

From: Hideshi Enokihara <[email-masked]>
Date: Mon, 26 Dec 2005 20:05:06 +0900

Hi all,

I want to confirm regarding the following RFC2308's description.

---------
7.2 Dead / Unreachable Server (OPTIONAL)

   Dead / Unreachable servers are servers that fail to respond in any
   way to a query or where the transport layer has provided an
   indication that the server does not exist or is unreachable.  A
   server may be deemed to be dead or unreachable if it has not
   responded to an outstanding query within 120 seconds.

   Examples of transport layer indications are:

      ICMP error messages indicating host, net or port unreachable.
      TCP resets
      IP stack error messages providing similar indications to those above.

   A server MAY cache a dead server indication.  If it does so it MUST
   NOT be deemed dead for longer than five (5) minutes.  The indication
   MUST be stored against query tuple <query name, type, class, server
   IP address> unless there was a transport layer indication that the
   server does not exist, in which case it applies to all queries to
   that specific IP address.
-----------

Last sentence says, "A server MAY cache a dead server indication.".
I think that "server" should be "resolver"(This "resolver" include a client that have caching function.) in this sentence.

Because section 7.1 says,
-----------

7.1 Server Failure (OPTIONAL)

   Server failures fall into two major classes.  The first is where a
   server can determine that it has been misconfigured for a zone.  This
   may be where it has been listed as a server, but not configured to be
   a server for the zone, or where it has been configured to be a server
   for the zone, but cannot obtain the zone data for some reason.  This
   can occur either because the zone file does not exist or contains
   errors, or because another server from which the zone should have
   been available either did not respond or was unable or unwilling to
   supply the zone.

   The second class is where the server needs to obtain an answer from
   elsewhere, but is unable to do so, due to network failures, other
   servers that don't reply, or return server failure errors, or
   similar.

   In either case a resolver MAY cache a server failure response.  If it
   does so it MUST NOT cache it for longer than five (5) minutes, and it
   MUST be cached against the specific query tuple <query name, type,
   class, server IP address>.
-------------

Last sentence use "a resolver".
This sentence indicate a server and a client with the caching function may cache a server failure response, right?

Is my understanding right?

Best Regards,
-- 
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation

--
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: Florian Weimer <[email-masked]>
Date: Mon, 26 Dec 2005 23:06:05 +0100

> Is my understanding right?

I think so.  If there aren't any objections, you should bring this
issue to the RFC Editor's attention, so that it can be included in the
errata.

---

From: Hideshi Enokihara <[email-masked]>
Date: Tue, 27 Dec 2005 13:54:24 +0900

Thank you for your reply.

On Mon, 26 Dec 2005 23:06:05 +0100

> issue to the RFC Editor's attention, so that it can be included in the

O.K.
I wait other person's opinion for a while.
If there are not any objections, I report this issue to the RFC Editor's attention.

Thanks,

---

From: bert hubert <[email-masked]>
Date: Tue, 27 Dec 2005 14:36:40 +0100

> 7.2 Dead / Unreachable Server (OPTIONAL)
(...)

>    that specific IP address.

For what it's worth, I consider this section to be meddling. It turns out
differing 'dead/unreachable' strategies have differing merits, this should
not be set in stone.

I missed the standardisation process, but maybe somebody cares.

The PowerDNS recursor reserves the right to tune its server selection
process regardless of this RFC.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Dec 2005 19:20:29 +0000

# > 7.2 Dead / Unreachable Server (OPTIONAL)
# 
# The PowerDNS recursor reserves the right to tune its server selection
# process regardless of this RFC.

that's probably why it says "OPTIONAL".

---

From: bert hubert <[email-masked]>
Date: Tue, 27 Dec 2005 21:46:02 +0100

> that's probably why it says "OPTIONAL".

Yes, but if you decide to do it, it tells you how to do it, making the
entire section a bit odd.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 28 Dec 2005 09:35:22 +0900

> entire section a bit odd.

In general, it is a bad idea to introduce timing parameters in
the Internetworking layer protocols including DNS, because proper
timing can be determined only by applications.

Though plain DNS does have several timing parameters in SOA,
they are tunable zone by zone, that is, approximately application
by application, and do not affect applicaiton timing so much.

						Masataka Ohta

---

From: Andras Salamon <[email-masked]>
Date: Fri, 30 Dec 2005 09:01:53 +0200

> that's probably why it says "OPTIONAL".

Yes, but the section also uses "MUST".  If a "MUST" is optional, it is
better written as "SHOULD".

-- Andras Salamon                   [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Fri, 30 Dec 2005 09:28:04 -0500

>process regardless of this RFC.

The above is why I use "interoperability" as the measuring stick 
against which judge the words in an RFC.

The history of documentation in the IETF is thicker than the rules of 
process.  To shed some background on documents like the one above, 
"once upon a time..."

At a meeting, I forget which but one about 5 years ago, there was a 
queue of speakers from ISC on the agenda to talk about a bazillion 
extensions to DNS and descriptions of enhancements that they encoded 
into BIND.  The motivation of these guys was not world domination but 
to be good citizen engineers and document for all the world to see 
"best practice."  I don't just mean best operational practice, but 
also the best way to go about implementing something.

I leaned to a neighbor and remarked that this was rather admirable of 
them - trying hard to fully expose their technology as open source 
folks - even though they seemed to be bent on monopolizing the 
agenda.  I made a disparaging remark about a competing commercial 
vendor to contrast this.

What I want to say is that a lot of documents on DNS in the past ten 
years or so are written from the perspective of (over) eager 
engineers wanting to make the world a better place.  One fault in the 
work is that they optimized for just the one environment in which 
they toiled - the open source Internet.  Keep this in mind when 
judging the works.

What failed the IETF then were two things.  One is that no alternate 
view (of what DNS should be) was taken seriously.  Note that I did 
not say there were no alternate views, nor views aired, but that the 
WG as a whole did not take other views seriously enough.  The other 
failure was in process, quite a few documents got through because 
engineers value progress over due diligence.

No one has ever "standardized" the resolution process in DNS.  I am 
unconvinced that this is a technical problem.  (It could be a policy 
problem.)  The way an process finds an answer to a query is not an 
interoperability issue, the protocol for doing so is.  Ohta's point 
about burning in timers to application protocols is interesting and 
right.

DNS uses UDP.  UDP is unreliable.  UDP packets get lost, as a result 
the sender has to know when to repeat the transmission.  This is not 
a DNS issue, it's a UDP issue.  DNS ought not then specify timers for 
this, but it is a concern for the datagram management element.

The documents on the shelf are there, I am not issuing a recall 
request.  I just want to point out that you need to read them in the 
context of the era in which they were written.  Future documents 
editors need to be more careful, as well as reviewers.  Standard 
track documents need to have a standards tone, other engineering 
ideas ought to be put in non-standards track documents.

I think it's a shame that we sometimes call a document "standards 
track" because it is updating a document that is standards track. 
Especially when the original document muddled standards and "what we 
think is better engineering" ideas.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

3 months to the next trip.  I guess it's finally time to settle down and
find a grocery store.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 30 Dec 2005 17:44:06 +0000

# > that's probably why it says "OPTIONAL".
# 
# Yes, but the section also uses "MUST".  If a "MUST" is optional, it is
# better written as "SHOULD".

agreed, i think.  what the combination means (to me) (in this case) is that
if you don't want to have dead/unreachable server logic, you don't have to,
but if you do want it, it has to work like this.  that makes no sense, and
should have been written with a combination that added up to "if you want 
this particular method of dead/unreachable, here's how to do it".  padlipsky
tried hard to shine light on the "descriptive vs. prescriptive" approach to
protocol design, but apparently not everybody read his book.

fortunately, rfc's can be read very loosely, and the ultimate arbiter of an
implementor's success is interoperability, not conformity.  so if various
folks through the years come up with alternative dead/unreachable server
logics that they either do or don't publish as rfc's, then each one will
succeed or not based on whether it improves the operation of a resolver, and
(perhaps) on whether it degrades the performance of other resolvers/servers,
but never whether it exactly matches what's written in section 7.2 here.

i'm glad our WG chairs are now actively searching for ways to make sure
nothing gets to IESG without strong support and actual review.  this doc,
among many others we've sent up, had neither.  (mea culpa, i helped w/ this.)