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

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Sat, 04 December 2004 07:15 UTC

Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04149 for <dnsop-archive@lists.ietf.org>; Sat, 4 Dec 2004 02:15:58 -0500 (EST)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id iB45T8GB000292; Fri, 3 Dec 2004 21:29:08 -0800 (PST)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id iB45T8mQ000291; Fri, 3 Dec 2004 21:29:08 -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 iB45T6xl000277 for <dnsop@lists.uoregon.edu>; Fri, 3 Dec 2004 21:29:07 -0800 (PST)
Received: from ocean.jinmei.org (PPP327.air128.dti.ne.jp [210.170.213.104]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4C5E815210; Sat, 4 Dec 2004 14:28:57 +0900 (JST)
Date: Sat, 04 Dec 2004 14:29:00 +0900
Message-ID: <y7vd5xqljhf.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: Rob Austein <sra@isc.org>
Cc: dnsop@lists.uoregon.edu
Subject: Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt
In-Reply-To: <20041119215805.37460418A@thrintun.hactrn.net> <y7vzn6mltfo.wl@ocean.jinmei.org>
References: <20041119215805.37460418A@thrintun.hactrn.net>
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: multipart/mixed; boundary="Multipart_Sat_Dec__4_14:29:00_2004-1"
Sender: owner-dnsop@lists.uoregon.edu
Precedence: bulk
Reply-To: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>

>>>>> On Fri, 19 Nov 2004 16:58:05 -0500, 
>>>>> Rob Austein <sra@isc.org> 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.

Thanks,

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

--- Begin Message ---
(explicitly cc'ing to the authors)

>>>>> On Thu, 24 Jun 2004 13:04:08 -0700, 
>>>>> David Meyer <dmm@1-4-5.net> 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...

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.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
--- End Message ---