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

["J-F C. (Jefsey) Morfin" <[e-mail]>]

Full support of this comment, from previous projects using so called 
numeric names (X.121, post codes) and from the current important usage of 
"numeric names" for their soundex meaning in non ASCII countries (China, 
Korea, etc). A generalization of numeric names in considering the current 
DNS character set as "-0Z" numbers is also a simple and culturally 
acceptable way to keep ASCII DNS used for technical purpose or common 
reference in ML.ML environment. Other projects for supporting company EIN 
or individual SSN exist through the world. Introducing such a 
discrimination seems impossible today, even for special projects/TLDs.

There is NO structural difference in DNS between a figure and a character. 
There should not be any in usage and code. Most TLDs impose no restriction 
on all numeric names.

I will note that "domain names resembling IP addresses" was the main 
problem we met 20 years ago when interfacing the DoD ARPA Internet to the 
International public packet switch network . The International names order 
was left to right (left being the root name - in Internet speak the TLD) 
and did not use dots. They added ".arpa" to internet names (see the RFC of 
the time), so we got the names we needed and made them "ARPANAMES" on the 
fly at the gateway. It worked well and we pasted our com, net, ISO 3166 
table as every where. But this created a conflict with IP addresses when 
they also shown-up (when we tested with Telenet too if I am correct). 
Because their reversed concatenation could be understood as an X.121 
address: we supported foreign network addresses as a numeric names in 50 
countries. The solution they agreed and we accepted was the trailing 
dot-root, as IP have no root. We only checked the last byte for a dot or 
not. I do not know the details on the Internet side, but this turned to be 
reliable (I assumed the international support and we got only a few 
problems), but I am sure nobody was really happy with that kind of trick. 
It made the entire interoperability between two major systems depending on 
a single y/n parameter in pasted files by unaccustomed techies (each team 
only had one machine to operate among many others not using that specific 
feature).

I will add that one of the nice feature of numeric names is flexibility 
(for example variable length addresses). You will never prevent people to 
use that flexibility. So, this option will probably meet a lof of 
exceptions. A probable nightmare.

However, experience shows that virtual zones can be proposed in filtering 
all the names to split the load among machines. In particular the "xn--" 
names could be supported by separated servers?
jfc



At 11:42 29/11/2004, Jaap Akkerhuis wrote:
>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

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