From: Robert Elz <kre@munnari.oz.au>
To: Eliot Lear <elear@cisco.com>
Cc: drums@cs.utk.edu
Subject: Re: Minutes from DRUMS WG, 42nd IETF 
In-Reply-To: Your message of "Thu, 01 Oct 1998 11:53:34 MST."
             <3613CFAD.141576DB@cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Fri, 02 Oct 1998 09:47:30 +1000
Message-Id: <13983.907285650@munnari.OZ.AU>
Sender: kre@munnari.oz.au

    Date:        Thu, 01 Oct 1998 11:53:34 -0700
    From:        Eliot Lear <elear@cisco.com>
    Message-ID:  <3613CFAD.141576DB@cisco.com>

 |  Well, I think a reasonable person could disagree.  RFC 1035 section 3 is
 |  pretty clear on the subject.  Here's what it says, and if it doesn't
 |  govern someone should correct me.

It doesn't.   You are corrected.

I've done this once in private already, and was about to do it again,
but as this is a very common misconception of what 1035 says, let me
go through section 2.3.1 (which is what you quoted from, not section 3)
in detail...  (with apologies to Dan, who has seen most of this before)

We start with the section header ...

     2.3.1. Preferred name syntax
   
That "preferred" isn't just noise you know.

And then, there's the first sentence in the section ...
   
     The DNS specifications attempt to be as general as possible in the rules
     for constructing domain names.  The idea is that the name of any
     existing object can be expressed as a domain name with minimal changes.
   
After that, follows some good advice to those constructing names...
   
     However, when assigning a domain name for an object, the prudent user
     will select a name which satisfies both the rules of the domain system
     and any existing rules for the object, whether these rules are published
     or implied by existing programs.
   
That's for the "prudent user" and is certainly good advice, but most
certainly isn't any kind of requirement of the DNS itself.
   
Then...
   
     For example, when naming a mail domain, the user should satisfy both the
     rules of this memo and those in RFC-822.
   
"For example" ...   in any case, that's certainly true, the rules in 822
need to be followed when naming mail domains (the question that was being
considered where this was mentioned in the minutes) was whether that syntax
might be relaxed a little to permit '_' (actually, it was the 821 part of it
but that isn't important).
   
     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.
   
More good advice.
   
     The following syntax will result in fewer problems with many
     applications that use domain names (e.g., mail, TELNET).
   
"will result in fewer problems" for other applications - not for the DNS
itself.   That's followed by the fairly conservative grammar on names.
   
After the grammar are two notes, the first which explains the case
independance (upper == lower), and the second which restates the grammar
in English, and also adds the length limit on labels.
   
The case equivalence and length limits are also stated in other places,
in the notes here, they are just explanations of the parts of the grammar
which aren't explicit in the grammar itself.  All of the notes are, so if
the part of 2.3.1 you're relying on for your belief in this rule is ...
   
     The labels must follow the rules for ARPANET host names.  They must
     start with a letter, end with a letter or digit, and have as interior
     characters only letters, digits, and hyphen.
   
then you're mis-understanding the intent.   That is simply telling you what
the grammar says (in English), and is clearly sibject to
   
     The following syntax will result in fewer problems with many
     applications that use domain names (e.g., mail, TELNET).
   
which precedes it, and generates the "preferred name syntax" that the whole
section is describing.

There's no DNS rule anywhere which limits the character set used in the DNS.
If you look other places, it even expressly indicates how to include non
printing characters, and such, in master zone files - which would clearly be
a waste of everyone's time if such things weren't legal in the first place.


Now, what section 3 does day is ...

    3. DOMAIN NAME SPACE AND RR DEFINITIONS

    3.1. Name space definitions

Now we're really in the definitions, those headers are clear...

The first two paragraphs are not on point here, so I will skip those.
The third reads...

    Although labels can contain any 8 bit values in octets that make up a
    label, it is strongly recommended that labels follow the preferred
    syntax described elsewhere in this memo, which is compatible with
    existing host naming conventions.  Name servers and resolvers must
    compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
    with zero parity.  Non-alphabetic codes must match exactly.

Read that one more time slowly...

	Although labels can contain any 8 bit values in octets that make up a
	label,

Do we need anything more clear than that?  And then just to reinforce that
section 2.3.1 (which contains the grammar you quoted) is not mandatory...

	it is strongly recommended that labels follow the preferred
	syntax described elsewhere in this memo, which is compatible with
	existing host naming conventions.

"strongly recommended"...   not required, with the point being to remain
compatible with the old conventions.

And just in case (or rather, because) people so commonly mis-read that
grammar in section 2.3.1 of rfc1035, section 10 of rfc2181 was written.


Now for mail, there's no question, 821 and 822 define what's legal, and
unless we change it here, that's what mailers have to comply with.

Finally ...

 |  Also, some DNS implementations may reject domains with an underscore.

Yes, those are broken.   It is however, a problem.   Fortunately, unless
even more mis-configured than they are shipped by default, that implementation
only generally rejectes names when they're loaded into the primary server,
and can be configured not to do that - so if you have a local name that
contains characters that it considers to be "bad", you can fairly easily
configure it to leave your names alone.   Aside from that, the resolver that
accompanies that server is also broken, and will reject names with "bad"
characters in them - that one is much harder to correct, and affects much
more, but fortunately, is much less widely installed than the server is
(changing resolvers is lots more work, and much less crucial in general,
than updating the server, so far fewer numbers of people bother).

kre