Subject: [dnsext] FW: I-D Action:draft-wang-improve-dns-resolver-01.txt

From: "Yan Wang" <[email-masked]>
Date: Mon, 25 Oct 2010 18:25:25 +0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, October 25, 2010 6:15 PM
To: [email-masked]
Subject: I-D Action:draft-wang-improve-dns-resolver-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Improving the caching DNS resolvers on "authority
failure"
	Author(s)       : Y. Wang, et al.
	Filename        : draft-wang-improve-dns-resolver-01.txt
	Pages           : 5
	Date            : 2010-10-25

This document provides a new mechanism for caching DNS resolvers.
When all the authoritative name servers for a zone fail, and the request
can't be found in the cache, during a period of time the caching DNS
resolvers won't query the authoritative name servers, but directly return a
SERVFAIL to the clients to reduce the recursive name server load and the
network load.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-wang-improve-dns-resolver-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Oct 2010 22:02:15 +0100

What is the difference between this and RFC 2308 section 7.2?

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Oct 2010 17:42:58 -0400

> What is the difference between this and RFC 2308 section 7.2?

I don't want to put words in the authors' mouths, but this draft
explicitly covers the case where all the authority servers are dead
like under RDC 2308 section 7.2, and provides the response code
(SERVFAIL) for a recursive resolver to return under such a case (which
RFC 2308 section 7.2 does not say).  It's a fairly tiny change, but it
might be addressing a corner case that isn't addressed explicitly
elsewhere.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Oct 2010 22:10:46 +0000

> From: Tony Finch <[email-masked]>
> Date: Mon, 25 Oct 2010 22:02:15 +0100
> 

"unreachable" should have included "all of the zone's primary servers
are answering SERVFAIL or REFUSED".

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Oct 2010 07:27:40 +0900

> might be addressing a corner case that isn't addressed explicitly

RFC1034 says:

: 5.2.3. Temporary failures

: or less often by coincident failure or
: unavailability of all servers for a particular domain.

: other tasks.  The recommended solution is to always have temporary
: failure as one of the possible results of a resolver function, even
: though this may make emulation of existing HOSTS.TXT functions more
: difficult.

						Masataka Ohta

---

From: "Yan Wang" <[email-masked]>
Date: Tue, 26 Oct 2010 17:53:46 +0800

5.2.3. of rfc1034 recommended caching resolver to "have temporary failure as
one of the possible results of a resolver function", but it did not give a
explicit solution, neither did RFC2308 section 7.2.
Our draft is proposing explicit actions of caching resolver (respond with
SERVFAIL directly) during temporary failures of DNS servers (further
including the situation that all of the zone's primary servers are answering
SERVFAIL or REFUSED) to reduce the load of caching resolvers and network
between caching resolvers and name servers.

B.R.
Yan

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Masataka Ohta
> Sent: Tuesday, October 26, 2010 6:28 AM
> To: <[email-masked]>
> Subject: Re: [dnsext] FW: I-D
Action:draft-wang-improve-dns-resolver-01.txt

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Oct 2010 10:55:53 +0000

> SERVFAIL to the clients to reduce the recursive name server load and the

The proposed protocol does not work because a resolver cannot infer
the zone status: The resolver does not know if the erroneous server
behavior is an attribute of the query it sent, and it is impossible to
predict if the same problem would apply to a different query.

I agree that this is an issue worth solving, but it's way more
difficult than the proposed approach.  Perhaps the server could send a
response such as "don't send me any more queries of the form X",
similar to the Kiss-o'-Death packets in NTP.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Oct 2010 12:11:46 +0100

> explicit solution, neither did RFC2308 section 7.2.

It says:

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

and:

   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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Oct 2010 20:54:21 +0900

> predict if the same problem would apply to a different query.

Worse, the servers can not be reached merely because of temporal
network failure around the resolver, in which case, 5 minutes of
delay is *TOOOOOOOOOO* much.

In general, it is wrong to introduce timeout at the network layer
where there is no notion of time, which is partly why ND of IPv6
is unusable.

Timeout, then, could be specified at higher layers.

