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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 20 Oct 2004 18:23:26 +0900

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.
					[email-masked]

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Oct 2004 13:52:40 -0400

> most matches the situation described in our draft.

OK.

> 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:

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   
.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 21 Oct 2004 04:24:17 +0900

>>>>> On Wed, 20 Oct 2004 13:52:40 -0400, 
>>>>> Thomas Narten <[email-masked]> said:

>    returns the broken response (as well as caches it) to the stub

As I said in my previous response, I'm not sure about that.  But from
a quick re-read of RFC1034, my impression is that discarding broken
responses is more compliant.  The RFC says in Section 5.3.3 that:

   4. Analyze the response, either:

	(...)

         d. if the response shows a servers failure or other
            bizarre contents, delete the server from the SLIST and
            go back to step 3.

and then in the same section that

  Step 4 involves analyzing responses.  The resolver should be highly
  paranoid in its parsing of responses.  It should also check that the
  response matches the query it sent using the ID field in the response.

Whether or not my guess is correct, however, I'm a bit reluctant to go
into the details in our draft.  The discussion on the "compliant
caching server behavior" is an off-topic for our draft, and if the
discussion itself is controversial describing it would cause
unnecessary delay.

So, how about just adding a note like this?

  RFC1034 requires that the caching server be paranoid in its parsing
  of responses.  Whether or not this requirement makes either type of
  implementation less RFC-compliant, the point in this document is
  that those two types of implementation are actually deployed,
  causing different effects in terms of the issues described in this
  document.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 22 Oct 2004 04:49:34 +0900

>>>>> On Thu, 21 Oct 2004 04:24:17 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> responses is more compliant.  [...]

>   causing different effects in terms of the issues described in this

Sorry for bothering you again, but I'm about to submit the new draft,
so could you let me know whether this is acceptable?

I basically prefer leaving the current text as is, since the
additional paragraph might cause another controversial and blocking
issue (on the interpretation of the "correct" behavior of a caching
server) even though it's irrelevant to the main subject of the
document.  So, if we can go without the change, it's the best for me.

If you still think we need additional text, please let me know if the
above proposal is okay.

Thanks,

					JINMEI, Tatuya

---

From: Thomas Narten <[email-masked]>
Date: Thu, 21 Oct 2004 21:35:51 -0400

> document.  So, if we can go without the change, it's the best for

Leaving the text unchanged is fine.

Thomas
.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 22 Oct 2004 16:39:59 +0900

>>>>> On Thu, 21 Oct 2004 21:35:51 -0400, 

> Leaving the text unchanged is fine.

Okay, thanks!

					JINMEI, Tatuya