Subject: Re: I-D ACTION:draft-ietf-dnsind-rfc2052bis-00.txt

From: "Michael A. Patton" <[email-masked]>
Date: Thu, 3 Sep 1998 17:05:05 EDT

Date: Wed, 02 Sep 1998 12:51:00 -0700
   From: Paul A Vixie <[email-masked]>

   > Could you summarize what the changes are 

   The only difference is the putting back in of the _'s that the RFC Editor
   took out of the draft I'd submitted for Experimental status.  To wit:

Ah, right!  I guess I never read the RFC version, just the original
ID, and I always assumed the underscores were still there.  It doesn't
really work if they're not...could conflict with host names...

	-MAP

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 Sep 1998 23:21:54 +1000

Date:        Thu,  3 Sep 1998 17:05:05 EDT
    From:        "Michael A. Patton" <[email-masked]>
    Message-ID:  <map=[email-masked]>

    It doesn't really work if they're not...could conflict with host names...

Even with the underscores the names could "clash" - but is that a problem?
The services have SRV records, the hosts have A (MX, RP, even maybe WKS)
records, if one name has both A and SRV records, is any harm done?

kre

ps: personally I don't care if the underscores are there or not.

pps: I am still wrestling with the concept of looking up
	_domain._udp..
in order to find the name (and hence addresses) and port number of the
root dns servers...   Nothing I could see in the draft (or current rfc)
exempts the DNS from its procedures.

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 04 Sep 1998 15:36:03 -0400

Well, there is some conflict of control since if someone inadvisidly
had created hosts host1.x.example and ftp.tcp.host1.x.example, then
both the host1 host and the ftp host would want to be controlling RRs
at ftp.tcp.host1.x.example which is a bit messy even if they are
diffent RR types.  In DNSSEC, update authority is related to a name,
not name-type...

Is there any reason why DNS should not be exempt?  The flexibility does
not seem worth the confusion and circularity...

Donald

From:  Robert Elz <[email-masked]>
In-Reply-To:  Your message of "Thu, 03 Sep 1998 17:05:05 EDT."
	                  <map=[email-masked]> 
Date:  Fri, 04 Sep 1998 23:21:54 +1000
Message-Id:  <[email-masked]>

---

From: "Michael A. Patton" <[email-masked]>
Date: Fri, 4 Sep 1998 20:54:12 EDT

From: Robert Elz <[email-masked]>
   Date: Fri, 04 Sep 1998 23:21:54 +1000

They cannot clash with host names.  Hosts cannot have "_" in their
names.  I agree that other DNS uses might include underscores, but
forcing them as the leading character probably avoids most.  There is
no existing standard that includes underscore in DNS...

But, there might already be such a name (and a requirement therefore)
with CNAME records, which does cause a problem.  This is the same
reason we couldn't populate any of the person oriented RRs at LCS when
I was there.  While I was [email-masked] (and still am :-), it was
not possible to put any records related to me at MAP.LCS.MIT.EDU,
because that was an alias, which could not be changed, for one of the
hosts, and thus had a CNAME RR.  (I was _not_ the only person with
this problem.)  In general, it is really bad to use one naming
heirarchy to name distinct types of objects, the underscores are a
cheap way of making a different name space...

	-MAP

---

From: Randy Bush <[email-masked]>
Date: Fri, 4 Sep 1998 23:22:25 -0700 (PDT)

> There is no existing standard that includes underscore in DNS...

RFC2181 [ elipsized ]

11. Name syntax

   ...

   The DNS itself places only one restriction on the particular labels
   that can be used to identify resource records.  That one restriction
   relates to the length of the label and the full name.  ...  Those
   restrictions aside, any binary string whatever can be used as the
   label of any resource record.

randy

---

From: "Michael A. Patton" <[email-masked]>
Date: Sat, 5 Sep 1998 02:32:10 EDT

> There is no existing standard that includes underscore in DNS...
and you responded with this quote from RFC2181

Unfortunately, you took my comment out of context and answered the
wrong question.  I still contend that there is no standard that uses
underscores.  They are certainly _allowed_, otherwise this proposal
for SRV wouldn't fly.  I still contend that so far, the only standards
for names in the DNS do not use underscores in those names.  The
standard for host names specifically exclude them, I don't know about
whether some of the other, less widespread, ones (e.g. for X.400
names) actually exclude them, but they don't call for them, either.

	-MAP

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Sep 1998 03:53:20 +1000

