[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Pekka Savola <pekkas@netcore.fi>
Cc: dnsop@cafax.se, <yasuhiro@jprs.co.jp>
From: JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>
Date: Wed, 13 Aug 2003 16:54:58 +0900
In-Reply-To: <Pine.LNX.4.44.0308130939150.5778-100000@netcore.fi>
Sender: owner-dnsop@cafax.se
User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI)
Subject: Re: comments about morishita-dnsop-misbehavior-against-aaaa-00

>>>>> On Wed, 13 Aug 2003 10:09:56 +0300 (EEST), 
>>>>> Pekka Savola <pekkas@netcore.fi> said:

>> > 4.3 Ignore Queries for AAAA
>> > [...]
>> >    Again, these servers apparently ignore all queries except those for
>> >    an A RR.
>> 
>> > ==> is this really the case?  Do these servers *also* ignore or return an 
>> > error to queries for NS, MX, SOA, and other resource records (and the text 
>> > was slightly inaccurate), or does it really, really break everything 
>> > except A records (whoops, maybe add a few words of clarification to 
>> > underline that).
>> 
>> This is the case at least about the examples described in the draft.
>> You can even check the behavior described in Section 4.3 by yourself
>> (I just retried and confirmed that it is still the case).

> So it seems, perhaps some stronger words are in order if revising the 
> draft.

Hmm, perhaps I misunderstood your original question.  Did you
actually ask if we checked the problematic server ignored all the
65535 (2^16 - 1) RR types?  If so, the answer is no.  We only tested
against AAAA, MX, SOA, and NS (perhaps A6 or some other types).  Also,
for the "ignore" case, the checking side cannot be sure if the
authoritative server really ignores the query or some intermediate
node drops the query or the response.  That's why we used the word
"apparently" in the draft.

And, you seem to require the authors to be more concrete (for example,
"we tried to send queries for AAAA, MX, SOA, NS, ...and XX, and waited
for yy seconds.  We did not get any responses.")

Not sure if the "redundant but perfectly accurate" wording is the best
way, but I'll keep this in mind for the next revision (if any).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list