However, as DNS is designed to let zone administrators specify
zone specific timeout, we should not specify universal timeout
capriciously and leave most, if not all, tasks for zone
administrators.

						Masataka Ohta

---

From: "Yan Wang" <[email-masked]>
Date: Tue, 26 Oct 2010 20:50:39 +0800

In my draft, when I talk about "authority failure" including "all of the
zone's primary servers are answering SERVFAIL or REFUSED" and "all servers
of the zone are dead/unreachable".
I don't think the second paragraph you quote from RFC2308 section 7.2 can
tell us how the caching resolver should respond to the client in that
situation.
I hope that clients can receive a SERVFAIL response directly from resolver
to avoid hopeless queries, to reduce the load.
Thanks.

B.R.
Yan

> [mailto:[email-masked]] On Behalf Of Tony Finch
> Sent: Tuesday, October 26, 2010 7:12 PM
> To: Yan Wang
> Cc: 'Masataka Ohta'; [email-masked]
> Subject: RE: [dnsext] FW: I-D

---

From: "Yan Wang" <[email-masked]>
Date: Tue, 26 Oct 2010 21:36:04 +0800

> [mailto:[email-masked]] On Behalf Of Florian Weimer
> Sent: Tuesday, October 26, 2010 6:56 PM
> To: Yan Wang
> Cc: [email-masked]
> predict if the same problem would apply to a different query.
[Yan Wang] 
I think a resolver can know which name servers are for the zone, also can
know the status of these servers. Zone status can be decided by the status
of these servers.
If a query will be affected can be concluded before it is sent to the name
server of the zone. 

B.R.
Yan

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Oct 2010 14:51:28 +0100

> tell us how the caching resolver should respond to the client in that

I think it is covered by the following text in RFC 2308 section 7.1:

   Server failures fall into two major classes.

   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.

That is, in those situations a client returns a SERVFAIL response. The
final pargraphs of section 7.1 and 7.2 of RFC 2308 say that the server may
cache these responses instead of re-querying the authorities and
re-discovering the problem.

> I hope that clients can receive a SERVFAIL response directly from
> resolver to avoid hopeless queries, to reduce the load.

They can, according to RFC 2308.

Tony.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 27 Oct 2010 09:19:25 +0000

* Yan Wang:

> I think a resolver can know which name servers are for the zone,
> also can know the status of these servers. Zone status can be
> decided by the status of these servers.

Currently, there is no query a server must answer successfully, so it
is impossible to probe the server status reliably.  With DNSSEC, you
could use the DNSKEY RRset at the zone apex.  For classic DNS, the SOA
RR at the zone apex should work, but in reality, it doesn't.
(WWW.QQ.COM/IN/SOA is an example for this anomaly.  WWW.QQ.COM is a
child zone of QQ.COM, but there is no SOA record.)

---

From: "Yan Wang" <[email-masked]>
Date: Thu, 28 Oct 2010 11:22:54 +0800

> Sent: Tuesday, October 26, 2010 9:51 PM
> To: Yan Wang
> re-discovering the problem.
[Yan Wang] 
To my comprehension, the two paragraphs 7.1 and 7.2 mainly focus on servers.

The last paragraph in 7.1 is talking about the resolver:

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

I think it mean that a resolver can cache a SERVFAIL response from the name
server.
But I propose that the resolver should answer the SERVFAIL even if all name
servers of the zone are 
dead/unreachable and no SERVFAIL received from name servers (sometimes it
does happen). 
I also proposed that any queries to the failure zone should be responded
with SERVFAIL, not only against 
the <query name, type,	class, server IP address>, but against the name
servers of the zone.

btw: If a server doesn't respond to a query within 120 seconds, the resolver
can consider that the server is dead.

B.R.
Yan

---

From: Florian Weimer <[email-masked]>
Date: Fri, 29 Oct 2010 07:13:04 +0000

> child zone of QQ.COM, but there is no SOA record.)

Let me clarify this a bit.  I think it would be useful to address the
protocol issue you describe in the draft.  However, it is necessary to
change the specification so that the failure cache works per
QNAME/QCLASS/QTYPE triple, and not per zone.  And you cannot use
responses to RD=1 queries to populate the failure cache because RD=1
queries result in a natural failure rate which is rather high.