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
