Re: Resolver Issues (non valid hostname characters)

2003-03-25 Thread Oliver Fromme
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


Re: Resolver Issues (non valid hostname characters)

2003-03-25 Thread David J Duchscher
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)

2003-03-25 Thread David J Duchscher
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)

2003-03-25 Thread Kevin Oberman
 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)

2003-03-25 Thread Ken Menzel
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)

2003-03-25 Thread Geoffrey
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)

2003-03-25 Thread Marius Strom
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)

2003-03-25 Thread Kevin Oberman
 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)

2003-03-25 Thread Mark . Andrews

 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)

2003-03-25 Thread Mark . Andrews

  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