[dnsop] the case of "server failure" against AAAA

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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.
					[e-mail]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html