Subject: [dnsop] I-D ACTION:draft-ietf-dnsop-bad-dns-res-02.txt

From: [email-masked]
Date: Wed, 21 Jul 2004 15:29:38 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title		: Observed DNS Resolution Misbehavior
	Author(s)	: M. Larson, P. Barber
	Filename	: draft-ietf-dnsop-bad-dns-res-02.txt
	Pages		: 21
	Date		: 2004-7-21
	
This memo describes DNS name server and resolver behavior that
   results in a significant query volume sent to the root and top-level
   domain (TLD) name servers.  In some cases we recommend minor
   additions to the DNS protocol specification and corresponding changes
   in iterative resolver implementations to alleviate these unnecessary
   queries.  The recommendations made in this document are a direct
   byproduct of observation and analysis of abnormal query traffic
   patterns seen at two of the thirteen root name servers and all
   thirteen com/net TLD name servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dnsop-bad-dns-res-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dnsop-bad-dns-res-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 26 Jul 2004 20:53:31 +0900

>>>>> On Wed, 21 Jul 2004 15:29:38 -0400, 
>>>>> [email-masked] said:

> 	Filename	: draft-ietf-dnsop-bad-dns-res-02.txt

Hmm, the revision number does not seem to be incremented from the
previous one:

DNS Operations                                                 M. Larson
Internet-Draft                                                 P. Barber
Expires: August 16, 2004                                        VeriSign
                                                       February 16, 2004

                  Observed DNS Resolution Misbehavior
                    draft-ietf-dnsop-bad-dns-res-02

But there appear to be differences between the two documents
(non-trivial ones such as the issue date).  And from a quick glance,
the new version does not seem to address my comments on the previous
one:
  http://darkwing.uoregon.edu/~llynch/dnsop/msg02958.html

If this simply means the author decided to reject the comments, then
it's okay (though I'll be sad then).  But at least I've not seen any
responses to the comments, either positive or negative, so I'm making
an explicit note just in case.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Larson, Matt" <[email-masked]>
Date: Tue, 27 Jul 2004 15:02:06 -0400

On Mon, 26 Jul 2004, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> [...]
> (non-trivial ones such as the issue date).

I'm not sure what happened.  I definitely submitted -03 to
[email-masked], but it showed up as -02.

> And from a quick glance,

I did see your comments and I thank you for sending them.  I apologize
for not responding to them until now.  Please see below for my
response.

On Tue, 29 Jun 2004, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> (explicitly cc'ing to the authors)
> 
> >>>>> On Thu, 24 Jun 2004 13:04:08 -0700, 
> >>>>> David Meyer <[email-masked]> said:
> 
> > 	The WGLC on this one was scheduled to end today at 1500
> > 	PDT (GMT/UTC-7). However, there have been several
> > 	comments that need to be resolved before we can go
> > 	forward. We will revisit this one after the authors have
> > 	revised the document.
> 
> In section 2.2.1, the draft says:
> 
>    [...]
>    Implementations that perform lame server caching MUST refrain from
>    sending queries to known lame servers based on a time interval from
>    when the server is discovered to be lame.  [...]
> 
> In general, I agree on this recommendation.  But it might cause a
> rather undesirable result when all authoritative servers seem to be
> lame, since some authoritative server implementations can be lame for
> particular resource record types.  (See Section 4.4 of
> draft-ietf-dnsop-misbehavior-against-aaaa-01.txt for more details)
> 
> Of course, what is wrong here is "lame" authoritative servers.  But
> sometimes we need to explore workaround to deal with real-world's
> problems...

This is true and I overlooked this comment during the revision.
You're right that a sentence or two explaining the unfortunate "lame
by domain name" behavior would be helpful.

> Meanwhile, I'm not sure if the recommendation also applies to the case
> where *all* authoritative servers seem to lame.  In the beginning of
> Section 2.2, the draft says as follows:
> 
>    A more common occurrence is a subset of a zone's name servers being
>    unavailable or misconfigured.
> 
> But I could not be sure if this section (including the recommendation)
> only concentrates on the case where a subset of the servers behave
> badly or it also considers the case where all of them are bad.
> 
> If the intention is the former, then please make it clear throughout
> the section, particularly in Section 2.2.1.
> 
> If the intention is the latter, I hope the document also notes that
> the recommended behavior may sometimes cause undesirable result while
> the behavior generally makes sense.

The section is intended to apply on a per-server basis, i.e., what to
do when a given server is discovered to be lame for a particular zone.
I confess that I re-read the section several times and thought it was
clear.  I could not figure out a way to make it more clear.  Could you
please suggest specific changes?

Matt

.