JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[EMAIL PROTECTED]> writes:
> 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. OK. > >> 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? I first read the words to mean that the caching server was doing the wrong thing... Rereading the text: 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). One question I have is what is the RFC-compliant thing to do? How about for that case saying something like: An RFC XXX compliant caching server implementation transparently returns the broken response (as well as caches it) to the stub resolver. Thomas . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
