Subject: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness

From: Paul Vixie <[email-masked]>
Date: Thu, 24 Jun 2010 09:32:12 +0000

after years of rejections, i finally realized that the ietf reject-o-bot
could be fooled into accepting my internet drafts if i moved the abstract
to the second page, after the boilerplate, and if i stopped tagging the
creation date with "Creation Date:" and stopped representing the creation
date in the same yyyy-mm-dd format as the expiration date, but rather in
"mmmm dd, yyyy" format under the list of author names. what a glorious way
to spend my time.

anyway we can apparently, finally share this.  looks like the URI is:

	http://tools.ietf.org/html/draft-vixie-dnsext-resimprove-00

i'll find out what else has been jammed in my queue, that i'd given up ever
publishing. abstract on the second page, what a hoot.

re:

Subject: New Version Notification for draft-vixie-dnsext-resimprove-00
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked],[email-masked]
Date: Wed, 23 Jun 2010 07:24:46 -0700 (PDT)

A new version of I-D, draft-vixie-dnsext-resimprove-00.txt has been successfully submitted by Paul Vixie and posted to the IETF repository.

Filename:	 draft-vixie-dnsext-resimprove
Revision:	 00
Title:		 Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness
Creation_date:	 2010-06-22
WG ID:		 Independent Submission
Number_of_pages: 6

Abstract:
This document describes several mechanisms which can be employed by
iterative caching DNS resolvers to improve resiliency, robustness,
and responsiveness.  These improvements are optional and they require
no changes to the protocol, or to authority servers, or to DNS stub
resolver clients.

The IETF Secretariat.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 24 Jun 2010 09:43:18 -0700

On 2.6 - I not sure that randomly reducing the TTL as suggested is a
good idea. Instead it may be better to randomise when the record is
revalidated (or prefetched). The difference is that I think that the
resolver should advertise the "honest" decrementing TTL to any
queries. That way if you have a hierarchy of resolvers they aren't
simply making the effective TTL shorter and shorter still.

On 3.4 - I see the security note at 5.1, but still - an attacker might
poison with a long-ttl NXDOMAIN response for "com" or "." and it will
cause a lot of problems for the resolver. As written, it may even
cause the cache to have to purge potentially a large volume of data.
I'm not sure I see the benefit, insulating upstream servers from
slightly more queries seems less important. Are NXDOMAIN subtrees
really a big problem?

On 4.4 - what happens when no nameservers are returned? Sometimes the
nameservers to which a domain have been delegated have incoherent
opinions about where the apex even is. E.g.

   example.com delegates www.example.com to   ns-1.foo.com

   ns-1.foo.com considers itself authoritative for "example.com" and
has a record configured for www.example.com

   A query for www.example.com's NS records would return 0 answers, but NOERROR.

This works right now, and while it's incoherent, it's a relatively
common misconfiguration.

On Thu, Jun 24, 2010 at 2:32 AM, Paul Vixie <[email-masked]> wrote:
> ---------- Forwarded message ----------

-- 
Colm