David J Duchscher wrote:> On Tuesday, March 25, 2003, at 05:03 AM, Terry Lambert wrote: > > > 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. > > I think this is the wrong approach to take with this problem. > Linux, Windows, and Solaris do not enforce this restriction. If > RFC 952 is being thrown out the window, then why should FreeBSD > continue to enforce this restriction? At the moment, the > problems I am seeing have little to do with 8-bit data but > characters outside of the what RFC 952 allows.RFC 952 is in effect until a subsequent standards track RFC is in effect. Just because Linux allows you to specif host names that break other machines, doesn't mean FreeBSD should. "If your friends OS jumped off a cliff...?" This is not that hard to understand: if FreeBSD is going to need to (effectively) rewrite the resolver code, it should be done once, not hundreds of times. It is an expensive proposition. If you want to provide a patch that allows this behaviour to be optional in the FreeBSD resolver, through the use of an "xrfc952" option in the /etc/resolv.conf file, I invite you to submit code. -- Terry
Kevin Oberman wrote:> It should be noted that this limitation was in RFC952 which is not a DNS > specification. See RFC2181. I think our implementation is simply > broken.You mean "bind's implementation, which FreeBSD has adopted, is broken, IYO". People keep saying this, and then not providing source code. -- Terry
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.htmlRegards, -- Terry
Mark.Andrews@isc.org wrote:> David J Duchscher <daved@nostrum.com> wrote: > > It should be noted that this limitation was in RFC952 which is not a DNS > > specification. See RFC2181. I think our implementation is simply > > broken. > > gethostby*(), get*info() all talk RFC 952. They use the > DNS as a database to store records in as they use /etc/hosts > and NIS. gethostbyaddr() and gethostinfo() should not be > returning names that don't comply to RFC 952. > > Like most people you are confusing hostnames and domainnames. > The are NOT the same things. They are in fact overlapping > sets. There are legal hostnames that cannot be stored in > the DNS and the are domainnames that are not hostnames. > > Checking the results returned from a public database is > good engineering practice. NIS and /etc/hosts are local > databases and can be assumed to be correct.Exactly. What Mark said. This will take a lot of code to correct. AFAIK, there is no usable reference implementation for a non RFC-952 restricted resolver library API, nor is there implementation in most intermediate DNS servers, which are consumers of such a library, in order to allow caching-only and slit horizon ("border") DNS servers to do such lookups through such a library, and then internalize the results. I'm sure if someone wanted to step forward and write the code, a lot of OS's would be happy to take it from them. So far, however, RFC-952 has not yet been obsoleted by anything but drafts (see other posting for the reference pointers to IDN). Further, there are complex issues involved in modifying OS libraries, some of them specific to FreeBSD's lack of kernel threads support at the current time, and some of them related to FreeBSD's organizational issues, and some of them related to nothing more than FreeBSD politics. The most damning thing, though, is the total lack of interface definitions by standards bodies, such as X/Open or POSIX. Without these, it's not *possible* to implement a conforming implementation of the code, and any code you do implement is not likely to be conformant to any final standard, unless you place it in the public domain, or under multiple licenses, granted in perpetuity, so that all commercial OS vendors, the BSD's, and the Linux's, can pick it up and *make it* the defacto standard. -- Terry
Marius Strom wrote:> I've submitted a PR for this: misc/50299 documenting the RFC > mis-following (is that a word?) as well as a patch for res_comp.c.Great. If this is committed before RFC-952 is updated, FreeBSD users can now define host names that break other machines on the net which are strictly conformant to RFC-952. What is the first maxim of protocol design? "Be generous in what you accept, strict in what you generate". It would be a mistake to commit this. Please see Mark Andrews fine postings (as well as my own postings) on this topic. -- Terry
At 2003-03-26 01:49:51+0000, Terry Lambert writes:> David J Duchscher wrote: > > On Tuesday, March 25, 2003, at 05:03 AM, Terry Lambert wrote: > > > > > 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. > > > > I think this is the wrong approach to take with this problem. > > Linux, Windows, and Solaris do not enforce this restriction. If > > RFC 952 is being thrown out the window, then why should FreeBSD > > continue to enforce this restriction? At the moment, the > > problems I am seeing have little to do with 8-bit data but > > characters outside of the what RFC 952 allows. > > RFC 952 is in effect until a subsequent standards track RFC is > in effect. Just because Linux allows you to specif host names > that break other machines, doesn't mean FreeBSD should.The relevant standard is STD13 (RFC1034 and RFC1035), which does indeed require LDH for hostnames. 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. There are also some restrictions on the length. Labels must be 63 characters or less. STD3 (RFC1123) modifies this slightly, but still LDH: The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax. In short, underscores in hostnames in the DNS are not permitted by the internet protocol standards. That does not necessarily mean that FreeBSD should enforce this restriction. I'm indifferent to that point. Nick B