>>>>> On Wed, 20 Oct 2004 13:52:40 -0400,
>>>>> Thomas Narten <[EMAIL PROTECTED]> said:
>> >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.
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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
