Re: Resolver Issues (non valid hostname characters)
> > Date: Tue, 25 Mar 2003 14:07:24 -0600 > > From: David J Duchscher <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > 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. > > 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. > >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. Similarly, any binary string can serve as the value >of any record that includes a domain name as some or all of its value >(SOA, NS, MX, PTR, CNAME, and any others that may be added). >Implementations of the DNS protocols must not place any restrictions >on the labels that can be used. In particular, DNS servers must not >refuse to serve a zone because it contains labels that might not be >acceptable to some DNS client programs. A DNS server may be >configurable to issue warnings when loading, or even to refuse to >load, a primary zone containing labels that might be considered >questionable, however this should not happen by default. 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. Mark > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
> David J Duchscher wrote: > > It seems that the use of invalid characters in hostnames is cropping > > up more and more. Besides complaining to the offending site which > > often doesn't work, I was wondering if these restrictions on FreeBSD > > should be re-examined. At this time, it seems that many OSes are no > > longer enforcing this requirement or never have. In my case, I am > > running into a hostnames with an underscore character in the name. It > > seems that Linux, MacOS X, Solaris and Windows all allow this hostname > > to resolve but FreeBSD, as well as the other *BSD, reject it. Should > > FreeBSD follow suit? > > Welcome to DNSINT. > > Specifically, restrictions were relaxed on the root level servers; > this was generally announced about a month ago. All data is 8-bit > now, but not all DNS servers can handle it (e.g. try putting a tab > or space or whatever in a zone name, which is now legal). 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. > 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. $ for s in a b c d e f g h i j k l m > do > echo $s `dig9 +short version.bind txt chaos +norec @$s.root-servers.net` > done a "VGRS2" b "8.2.5-REL" c "8.3.3-REL" d "8.3.1-REL" e "8.3.3-REL" f "9.2.2" g h "8.3.4-REL" i "8.2.3-REL" j "VGRS2" k l "BIND-8.3.1-MA-PATCH-JMB-01" m "8.3.4-REL" $ > The specific reasons were for support of Big5 due to increased > political pressure coming from China. See the ICANN web site > for details. > > Personally, I think it's to make it harder to cut-and-paste > domain names from SPAM to find the responsible party (chars > in Big5 don't go over very well in ISO 8859-1, and end up > being shell escapes, etc.). > > The answer is that it will have to be supported when DNSINT is > supported (but nit until then; significant resolver library > changes, which are not easy, are required, etc.). IDN (internationalised domain name) requires a translation layer ABOVE the DNS to translate the extended hostname range (which is not every UNICODE character) into LDH and back. > 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. 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. > 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). For those that want the RFC's and current drafts see http://www.ietf.org/html.charters/idn-charter.html Mark > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message -- Mark Andrews, Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
> Date: Tue, 25 Mar 2003 16:46:27 -0600 > From: Marius Strom <[EMAIL PROTECTED]> > > 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. As Mark Andrews pointed out in a private message, this is not a BIND issue. It's a resolver issue. The resolver does enforce the RFC limiting the characters used for host names in accordance with the RFC. BIND will handle anything. A big issue is that ICANN appears to have authorized internationalized names and those appear certain to break LOTS of things. But this PR is probably not correct as BIND does adhere to the RFC. RFC952 still holds sway as confirmed in RFC1123. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
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. On Tue, 25 Mar 2003, Kevin Oberman wrote: > > Date: Tue, 25 Mar 2003 14:07:24 -0600 > > From: David J Duchscher <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > 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. > > 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. > >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. Similarly, any binary string can serve as the value >of any record that includes a domain name as some or all of its value >(SOA, NS, MX, PTR, CNAME, and any others that may be added). >Implementations of the DNS protocols must not place any restrictions >on the labels that can be used. In particular, DNS servers must not >refuse to serve a zone because it contains labels that might not be >acceptable to some DNS client programs. A DNS server may be >configurable to issue warnings when loading, or even to refuse to >load, a primary zone containing labels that might be considered >questionable, however this should not happen by default. > > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message > -- /-> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-| Alan Frame |--> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
On Tue, 25 Mar 2003, 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. > >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. Similarly, any binary string can serve as the value >of any record that includes a domain name as some or all of its value >(SOA, NS, MX, PTR, CNAME, and any others that may be added). >Implementations of the DNS protocols must not place any restrictions >on the labels that can be used. In particular, DNS servers must not >refuse to serve a zone because it contains labels that might not be >acceptable to some DNS client programs. A DNS server may be >configurable to issue warnings when loading, or even to refuse to >load, a primary zone containing labels that might be considered >questionable, however this should not happen by default. > Before anyone considers removing restrictions, I hope consideration is given to the very real probability of vulnerabilities in bind which may have much more interesting implications as a result of the same. Test, test, fix, probe, fix and test some more before considering this please. At least then when the vulns happen (and they will), there will at least be a starting point to implement a fix. "You cannot deftly manipulate the control stick if you are suffering from diarrhoea"- [from a manual for Japanese Kamikaze pilots] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
I understand, even though the DNS server, windows linux, nslookup
and dig see the name, you can't get to it with any tool using the
resolver. BTW if you put the name in /etc/hosts you can still use it
with ping etc (this fooled me!), but it won't allow it from DNS. Why
wouldn't we use the same rules on the hosts file? Should etc/hosts be
'looser'?
Ken
- Original Message -
From: "David J Duchscher" <[EMAIL PROTECTED]>
To: "Ken Menzel" <[EMAIL PROTECTED]>
Cc: "Marius Strom" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 2:55 PM
Subject: Re: Resolver Issues (non valid hostname characters)
> Try pinging this 'dont_work.net.tamu.edu'. Then try doing a
> nslookup or dig on the name. You will find that in
> /usr/src/lib/libc/net/res_comp.c at line 133 in the function
> res_hnok() the code that restricts DNS queries to RFC 952.
>
> DaveD
>
> On Tuesday, March 25, 2003, at 10:39 AM, Ken Menzel wrote:
>
> > hi,
> > I am not sure where you think freebsd needs support for
underscores in
> > the resolver.
> > freebsd2# hostname -s free_bsd2
> > freebsd2# hostname
> > free_bsd2.icarz.com
> > freebsd2#vi /etc/hosts (edit host file here adding new name)
> > freebsd2# ping free_bsd2
> > PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes
> > 64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms
> > freebsd2# su
> > free_bsd2#
> >
> > If you are having trouble with bind try 'check-names ignore;'
> > zone "_msdcs.icarz.com" {
> > type master;
> > file "_msdcs.icarz.com.db";
> > allow-update { dmcs; 127.0.0.1; };
> > check-names ignore;
> > };
> >
> > If that is not what you mean please be more specific.
> > Best of luck, hope this helps.
> > Ken
> >
> > - Original Message -
> > From: "Marius Strom" <[EMAIL PROTECTED]>
> > To: "David J Duchscher" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Tuesday, March 25, 2003 10:59 AM
> > Subject: Re: Resolver Issues (non valid hostname characters)
> >
> >
> >> FWIW, I've been having trouble with domains that in particular
have
> > '_'
> >> in the hostname.
> >>
> >> I know it violates RFC952, but lots of people are using them now,
> > for
> >> good or bad. How about a compile-time flag to allow a "looser"
> >> adherence to the RFC? (Yeah, I know this would likely be gross,
and
> > thus
> >> I'll defer to people who are more familiar with FreeBSD internals
> > here)
> >>
> >> On Mon, 24 Mar 2003, Dave Duchscher wrote:
> >>> It seems that the use of invalid characters in hostnames is
> > cropping
> >>> up more and more. Besides complaining to the offending site
which
> >>> often doesn't work, I was wondering if these restrictions on
> > FreeBSD
> >>> should be re-examined. At this time, it seems that many OSes
are
> > no
> >>> longer enforcing this requirement or never have. In my case, I
am
> >>> running into a hostnames with an underscore character in the
name.
> > It
> >>> seems that Linux, MacOS X, Solaris and Windows all allow this
> > hostname
> >>> to resolve but FreeBSD, as well as the other *BSD, reject it.
> > Should
> >>> FreeBSD follow suit?
> >>>
> >>> DaveD
> >>>
> >>>
> >>> To Unsubscribe: send mail to [EMAIL PROTECTED]
> >>> with "unsubscribe freebsd-stable" in the body of the message
> >>>
> >>
> >> --
> >>
> > /->
> >> Marius Strom | Always carry a short length of
fibre-optic
> > cable.
> >> Professional Geek | If you get lost, then you can drop it on
> > the
> >> System/Network Admin | ground, wait 10 minutes, and ask the
> > backhoe
> >> http://www.marius.org/ | operator how to get back to
civilization.
> >>\-| Alan Frame
> > |-->
> >>
> >> To Unsubscribe: send mail to [EMAIL PROTECTED]
> >> with "unsubscribe freebsd-stable" in the body of the message
> >>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
> Date: Tue, 25 Mar 2003 14:07:24 -0600 > From: David J Duchscher <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > 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. 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. 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. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. A DNS server may be configurable to issue warnings when loading, or even to refuse to load, a primary zone containing labels that might be considered questionable, however this should not happen by default. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
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. DaveD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
Try pinging this 'dont_work.net.tamu.edu'. Then try doing a
nslookup or dig on the name. You will find that in
/usr/src/lib/libc/net/res_comp.c at line 133 in the function
res_hnok() the code that restricts DNS queries to RFC 952.
DaveD
On Tuesday, March 25, 2003, at 10:39 AM, Ken Menzel wrote:
hi,
I am not sure where you think freebsd needs support for underscores in
the resolver.
freebsd2# hostname -s free_bsd2
freebsd2# hostname
free_bsd2.icarz.com
freebsd2#vi /etc/hosts (edit host file here adding new name)
freebsd2# ping free_bsd2
PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes
64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms
freebsd2# su
free_bsd2#
If you are having trouble with bind try 'check-names ignore;'
zone "_msdcs.icarz.com" {
type master;
file "_msdcs.icarz.com.db";
allow-update { dmcs; 127.0.0.1; };
check-names ignore;
};
If that is not what you mean please be more specific.
Best of luck, hope this helps.
Ken
- Original Message -
From: "Marius Strom" <[EMAIL PROTECTED]>
To: "David J Duchscher" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 10:59 AM
Subject: Re: Resolver Issues (non valid hostname characters)
FWIW, I've been having trouble with domains that in particular have
'_'
in the hostname.
I know it violates RFC952, but lots of people are using them now,
for
good or bad. How about a compile-time flag to allow a "looser"
adherence to the RFC? (Yeah, I know this would likely be gross, and
thus
I'll defer to people who are more familiar with FreeBSD internals
here)
On Mon, 24 Mar 2003, Dave Duchscher wrote:
It seems that the use of invalid characters in hostnames is
cropping
up more and more. Besides complaining to the offending site which
often doesn't work, I was wondering if these restrictions on
FreeBSD
should be re-examined. At this time, it seems that many OSes are
no
longer enforcing this requirement or never have. In my case, I am
running into a hostnames with an underscore character in the name.
It
seems that Linux, MacOS X, Solaris and Windows all allow this
hostname
to resolve but FreeBSD, as well as the other *BSD, reject it.
Should
FreeBSD follow suit?
DaveD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
--
/->
Marius Strom | Always carry a short length of fibre-optic
cable.
Professional Geek | If you get lost, then you can drop it on
the
System/Network Admin | ground, wait 10 minutes, and ask the
backhoe
http://www.marius.org/ | operator how to get back to civilization.
\-| Alan Frame
|-->
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Resolver Issues (non valid hostname characters)
Ken Menzel <[EMAIL PROTECTED]> wrote: > I am not sure where you think freebsd needs support for underscores in > the resolver. > freebsd2# hostname -s free_bsd2 > freebsd2# hostname > free_bsd2.icarz.com > freebsd2#vi /etc/hosts (edit host file here adding new name) > freebsd2# ping free_bsd2 > PING free_bsd2.icarz.com (207.99.22.11): 56 data bytes > 64 bytes from 207.99.22.11: icmp_seq=0 ttl=64 time=0.128 ms Neither the machine's hostname nor /etc/hosts have got anything to do with DNS or BIND. In fact, you can set the machine's hostname to anything you like, including not setting it at all, or setting it to something completely different from the machine's DNS name. It might confuse a few programs or scripts, though. In fact, I was working for some time on a Solaris machine before I noticed that its hostname was "-s" (yes, a dash followed by the letter s). It turned out that a cow-orker had run a configure script of some crappy Linux software a few days before. That configure script used "hostname -s" to find out the hostname, but that particular version of Solaris did not support that option. Instead, it just set the hostname to whatever was given as the first argument. On another pool of machines, /etc/hosts contains MAC addresses. Those wouldn't be legal names in DNS (because of the colons), but they work perfectly fine in /etc/hosts, so you can easily lookup and ping MAC addresses. That has been very handy in that environment. But in DNS, anything except letters, digits and dashes is not allowed (apart from the separating dots, of course). Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "If you do things right, people won't be sure you've done anything at all." -- God in Futurama season 4 episode 8 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