Date:        Fri,  4 Sep 1998 20:54:12 EDT
    From:        "Michael A. Patton" <[email-masked]>
    Message-ID:  <map=[email-masked]>

    names.

I am still waiting for some kind of definition as to what is a "host name".

The best that I cam come up with so far is that it is something that is
entered in hosts.txt.    That isn't very relevant in the modern world.

Aside from that, there is absolutely no reason to standardise what I call
my computer (names like "Fred's PC" would tend to dominate I'd think).

We all kind of vaguelly think we might know what a host name might be,
but when things really come to the crunch, it turns out to be a very
difficult concept to actually define in any kind of rigorous way - and if
the point of doing that would be simply so we can apply an ancient standard
and forbid underscores (and other stuff) in their names, it seems to me that
it would be an utter waste of time bothering to find a definition.

I'd much prefer to simply retire 952 (and its modifications in 1123) to
the dust of ancient history, and let's all forget about restrictions on
names of things whose precise nature we are unable to actually specify.

    But, there might already be such a name (and a requirement therefore)
    with CNAME records, which does cause a problem.

Yes, CNAME would cause problems, if there were such things anywhere with names
that would actually clash, and if they happened to occur in one of the very
obscure few places where the alias couldn't just be made into a canonical
name (the data from the canonical name copied over).   But this and the
DNSSEC argument that Donald made would make me lean just slightly toward
distinguishing the magic SRV names.  I wouldn't do it with underscore for
preference though - if something was needed it ought be something which
really is unlikely to occur (like a dot, or a null, or something).   But
that leaning is only very very slight - I doubt that in practice any of this
really will ever matter at all.

kre

ps: Donald - the comment about DNS lookups requiring SRV lookups to locate
the DNS servers was really not meant to be serious -- though it probably
would be better if the doc was more explicit about just when SRV lookups
should be done and when they shouldn't.    Obviously they can't be for the
DNS itself.   I don't think they'll ever catch on for mail (MX already fills
the need just fine, other than the "no server" case for which there are
workarounds).   How about for traceroute?   Ping?   (echo.icmp.fq.dn ??)

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Sep 1998 05:56:34 +1000

Date:        Sat,  5 Sep 1998 02:32:10 EDT
    From:        "Michael A. Patton" <[email-masked]>
    Message-ID:  <map=[email-masked]>

    I still contend that so far, the only standards
    for names in the DNS do not use underscores in those names.

I'm not aware of anything (don't remember anything) which currently
specifies underscore as legal.   There is however a proposal (not yet
quite an i-d, but soon) for adding "vistual hosts" to ftp, by adding a
"HOST" command to the FTP set (similar to what is done in HTTP) - that
will almost certainly expressly permit underscore in the names.   There
has also been some occasional idle talk in DRUMS about the possibility
of perhaps permitting underscore in host names used for mail (since in
practice people do it anyway).

If I understand correctly, underscore was originally omitted since it was
one of the few ascii characters that wasn't guaranteed everywhere (had
different representations etc).    Since then, underscore has become
standard - it exists everywhere, there's no longer really any reason to
exclude it.

In any case, while underscores might not be permitted right now in the
places where name syntax is specified (ie: where names are transmitted
across the wire) I don't think it would be a good idea to assume that will
hold true for the indefinite future.

kre

---

From: Dennis Glatting <[email-masked]>
Date: Sun, 6 Sep 98 13:35:32 -0700

> If I understand correctly, underscore was originally omitted
> since it was one of the few ascii characters that wasn't
> guaranteed everywhere (had different representations etc).
> Since then, underscore has become standard - it exists
> everywhere, there's no longer really any reason to exclude it.
>

There is the practical problem of many newer generation DNS
servers out there that reject underscores. To suddenly allow
underscores makes those servers incompatible (regardless of
the "check names" option).

One may argue to allow underscores requires the newer
generation servers to upgraded but they aren't the servers we
want upgraded, rather the old and very old ones. By leaving out
underscores we assert, by some small measure, pressure to
upgrade old servers.

-dpg

---

From: John Gilmore <[email-masked]>
Date: Wed, 09 Sep 1998 21:51:11 -0700

Veering onto the techniques-for-distinguishing-names thread:

