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

[Thomas Narten <[e-mail]>]

JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <[e-mail]> 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