Subject: Re: Last Call: 'Domain Name System (DNS) Case Insensitivity Clarification' to Proposed Standard

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Feb 2005 10:14:58 +1100

> At 23:21 +0000 2/4/05, D. J. Bernstein wrote:
> 
> >But Mark just told us that \067 means c ``wherever domain names are
> >entered.'' That's inconsistent in two ways with what actually happened:
> >
> >    * The server did _not_ accept \067 as a substitute for c.
> >    * The client did _not_ convert \067 to c---which would have worked
> >      around the server's failure to accept \067.
> >
> >I think that the client and server are just fine, and that Mark's
> >comment was a wild exaggeration.
> 
> Perhaps Mark's words are an overstatement.  Looking at RFC 2396 
> (Uniform Resource Identifiers (URI): Generic Syntax), section 3.2.2 
> (Server-based Naming Authority), this text is found (chopped up):

	I stand by my words.  URLs take hostnames.  RFC 2396 just
	described the subset of hostnames that are representable in
	the DNS.

	The encoding applies to applications which take domain
	names.  Most applications, including web browsers, take
	hostnames.  The fact that you can represent most (but not all)
	hostnames in the DNS just adds to the confusion.

	Hostnames of length 254 and 255 cannot be represented in the DNS.

	I don't expect a application that takes a hostname to accept
	\DDD.  I do expect a application that takes a domain name to
	accept \DDD.

	Mail clients take hostnames and/or mail domains (which are
	syntactically identical to hostnames).

	Telnet, ssh, ftp etc. take hostnames.

> #   URL schemes that involve the direct use of an IP-based protocol to a
> #   specified server on the Internet use a common syntax for the server
> #   component of the URI's scheme-specific data:
> #
> #      <userinfo>@<host>:<port>
> ...
> #   The host is a domain name of a network host, or its IPv4 address as a
> #   set of four decimal digit groups separated by ".".  Literal IPv6
> #   addresses are not supported.
> ...
> #      host          = hostname | IPv4address
> ...
> #   Hostnames take the form described in Section 3 of [RFC1034] and
> #   Section 2.1 of [RFC1123]: a sequence of domain labels separated by
> ...
> #   To actually be "Uniform" as a resource locator, a URL hostname should
> #   be a fully qualified domain name.  In practice, however, the host
> #   component may be a local domain literal.
> 
> I find it interesting that section 3 of 1034 is called out here.  The 
> "\DDD" is not defined there, it is defined in RFC 1035 in section 5 
> (MASTER FILES), specifically in 5.1 (Format).
> 
>  From this I would take it that an implementation operating on URLs 
> would not be required to parse the \DDD.  An implementation could, 
> under the mantra "liberal on receipt, conservative on send."
> 
> Still, there is no requirement that an implementation make the entire 
> syntax available to the GUI.  An implementation is free to restrict 
> what it allows to happen in a protocol, so long as it can speak 
> (listen) the entire protocol.
> 
> >I now see that the draft under discussion makes the same wild
> >exaggeration---it talks about all ``human readable and writable ASCII
> >contexts'' rather than just zone files. Consequently I object to the
> >draft as being blatantly inconsistent with (1) other IETF protocols,
> >notably HTTP and SMTP, and (2) many existing user interfaces, such as
> >the Firefox URL line and the qmail rcpthosts configuration-file format.
> 
> "Wild exaggeration" is a bit melodramatic.  It's not like the draft 
> is claiming it would cure the common cold.  But you have a point that 
> it ought to stick to what is in zone files.  Overall, I think this is 
> a rather inconsequential point though, as this abstract and 
> introduction do refer to RFC 1034 and 1035 (and not 2396, for 
> example).
> 
> >I also object to the entire notion of the IETF trying to constrain user
> >interfaces. If the IETF wants to define a zone-file format that can be
> >transferred by FTP, fine---and I'll be happy to defend the goofy use of
> >decimal in zone files for backwards compatibility---but the IETF has no
> >business making declarations regarding _all_ formats.
> 
> I can't make this leap in the argument.  I cannot see that the draft 
> talks about user interfaces, just a (the original, standard) 
> presentation format for DNS.
> 
> You are right that there should never be an IETF effort to restrict 
> what can be in an implementation.  We should stick to what is needed 
> for interoperability, while meeting requirements for functionality, 
> operability, and simplicity.
> 
> With that in mind, there's a protocol reason I can think of for 
> having a master file format defined.  The reason is this offers an 
> alternative to zone transfers via port 53.  At one time (and may 
> still be true) the root zone was "file transferred" and not 
> [A|I]XFR'd.  The root servers are a mix of BIND and NSD, this 
> wouldn't have been possible if NSD didn't have a Master File format 
> to build to.  (One can argue that such an arrangement is outmoded I 
> guess, with VPNs, TSIG, etc.  But changing an institutional practice 
> is sometimes beyond the control of protocol wonks.)
> 
> Beyond the on-the-wire protocol, there are two reasons for specifying 
> a master file formats.  It gives us a common language for discussing 
> the protocol on a list like this.  It also makes it easier to staff a 
> DNS operations center - because there is a pool of people (or firms) 
> that will be able to start "right away."
> 
> Other than that, I don't think master files are important as they do 
> not get passed around on port 53.
> 
> It is important to remember that IETF specifications are for 
> interoperability.  An implementation is free to exceed the 
> specifications, but exceeding it without extending the specification 
> does not guarantee interoperability.
> 
> As a customer for DNS software, I want to know that any 
> implementation I decide to deploy would be compatible with my 
> installed base so that I do not need to have a flag day should I 
> choose to migrate.  I wouldn't object to an implementation with 
> non-standard features, but I would refrain from using them unless it 
> was really compelling to do so.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> "A noble spirit embiggens the smallest man." - Jebediah Springfield
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Feb 2005 07:11:53 -0000

This document specifies \065 as a synonym for capital A---not just in
zone files, but in all ``human readable and writable ASCII contexts.''

That specification is plainly erroneous. Nobody is willing to defend the
notion that this screwy decimal system should be allowed in URLs, SMTP
RCPT, etc.

The obvious fix is to limit the document to zone files.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Peter Koch <[email-masked]>
Date: Tue, 08 Feb 2005 14:33:56 +0100

Mark Andrews <[email-masked]> wrote:

{IESG removed from Cc}

> 	described the subset of hostnames that are representable in

RFC 2396 has recently been obsoleted by RFC 3986. That now uses a Thingy
Formerly Known As Hostname.

> 	Hostnames of length 254 and 255 cannot be represented in the DNS.

Yes, but "domain names" of length 254 or 255 cannot either - due to the fact
that the wire format needs two more octets than the FQDN text representation.

> 	\DDD.  I do expect a application that takes a domain name to

Now it may be time to dig out your long since expired Internet Draft again ...

> 	Telnet, ssh, ftp etc. take hostnames.

Weird enough they should use IDNs - at a different layer, though.

-Peter