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
