[6bone] Re: reverse 6dns painful (was Re: reverse DNSconsideredpointless)

Edward Lewis edlewis at arin.net
Sat Feb 14 08:12:19 PST 2004


At 13:48 +0100 2/14/04, Gert Doering wrote:
>Good point.  Now the interesting question is - are the authors of RFC2782
>aware that they violate DNS host name requirements, or are they even
>doing it *on purpose*, so that...

I have no stance on reverse map for IPv6, but I do think an 
explanation of "what is standard" needs to be cleared up.

The authors are *not* violating "DNS host name requirements."  The 
reigning confusion is over the difference between domain names and 
host names.  DNS does not have host name requirements, per se.  DNS 
has domain name requirements and the DNS documents do make 
recommendations - the recommendations cause the confusion.

In RFC 1034, sect. 3.1, top of page 8, in the middle of the discussion:
     "The rationale for this choice is that we may someday need to add full
     binary domain names for new services; existing services would not be
     changed."
The intent then was to not restrict the contents of domain names.

RFC 1123 is often cited as restricting what is in a label - it is a 
document on host requirements ("Requirements for Internet Hosts -- 
Application and Support").  Adding to the confusion is RFC 1035 which 
has this in it:

# <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
# <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
# <let-dig-hyp> ::= <let-dig> | "-"
# <let-dig> ::= <letter> | <digit>
# <letter> ::= any one of the 52 alphabetic characters A through Z in
# upper case and a through z in lower case
# <digit> ::= any one of the ten digits 0 through 9

This seems to support the restricted names, but when you consider the 
context of this - "Preferred Name Syntax" is the section and the text 
just before this says:

# For example, when naming a mail domain, the user should satisfy both the
# rules of this memo and those in RFC-822.  When creating a new host name,
# the old rules for HOSTS.TXT should be followed.  This avoids problems
# when old software is converted to use domain names.
#
# The following syntax will result in fewer problems with many
# applications that use domain names (e.g., mail, TELNET).

The point is that the restrictions to letters, hypens and digit were 
made in the context of names to be used by common applications of 
that era - telnet, smtp.  The restrictions do not apply to other 
names (labels).

E.g., "aluminim.arin.net." is a domain name representing a host, 
"_tcp.aluminum.arin.net." is a domain name representing the tcp 
services on said host.  The first name is also a host name, so it 
needs to adhere to the rules that will let telnet, ssh work, as well 
as smtp for receiving mail.  However, "_tcp.aluminum.arin.net." is 
not a host name, so there's no expectation that those applications 
will ever have to deal with it.

MS is not violating any standard in using SRV records.  They are 
implementing an IETF proposed standard.  (But before arguing over 
whether that's good or bad read RFC 2026.)

>
>>  | The symbolic name of the desired service, as defined in Assigned
>>  | Numbers [STD 2] or locally.  An underscore (_) is prepended to
>>  | the service identifier to avoid collisions with DNS labels that
>>  | occur in nature.
>
>... no clash with "proper" DNS names can occur?
>
>However, this is not really IPv6 related.
>
>Gert Doering
>         -- NetMaster
>--
>Total number of prefixes smaller than registry allocations:  58081  (57882)
>
>SpaceNet AG                 Mail: netmaster at Space.Net
>Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
>80807 Muenchen              Fax : +49-89-32356-299
>
>_______________________________________________
>6bone mailing list
>6bone at mailman.isi.edu
>http://mailman.isi.edu/mailman/listinfo/6bone

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

History repeats, therefore my life is a rerun.


More information about the 6bone mailing list