IETF Logo Mail Archive

[dnsop] response to comments on dnsop-misbehavior-against-aaaa-01

JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Wed, 20 October 2004 10:41 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 GAA19486 for <dnsop-archive@lists.ietf.org>; Wed, 20 Oct 2004 06:41:49 -0400 (EDT)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.12.11/8.12.11) with ESMTP id i9K9NZrJ028751; Wed, 20 Oct 2004 02:23:35 -0700 (PDT)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.12.11/8.12.11/Submit) id i9K9NZg6028750; Wed, 20 Oct 2004 02:23:35 -0700 (PDT)
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 i9K9NR7b028719 for <dnsop@lists.uoregon.edu>; Wed, 20 Oct 2004 02:23:27 -0700 (PDT)
Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 0729815210; Wed, 20 Oct 2004 18:23:25 +0900 (JST)
Date: Wed, 20 Oct 2004 18:23:26 +0900
Message-ID: <y7vlle1n3ox.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: narten@us.ibm.com
Cc: dnsop@lists.uoregon.edu
Subject: [dnsop] response to comments on dnsop-misbehavior-against-aaaa-01
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>

Hello,

I'm now going to revise the following draft
draft-ietf-dnsop-misbehavior-against-aaaa-01.txt
based on IESG comments available on the I-D tracker page.  I have some
questions on your comments:

>>    for a AAAA RR of the name with the RCODE being 0 (indicating no
>>    error) and with an empty answer section [1]. Such a response

> [1] should point to RFC 1035, not 1034 (could also point to both).

Why do you think this should be RFC1035?  We referred to RFC1034 since
it defines the standard algorithm for an authoritative server to
process queries.  Also, RFC1034 shows an example in Section 6.2.4 that
most matches the situation described in our draft.

>>    A widely deployed caching server implementation transparently returns
>>    the broken response (as well as caches it) to the stub resolver.
>>    Another known server implementation parses the response by
>>    themselves, and sends a separate response with the RCODE being 2
>>    (SERVFAIL).

>But, isn't returning the "malformed" response the right thing to do?
>The above makes it sound like the caching server has a bug. Caching
>servers do not necessarily understand the format of the RRs they
>cache...

Honestly speaking, I don't know which is the right thing,
protocol-wise.  But in any event, we did not intend to mean either one
is "right".  We just wanted to point out there are two types of
caching servers, causing different effects in terms of the main
subject in our draft.

Are you suggesting by this comment to clarify that the intent is not
to declare the "right" behavior of a caching server?  If so, I'll do
that.  Or are you just showing a general impression, without
particularly requiring a change to the draft?

					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

v2.23.0 | Report a Bug | By Email