Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Fri, 10 December 2004 11:11 UTC

Received: from darkwing.uoregon.edu (darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04034 for <dnsop-archive@lists.ietf.org>; Fri, 10 Dec 2004 06:11:43 -0500 (EST)
Received: from darkwing.uoregon.edu (localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id iBA9FVdL005194; Fri, 10 Dec 2004 01:15:31 -0800 (PST)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id iBA9FVYw005192; Fri, 10 Dec 2004 01:15:31 -0800 (PST)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id iBA9FU31005175 for <dnsop@lists.uoregon.edu>; Fri, 10 Dec 2004 01:15:30 -0800 (PST)
Received: from ocean.jinmei.org (unknown [3ffe:501:100f:1048:5c31:4b60:a406:2638]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 6600D1521B; Fri, 10 Dec 2004 18:15:28 +0900 (JST)
Date: Fri, 10 Dec 2004 18:15:40 +0900
Message-ID: <y7v7jnqfr9f.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: mlarson@verisign.com, pbarber@verisign.com
Cc: dnsop@lists.uoregon.edu, sra@isc.org
Subject: Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt
In-Reply-To: <y7vd5xqljhf.wl@ocean.jinmei.org>
References: <20041119215805.37460418A@thrintun.hactrn.net> <y7vzn6mltfo.wl@ocean.jinmei.org> <y7vd5xqljhf.wl@ocean.jinmei.org>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-dnsop@lists.uoregon.edu
Precedence: bulk
Reply-To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>

>>>>> On Sat, 04 Dec 2004 14:29:00 +0900, 
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:

>> This is a working group last call on the "Observed DNS Resolution
>> Misbehavior" draft, draft-ietf-dnsop-bad-dns-res-03.txt, which we
>> hope to submit to the IESG for consideration as a BCP document.

>> This last call will terminate at 17:00 UTC on 6 December 2004.

>> Please clearly state to the mailing list whether you support or oppose
>> this draft going to the IESG.

>> Please do not express an opinion if you have not read the draft.

>> As always, please discuss substantive issues on the WG mailing list.
>> Minor editorial comments may be sent directly to the draft authors
>> (please CC the WG chairs on any such comments so that we can track
>> this).

> I think my concern to the previous last call (attached below) is still
> there.  It's my bad that I've not sent a proposed text to address this
> that I promised before, but if you give me some more time, I'll make a
> suggestion and send it to the list next week.

Below is my proposed text to address my concern.  I'd first like to
proposed an additional paragraph at the end of section 2.2.  And then
I'd propose some changes in the paragraph of Section 2.2.1.  In the
proposed text I assume we can refer to
draft-ietf-dnsop-misbehavior-against-aaaa-02.txt to provide background
information, but I believe we can also convey the same point without
the reference if we do not want to have an additional reference.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

2.2  Repeated queries to lame servers

[...]

   It should also be noted, however, that some authoritative name
   server behave as lame servers only for queries of some specific
   types [x].  In this case, it makes sense to retry the "lame"
   servers for other types of queries, particularly when all known
   authoritative name servers seem to be "lame".

[x] draft-ietf-dnsop-misbehavior-against-aaaa-02.txt

2.2.1  Recommendation

   Iterative resolvers SHOULD cache name servers that they discover are
   not authoritative for zones delegated to them (i.e.  lame servers).
   Lame servers MUST be cached against the specific query tuple <zone
   name, class, server IP address>.  Zone name can be derived from the
   owner name of the NS record that was referenced to query the name
   server that was discovered to be lame.  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 as long as the implementations know non-lame servers.
   A minimum interval of thirty minutes is RECOMMENDED.  However, it
   still makes sense to keep trying the lame server when all servers
   are seem to be lame as a last resort, in order to workaround the
   type-specific lame servers described in the previous section.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html