Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt

[Jaap Akkerhuis <[e-mail]>]

Executive Summary

 Although I think that most of it is fine, I have an issue with
 section 2.9, "Queries for domain names resembling IP addresses".
 I fear the recommendation(s) in 2.9.1 will create more problems
 then they will solve. Therefore I propose to drop this section.

Details:

Section 2.9 makes the observation that the root servers receive a
lot of queries, which are actually IP numbers and notes that it
would be desirable that these queries won't end up at the root
servers at all. Therefore it is suggested that

	(1) ...  implementors consider the option of synthesizing
	Name Error responses at the iterative resolver.  The server
	could claim authority for synthesized TLD's corresponding
	to the first octet of every possible IP address, e.g. 1.,
	2., through 255.  This behavior could be configurable in
	the (probably unlikely) event that numeric TLDs are ever
	put into use.

or that

	(2) ... root servers delegate these domains to separate
	servers which are currently already delegated the in-addr.arpa
	zones corresponding to RFC 1918 for the AS 112 "black hole"
	project.

Suggestion (1):

 I consider it a bad idea that resolvers synthesize answers for
 some class of specific names as suggested in (1), it is simply not
 in the dns specifications. Making configurable in case numerical
 become existing is not a good idea, because when they do, it will
 be difficult, if not impossible, to have the configurations of all
 caching forwarders changed timely and consistently whenever this
 needs to be done.

Suggestion (2):

 This means the root server operators change the root zone data on
 their own, bypassing the usual channels.

Also:

- The observation in 2.9 concentrates on ipv4 like addresses used
  as names, but that is just a subset of the problem that too many
  queries end up where they don't belong.  There are other ones,
  such as queries for ".localdomain" and I won't be surprised that
  ipv6 like addresses are showing up as well.

- Using technical tricks as suggested tolerates misbehaving resolvers
  or bad configuration issues and thereby removes the motivations
  of getting these things fixed. Where will this stop?

- If these solutions are going to adapted be anyway, there might
  be impact on DNSSEC, which will require further study.

So, in conclusion, I ask the Section 2.9 be dropped from the document.
Although the problem is real, the recommendations to fix it create
more problems then it tries to solve.

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