> ...					This is the same

At one point I proposed using "@" at the end of user names in domain
records, to help with this problem.  I would have also changed the
printable-name parsing so that "@" ends a DNS label, as if it had been
"@."  Thus printable domain name "[email-masked]" would have three
labels, 'gnu@', 'toad', and 'com'.

This could straighten out all the twisted email syntax in SOA records,
and could make KEY or CERT records that relate to an email address
fall into the naming hierarchy naturally, without conflicting with
similar records for hosts.

The idea never seemed to get any traction...

	John

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 14 Sep 1998 15:09:57 -0400

John,

That would have been a great idea it if had been adopted early enough.
At this point, the installed base is so great that you would have to
hack DNS servers that had these sort of names in them to scan the
interior of at least the first label of names they were handed, treat
them as two split at the first @ if there was an embedded @ other than
the last character, and glue them back together again on output if the
query was represented that way.  Otherwise old resolvers that didn't
know to split at an @ wouldn't work.  Seems like too much klugery
given everything else that is going on in DNS and it would break the
internal binary transparency of DNS.

Donald

From:  John Gilmore <[email-masked]>
Message-Id:  <[email-masked]>
To:  "Michael A. Patton" <[email-masked]>
cc:  [email-masked], [email-masked], [email-masked]
In-reply-to:  <map=[email-masked]> 
Date:  Wed, 09 Sep 1998 21:51:11 -0700
Sender:  [email-masked]

---

From: John Gilmore <[email-masked]>
Date: Mon, 14 Sep 1998 13:37:32 -0700

> know to split at an @ wouldn't work.  Seems like too much klugery

Donald,

What are you talking about?

>labels, 'gnu@', 'toad', and 'com'.

I proposed a change in how zone files are parsed, for convenience.
And a change in the recommended label name that the DNSSEC RFC
suggests for storing records related to users.  It's true that
resolvers and user interfaces (like "dig") COULD be changed, but
there's no major backward compatability issue if "@" isn't widely
used by those already.

I don't see a massive installed base of user-related DNSSEC keys (with
the "user" bit on).  And I don't see a massive installed base of
@-signs in SOA records or SIG records (or in domain names in any
RR's).  (Probably the @-signs in existing SOA records would be
*better* handled by this proposal, since they are almost certainly
there by mistake.)

The Berkeley r-commands (rlogin, rsh, etc) were changed to allow the
user to specify "[email-masked]" rather than "-l user host.dom" some
time ago, and I didn't hear any complaints that users suddenly
couldn't access hostnames with @-signs in them...because there weren't
any.

	John

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 14 Sep 1998 19:26:31 -0400

I'm talking about your suggestion to "change the printable name
parsing".  I assumed this was intended to be more or less most places
domain names are used.  If you do that, so that [email-masked] is the
printable/input form of what would now be gnu@.toad.com, you will have
old software that prints it the old way and new software the prints it
the new way.  And you will have confused people that type the old form
into new software and the new form into old software.  And you can
still get that all to work if you make appropriate allowances in the
new software, allowances that could in principle be eventually phased
out as the old software is replaced by new software.

If the installed base of DNS software were small enough, you could
just change it all overnight.  Since it's so widespead, you can't.  So
to make the change you seemed to be suggesting would need kludges such
as I described.  Such kludges are a bad idea for several reasons.
Thus I don't think your idea is a good one for implementation now or
in the forseeable future.  Which is too bad because it would have been
great if it had been incorporated into DNS early enough.

Maybe I shouldn't have bothered with my remarks but I had never seen
the idea before of having "@" be a DNS label terminator that was
included as the last character of the preceeding label...

Donald

From:  John Gilmore <[email-masked]>
Message-Id:  <[email-masked]>
X-Authentication-Warning:  toad.com: Host localhost [127.0.0.1] didn't use HELO proto
col
To:  "Donald E. Eastlake 3rd" <[email-masked]>
cc:  John Gilmore <[email-masked]>, [email-masked]
In-reply-to:  <[email-masked]> 
Date:  Mon, 14 Sep 1998 13:37:32 -0700

---

From: [email-masked]
Date: Tue, 15 Sep 1998 09:07:35 -0700 (PDT)

> And I don't see a massive installed base of

In the in-addr.arpa tree:  578168 visable SOA records.
			     1838 records w/ @-signs in them

--bill