Underscores are not legal in domain names. See the following
references.
RFC 1123, Section 2.1:
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.
RFC 952, ASSUMPTIONS para 1:
A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period.
RFC 1035, Section 2.3.1:
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.
--
Michael Fuhr
http://www.dimensional.com/~mfuhr/
It's a bug if it has a segmentation fault. Try 4.9.5-P1 and if
it still has a fault put the core and binary to one side and
send me a stack trace.
Mark
- Jared
M.A. Walker graced my mailbox with this long sought knowledge:
> Are underscores allowed in Domain Names? The bind version 4.9.5 produces a
> _segmentation fault_ error when starting named if there are any
> underscores in the domain names of the db files. Is this a bug?
>
--
"So I'm driving down the street at 150 -- In the back seat with a friend, and
Cruise control on. The police pull us over, and don't know who to arrest."
--
Jared Mauch - CICNet - ja...@cic.net - http://www.cic.net/ - visit my personal
page at http://puck.nether.net/~jared/
> Are underscores allowed in Domain Names? The bind version 4.9.5 produces a
> _segmentation fault_ error when starting named if there are any
> underscores in the domain names of the db files. Is this a bug?
They are illegal. 4.9.5 should be logging complaints about it
though...not dying.
------------------------------------------------------------------
Jon Lewis <jle...@fdt.net> | Unsolicited commercial e-mail will
Network Administrator | be proof-read for $199/hr.
________Finger jle...@inorganic5.fdt.net for PGP public key_______
--Ben Croswell
Compuserve Inc.
_____________________________________________________________________________
> Per rfc, underscores are invalid characters in dns names. Replace
> them all with hyphens.
No. Per RFCs, underscores are not allowed in host names. There is no
prohibition on underscores in DNS names that are not host
names. Replace underscores in A records (left column) and PTR records
(right column) with hyphens.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
>Jared Mauch <ja...@puck.nether.net> writes:
>> Per rfc, underscores are invalid characters in dns names. Replace
>> them all with hyphens.
>No. Per RFCs, underscores are not allowed in host names. There is no
>prohibition on underscores in DNS names that are not host
>names. Replace underscores in A records (left column) and PTR records
>(right column) with hyphens.
If you're going to say "per RFCs," please cite the RFC. For example:
RFC 1035, Section 2.3.1:
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.
....
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.
RFC 952, ASSUMPTIONS para 1:
A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.).
Note the use of the term "object" in RFC 1035, which doesn't necessarily
refer to a host. Examination of Section 2.3.1 and the rest of RFC 1035
indicates that the rules apply to any label, not just those for hosts.
Note also the list "Net, Host, Gateway, or Domain name" in RFC 952.
I'm not aware of any RFC that states what you claim, but will readily
admit my error if you can cite one.
Nice use of selective quoting. Reading the whole section will
show that they are talking about "Preferred name syntax".
As for the counter example read section "3.1 Name space
definitions". There is no *prohibition* on the use of underscore
in domainnames. There is a prohibition on the use of underscore in
hostnames (952/1123) and mail domains (821) (822 is slightly
more liberal than 821, but you can send them using SMTP) (1123
does not officially update 821 but it should be seen as doing
so).
Mark
> Nice use of selective quoting. Reading the whole section will
> show that they are talking about "Preferred name syntax".
>
> As for the counter example read section "3.1 Name space
> definitions". There is no *prohibition* on the use of underscore
> in domainnames. There is a prohibition on the use of underscore in
> hostnames (952/1123) and mail domains (821) (822 is slightly
> more liberal than 821, but you can send them using SMTP) (1123
> does not officially update 821 but it should be seen as doing
> so).
Right you are; as promised, I admit my mistake. Here's the relevant
paragraph from RFC 1035, Section 3.1:
Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions. Name servers and resolvers must
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
with zero parity. Non-alphabetic codes must match exactly.
In RFC 1123 terms, it's saying that labels SHOULD follow the syntax
described elsewhere (letters, digits, hyphens only), but it doesn't
say they MUST follow that syntax.
Thank you for pointing that out.
Underscores in domain/host names have never been allowed and there are
RFC's detailing what is allowed. The following are extracts from the RFC's
detailing domain syntax.
Extract from RFC 1101:
3.1. Network name syntax
The current syntax for network names, as defined by [RFC 952] is an
alphanumeric string of up to 24 characters, which begins with an
alpha, and may include "." and "-" except as first and last
characters. This is the format which was also used for host names
before the DNS. Upward compatibility with existing names might be a
goal of any new scheme.
However, the present syntax has been used to define a flat name
space, and hence would prohibit the same distributed name allocation
method used for host names. There is some sentiment for allowing the
NIC to continue to allocate and regulate network names, much as it
allocates numbers, but the majority opinion favors local control of
Extract from RFC 952:^M
ASSUMPTIONS
1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
sign (-), and period (.). Note that periods are only allowed when
they serve to delimit components of "domain style names". (See
RFC-921, "Domain Name System Implementation Schedule", for
background). No blank or space characters are permitted as part of a
name. No distinction is made between upper and lower case. The first
character must be an alpha character. The last character must not be
a minus sign or period. A host which serves as a GATEWAY should have
"-GATEWAY" or "-GW" as part of its name. Hosts which do not serve as
Internet gateways should not use "-GATEWAY" and "-GW" as part of their
names. A host which is a TAC should have "-TAC" as the last
part of its host name, if it is a DoD host. Single character names
or nicknames are not allowed.
Regards
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Stephen Burley | Please reply to:
\ HOSTMASTER for UUNET(UK) | hostm...@uunet.pipex.com
\ Internet House | inc. all original email.
\ 332 Science Park, Milton Rd. |
\ Cambridge | http://www.uunet.pipex.com
\ CB4 4BZ |
---------------------------------------
> Underscores in domain/host names have never been allowed and there are
>RFC's detailing what is allowed. The following are extracts from the RFC's
>detailing domain syntax.
There have been several postings with RFC citations that show where
underscores are verboten; I myself posted a few of these. It's been
pointed out, however, that most of these citations refer to a particular
object type (host, network, etc.) or have been misinterpreted to forbid
underscores when they actually only discourage their use.
Here is RFC 1035, Section 3.1 ("Name space definitions") in its
entirety; note especially the last paragraph:
3.1. Name space definitions
Domain names in messages are expressed in terms of a sequence of labels.
Each label is represented as a one octet length field followed by that
number of octets. Since every domain name ends with the null label of
the root, a domain name is terminated by a length byte of zero. The
high order two bits of every length octet must be zero, and the
remaining six bits of the length field limit the label to 63 octets or
less.
To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.
Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions. Name servers and resolvers must
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
with zero parity. Non-alphabetic codes must match exactly.
The "preferred syntax described elsewhere" refers to Section 2.3.1
("Preferred name syntax") and describes labels consisting of letters,
digits, and hyphens only. Note the word "preferred", not "required".
This doesn't mean underscores are allowed everywhere: RFCs 952 and
1123, for example, do give restrictions on the characters allowed in
host names.
Regardless of what the letter of the law reads, it seems the most prudent
thing to do is to follow RFC 1035's strong recommendation to stick with
letters, digits, and hyphens only. Recall RFC 1123:
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability:
"Be liberal in what you accept, and
conservative in what you send"
So could we please stop arguing about how many underscores can fit
on the head of a pin? :-)
RFC1034/1035 allows arbitrary octets in domain names. Underscores are
allowed.
However, if you are creating a domain name to be used as a host name, or a
mailbox name, or whatever, you have to follow both the rules for domain
names (to get it in the server) and the rules for whatever.
Domain names used as host names have to follow host name syntax to work.
So if underscores aren't allowed in host names, you can't use them in
domain names WHICH ARE USED TO NAME HOSTS.
Domain names used as mailboxes have to follow mailbox syntax to work. So
@Home wisely decided to register as Home.net, even though they could have
registered @Home.net, but then sending mail to Postmaster@@Home.net
probably would have been pretty tough.
If you like, you can thing of an analogy to a file system, where a file
that's going to be used as a C program had better have valid C in it, even
though the file system will let you store arbitrary bytes.
DNS servers should simply check for acceptable domain name syntax.
---------------------------------------------
Host name syntax has changed over the years. Some people have happily used
underscores, and now are surprised to find they don't work with new
versions of bind. But in the grand scheme of things an underscore isn't
much to give up.
I personally think that bind has no business checking master files for
syntax, other than that required for valid domain names. The filtering for
_ supposedly fixes a security bug, and so the expediency argument comes out.
Perhaps bind should be further enhanced to bar the 7 forbidden dirty words,
so children using the Internet will be safe.
paul
CTO
Software.Com main: 805-882-2470
525 Anacapa Street fax: 805-882-2473
Santa Barbara, CA extension: 278
I believe that's what 4.9.5-P1 fixed!
--
William A. Gianopoulos; Raytheon Company
gia...@eo.ray.com
--------------------------------------------------------
This is my personal opinion and not that of my employer.