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.
You made the following comment:
> Just as a point of interest to section 4.2:
> Microsoft's name server returned SERVFAIL in response to AAAA queries
> at one point; SERVFAIL causes BSD's resolver to return TRY_AGAIN;
> sendmail thinks that TRY_AGAIN means "don't ask this name server any
> more questions", so would never ask for the A record since it always
> tried AAAA first, got TRY_AGAIN, and queued it to be tried again
> later. Sendmail introduced the WorkAroundBrokenAAAA configuration
> option in response, which changes the behavior on TRY_AGAIN.
while this is probably just a comment, not a requirement to address
before publication, I think it's also useful information. So, I'd
like to propose revise the entire section 4.2 (even its title) as
follows:
4.2 Return Other Erroneous Codes
Other authoritative servers return a response with other erroneous
response codes than RCODE 1 ("Name Error"). One well-known such
RCODE is 4 ("Not Implemented"), indicating the servers do not support
the requested type of query.
These cases are less harmful than the previous one; if the stub
resolver falls back to querying for an A RR, the caching server will
process the query correctly and return an appropriate response.
However, these can still cause a serious effect. There was an
authoritative server implementation that returned RCODE 2 ("Server
failure") to queries for AAAA RRs. One widely deployed mail server
implementation with a certain type of resolver library interpreted
this result as an indication of retry and did not fall back to
queries for A RRs, causing failure of message delivery.
If the caching server receives a response with these response codes,
it does not cache the fact that the queried name has no AAAA RR,
resulting in redundant queries for AAAA RRs in the future. The
behavior will waste network bandwidth and increase the load of the
authoritative server.
Using RCODE 1 ("Format error") would cause a similar effect, though
the authors have not seen such implementations yet.
(Note that we now use RFC1035 terminologies to represent RCODEs in
order to address another IESG comment.)
I slightly recall the sendmail incident, but I don't know if it's
still happening, so I used the past tense for this part. If it's
still a today's issue, I'll rephrase that paragraph.
It would be nice if you could let us know whether the above change
makes sense to you.
Thanks,
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
