[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: Tue, 12 Aug 2003 17:46:39 +0900
In-Reply-To: <Pine.LNX.4.44.0308111248400.13622-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 Mon, 11 Aug 2003 13:15:42 +0300 (EEST), 
>>>>> Pekka Savola <pekkas@netcore.fi> said:

> A few comments on:

>        Common Misbehavior against DNS Queries for IPv6 Addresses
>          draft-morishita-dnsop-misbehavior-against-aaaa-00.txt

> In short, I think this is a very well written and a very useful document.  
> I was surprised why it wasn't on the DNSOP agenda in Vienna.

Thanks for the careful reading and the comments.  This is the first
response to the draft as far as I know:-)

> substantial
> -----------

> 4.1 Return NXDOMAIN
                                                                                                  
>    This type of server returns a response with the RCODE being 3
>    (NXDOMAIN) to a query for a AAAA RR, indicating it does not have any
>    RRs of any type for the queried name.  In fact, such a server
>    apparently returns NXDOMAIN to all queries except those for an A RR.

> and:

> 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).

> 4.2 Return NOTIMP
                                                                                                  
>    Other authoritative servers return a response with the RCODE being 4
>    (NOTIMP), indicating the servers do not support the requested type of
>    query.

> [...]

>   Using SERVFAIL or FORMERR would cause the same effect, though the
>    authors have not seen such implementations yet.
                                                                                                  
> ==> I recall faintly that e.g. bind 4.9 series prior to patching some
> years ago returned SERVFAIL?  Maybe also have a look at: 
> http://www.wcug.wwu.edu/lists/ngtrans/200110/msg00123.html

Hmm, I've looked at the ngtrans message, and the latest version of the
internet-draft discussed there, but I could not find a concrete
example.  Could you be more specific please?

Regarding BIND 4.9, I don't have an environment to check the behavior
at least at this moment.  If anyone else could confirm the
information, it would be helpful.

As for editorial comments, we'll take them into account when we ever
have a chance to revise the draft.  (At the moment, I, for one, do not
see the need.)  But in any event, we appreciate all the comments.

Thanks,

					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