From owner-freebsd-stable@FreeBSD.ORG Tue Mar 25 18:25:48 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B8B937B404 for ; Tue, 25 Mar 2003 18:25:48 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC6C243FAF for ; Tue, 25 Mar 2003 18:25:47 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0212.cvx21-bradley.dialup.earthlink.net ([209.179.192.212] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18y0bk-0007CA-00; Tue, 25 Mar 2003 18:25:41 -0800 Message-ID: <3E810F54.4E6E0151@mindspring.com> Date: Tue, 25 Mar 2003 18:24:20 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark.Andrews@isc.org References: <200303252102.h2PL2d5Y025441@drugs.dv.isc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a478c1d80597ac31976935d17e46203e09387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Spam-Status: No, hits=-22.5 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,QUOTE_TWICE_1, RCVD_IN_OSIRUSOFT_COM,REFERENCES,REPLY_WITH_QUOTES autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: stable@FreeBSD.ORG Subject: Re: Resolver Issues (non valid hostname characters) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2003 02:25:49 -0000 X-List-Received-Date: Wed, 26 Mar 2003 02:25:49 -0000 Mark.Andrews@isc.org wrote: > 8 bit characters have ALWAYS been legal in the DNS. > > Hostnames when stored in the DNS are still restricted to > the characterset specified in RFC 952. Letters, digits and > hyphen (LDH) for the labels. Yes, of course. > > The root servers were mostly switched over to totally different > > software from bind. 8-(. > > Really. The route operators would be very interested to > know this. Sorry if the information from 14/19/25 Feb 2003 is incorrect. The original claim was for *all* root servers, but I see that it only applies to the "k" root servers. Actually, that was not what was reported/implied by Slashdot; you may want to correct them: http://slashdot.org/article.pl?sid=03/02/25/1635239&mode=thread&tid=95&tid=185 On the RIPE DNS and ICANN RSSAC mailing lists, it's more clear that it only applies to the "k" servers: http://www.ripe.net/ripe/mail-archives/dns-wg/2003/msg00044.html and the new software vendor's press release (Dutch; sorry): http://www.nrc.nl/W2/Nieuws/2001/04/21/Vp/wo.html > > It's probably not very useful to talk about doing this until > > local caching-only name servers on border servers are capable > > of handling the 8-bit, as well. For the RFC's that FreeBSD > > currently complies with, it's right to be strict about this. > > Nameservers and resolvers DO NOT need to be changed to > support IDN. Applications need to know how and when to > perform the translations. FreeBSD's resolver library, which is what's used by local caching DNS servers, needs to know how to deal with this -- in other words, those servers are also in the set "applications", so they "need to know". The FreeBSD resolver library comes from the IPv6 KAME modified versions of the standard "ISC bind" library reference implementation; unfortunately, the last time this was discussed, ISC had not yet released a new reference implementation of the resolver library which was both fully implemented, supported IPv6 adequately from the Japanese perspective, and supported IDN. In addition, because the resolver is still integrated into libc, and there is not a universal threading library support for FreeBSD, transition to the new resolver code, which requires a threaded implementation for some aspects, will be very difficult. Yes, this is a FreeBSD problem; I would personally prefer a free-standing "libresolv", and an ELF linkage of "libc" to "libresolv", which would make updating the library much easier, both now and in the future. Either way, it doesn't matter how many people bitch about not being able to use "_" in their host names, until something other than RFC 952 applies to host names (and to heck with the DNS issues of putting "evil" characters into bind config files). > New / extended API's to lookup and return IDN's are > needed. The application needs to know in advance > that it is going to get IHN (internationalised hostname > name) returned. IHN are a subset of IDN which when > stored in the DNS is a subset of the legal hostnames > which intern are a subset of all domainnames. Yes. We expect these API's to come from ISC. Since there are not any API RFC's that are accepted as anything other than "informational" by the IETF, the only real standard is a defacto one that comes from a reputable source, like ISC. We expect them to be part of a reference implementation, preferably one which provides "optional implementation" of threads-requiring parts of the API, so that the implementation can be split between libc and libc_r on OS's like FreeBSD without current kernel threads support. > > Mostly it's still about domain name speculation, and, IMO, > > will be for a while. I'd say it's about as widely adopted as > > IPv6 -- which is to say: not very. > > > > PS: I was on the DNSINT IETF working group for a while, FWIW. > > Well you obviously do not know what the consensus was or > the correct title (IDN). It was back when it was first starting. I can provide the emails involved, if necessary. 8-). After the Japanese deployment of the UTF-5 based server, I mostly lost interest in the idea, as I greatly dislike UTF in all its forms, since it destroys information that I consider important, like being able to predict the size of a host name buffer or the size of a packet required for a query, or whether UDP can be used, or if TCP is necessary. > For those that want the RFC's and current drafts see > http://www.ietf.org/html.charters/idn-charter.html Regards, -- Terry