Are underscores no longer supported in Bind 9.4?
Jake Morrisey
I know I have these in many records in versions before 9.4.
Here is the error that I am getting now.
Feb 28 18:29:54 t141 named[8767]: db.example.com:77:
test_underscore.example.com: bad owner name (check-names)
As soon as I remove the A record with the underscore it in, everything is
fine and the zone loads.
Is this a new rule / RFC?
Thanks,
-Jake
Mark Andrews
No. It's a 20 year old rule. See RFC 952 and RFC 1123.
The later extends the syntax to allow leading digits.
Labels in hostnames are restricted to letters, digits and
hypens (LDH).
If you really want underscore you can turn the checks off
however I suggest that you rename the machines as there are
resolver libraries which check.
Mark
> Thanks,
> -Jake
>
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Kevin Darcy
> Does bind 9.4 no longer support underscores (_) in the A records?
> I know I have these in many records in versions before 9.4.
> Here is the error that I am getting now.
>
> Feb 28 18:29:54 t141 named[8767]: db.example.com:77:
> test_underscore.example.com: bad owner name (check-names)
>
> As soon as I remove the A record with the underscore it in, everything is
> fine and the zone loads.
>
> Is this a new rule / RFC?
>
No, actually, it's a very *old*, arguably obsolete RFC (RFC 952).
BIND has flip-flopped over the years on whether it should be in the
business of enforcing *hostname* (as opposed to DNS) standards. Recently
the pendulum has swung back in the direction of "we'll enforce them", so
you'll need to fiddle with your "check-names" settings if you have
underscores in your names and you want to exorcise the spurious
failures/warnings from BIND.
- Kevin
Tony Earnshaw
>> Does bind 9.4 no longer support underscores (_) in the A records?
>> I know I have these in many records in versions before 9.4.
>> Here is the error that I am getting now.
>>
>> Feb 28 18:29:54 t141 named[8767]: db.example.com:77:
>> test_underscore.example.com: bad owner name (check-names)
>>
>> As soon as I remove the A record with the underscore it in, everything is
>> fine and the zone loads.
>>
>> Is this a new rule / RFC?
>
> No. It's a 20 year old rule. See RFC 952 and RFC 1123.
> The later extends the syntax to allow leading digits.
>
> Labels in hostnames are restricted to letters, digits and
> hypens (LDH).
>
> If you really want underscore you can turn the checks off
> however I suggest that you rename the machines as there are
> resolver libraries which check.
Haven't begun with 9.4 yet, but shall do shortly. Are underscores
permitted in TXT records? I'm thinking of things like Kerberos and
Domainkeys/DKIM TXT records.
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
Tony Earnshaw
[...]
>> Haven't begun with 9.4 yet, but shall do shortly. Are underscores
>> permitted in TXT records? I'm thinking of things like Kerberos and
>> Domainkeys/DKIM TXT records.
>
> Come on, there is a difference between "hostnames" with an "A" record
> and "TXT" records. This is an argument from the early BIND-8 days. At
> least seven years old.
>
> Please, if you are managing a DNS operation, maybe for Kerberos, you
> need to understand the DNS that you are managing. Do a little
> studying. (You have the exact same issue with "SRV" records used by
> Microsoft Active Directory also. The AD records/domains specifically
> include underscore characters.)
Possibly. Keep things on the list, if you please.
Mark Andrews
Kerberos uses _kerberos specifically because _kerberos is
not a legal label in a hostname. You can then have a host
called kerberos without it clashing the TXT record specifying
the Kerberos realm.
e.g.
kerberos.example.com A 1.2.3.4
_kerberos.example.com TXT EXAMPLE.COM
Similarly for SRV, using underscore moves the records out of
the hostname space.
Mark
Edward Lewis
> Similarly for SRV, using underscore moves the records out of
> the hostname space.
What is often misunderstood is the difference between a domain name
and a (DNS) host name. Host names are constrained by rules in RFC
1123 to basically letters, digits, etc. (you can read the spec for
details). All DNS host names are domain names but not vice versa.
Places where a host is needed and not a domain name is in the RDATA
of an NS record. Conversly the owner of any record is a domain name
and ordinarily not just a host name. A and AAAA records are places
where the restriction is understandable as only hosts have IP (4/6)
addresses.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
"Two years ago you said we had 5-7 years, now you are saying 3-5. What I
need from you is a consistent story..."
Michael Milligan
> At 16:37 +1100 3/1/07, Mark Andrews wrote:
>
>> Similarly for SRV, using underscore moves the records out of
>> the hostname space.
>
> What is often misunderstood is the difference between a domain name
> and a (DNS) host name. Host names are constrained by rules in RFC
> 1123 to basically letters, digits, etc. (you can read the spec for
> details). All DNS host names are domain names but not vice versa.
This confusion is also compounded by the fact that Microsoft allowed
underscore characters in computer names (NetBIOS carryover) until
recently. So did Apple prior to OS X.
I've been convinced by various arguments over the years that the
server-side of DNS is the wrong place to enforce this.
Regards,
Mike
--
Michael Milligan -> mi...@acmeps.com
Kevin Darcy
> Does bind 9.4 no longer support underscores (_) in the A records?
> I know I have these in many records in versions before 9.4.
> Here is the error that I am getting now.
>
> Feb 28 18:29:54 t141 named[8767]: db.example.com:77:
> test_underscore.example.com: bad owner name (check-names)
>
> As soon as I remove the A record with the underscore it in, everything is
> fine and the zone loads.
>
> Is this a new rule / RFC?
>
No, actually, it's a very *old*, arguably obsolete RFC (RFC 952).
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
> Jake Morrisey wrote:
> > Does bind 9.4 no longer support underscores (_) in the A records?
> > I know I have these in many records in versions before 9.4.
> > Here is the error that I am getting now.
> >
> > Feb 28 18:29:54 t141 named[8767]: db.example.com:77:
> > test_underscore.example.com: bad owner name (check-names)
> >
> > As soon as I remove the A record with the underscore it in, everything is
> > fine and the zone loads.
> >
> > Is this a new rule / RFC?
> >
>
> No, actually, it's a very *old*, arguably obsolete RFC (RFC 952).
>
> BIND has flip-flopped over the years on whether it should be in the
> business of enforcing *hostname* (as opposed to DNS) standards. Recently
> the pendulum has swung back in the direction of "we'll enforce them"
The check-names option has been in BIND since 8.x, I think. The only
flip-flopping, I believe, has been on what the default setting should be.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Jake Morrisey
> No. It's a 20 year old rule. See RFC 952 and RFC 1123.
> The later extends the syntax to allow leading digits.
>
> Labels in hostnames are restricted to letters, digits and
> hypens (LDH).
Thank you for the previous references.
As a followup are underscores allowed in CNAME records? Are CNAME
records not bound by these RFCs? I would think they would have the
same rules but the named-checkzone and the named-compilezone have no
problem with a CNAME having an underscore.
Thanks,
-Jake
Jake Morrisey
> CNAME's point to hostnames and therefore must follow the same rules. Are
> you asking about the label of the CNAME record? It should be the same as
> it acts as a hostname for all purposes. If it doesn't complain then it's
> probably a bug. I didn't see anything in any of the RFC's that makes
> that explicit but it would make sense.
Yeah, this appears to be a bug then. Both parts of the CNAME can have
an underscore and named-checkzone and named-compilezone have no
problem at all with allowing it without warnings or errors.
-Jake
Mark Andrews
> you asking about the label of the CNAME record? It should be the same as
> it acts as a hostname for all purposes. If it doesn't complain then it's
> probably a bug. I didn't see anything in any of the RFC's that makes
> that explicit but it would make sense.
>
CNAME's provide aliasing of domain names. Hostnames are
a subset of domain names. If a CNAME is being used as
a hostname then it needs to follow the rules in RFC 952 +
RFC 1123. If it is not being used as a hostname then it
doesn't.
If people actually read and followed the RFC's then there
wouldn't be all this discussion. RFC 1035 says to use RFC
952 syntax for hostnames. RFC 1123 which came later, relaxed
it slightly to allow leading digits.
Mark
RFC 1035.
The DNS specifications attempt to be as general as possible in the rules
for constructing domain names. The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
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.
For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822. When creating a new host name,
the old rules for HOSTS.TXT should be followed. This avoids problems
when old software is converted to use domain names.
> Danny
>
> > Thanks,
> > -Jake
Chris Thompson
>In article <esa68j$mfp$1...@sf1.isc.org>,
> Kevin Darcy <k...@daimlerchrysler.com> wrote:
[...]
>> BIND has flip-flopped over the years on whether it should be in the
>> business of enforcing *hostname* (as opposed to DNS) standards. Recently
>> the pendulum has swung back in the direction of "we'll enforce them"
>
>The check-names option has been in BIND since 8.x, I think. The only
>flip-flopping, I believe, has been on what the default setting should be.
Actually, although the check-names option was present in BIND 8, it was
entirely missing from BIND 9.x until 9.3. (See entry 1586 in the change log.)
--
Chris Thompson
Email: ce...@cam.ac.uk
Mark Andrews
> > you asking about the label of the CNAME record? It should be the same as
> > it acts as a hostname for all purposes. If it doesn't complain then it's
> > probably a bug. I didn't see anything in any of the RFC's that makes
> > that explicit but it would make sense.
>
> an underscore and named-checkzone and named-compilezone have no
> problem at all with allowing it without warnings or errors.
No. Checking CNAME reached the point of diminishing returns.
You have to check what the CNAME(s) (you can have a CNAME
chain) points to then issue a error/warning. This also has
to be done post load as the target may not yet be loaded.
CNAME records can also point out of zone.
Also people use the lack of CNAME checks to aid in "fixing"
the zone. They fix the offend name and add a CNAME at the
old name to keep all their broken names working.
One day we might add CNAME owername checks. It's not a high
priority however.
Mark
Kevin Darcy
>> Jake Morrisey wrote:
>>
>>> On 2/28/07, Mark Andrews <Mark_A...@isc.org> wrote:
>>>
>>>> No. It's a 20 year old rule. See RFC 952 and RFC 1123.
>>>> The later extends the syntax to allow leading digits.
>>>>
>>>> Labels in hostnames are restricted to letters, digits and
>>>> hypens (LDH).
>>>>
>>> Thank you for the previous references.
>>> As a followup are underscores allowed in CNAME records? Are CNAME
>>> records not bound by these RFCs? I would think they would have the
>>> same rules but the named-checkzone and the named-compilezone have no
>>> problem with a CNAME having an underscore.
>>>
>>>
>> you asking about the label of the CNAME record? It should be the same as
>> it acts as a hostname for all purposes. If it doesn't complain then it's
>> probably a bug. I didn't see anything in any of the RFC's that makes
>> that explicit but it would make sense.
>>
>>
>
> CNAME's provide aliasing of domain names. Hostnames are
> a subset of domain names. If a CNAME is being used as
> a hostname then it needs to follow the rules in RFC 952 +
> RFC 1123. If it is not being used as a hostname then it
> doesn't.
>
> If people actually read and followed the RFC's then there
> wouldn't be all this discussion. RFC 1035 says to use RFC
> 952 syntax for hostnames.
you're referring to the text "the old rules for HOSTS.TXT should be
followed", then understand that that whole paragraph is subservient to
the preceding paragraph, which describes what a "prudent user" would,
i.e. this is a weak *recommendation*, not a normative reference. At most
a SHOULD, not a MUST. And it makes a clear distinction between "rules of
the domain system" and other types of rules associated with the object.
What's more definitive is the verbiage "The DNS specifications attempt
to be as general as possible in the rules for constructing domain names"
at the beginning of section 2.3.1. That should be the touchstone: the
DNS specifications themselves are general, other specifications which
relate to names and how names are used, may choose to be more restrictive.
Consequently, I don't think it is a proper function of DNS software to
enforce standards outside of the DNS standards themselves. By "enforce"
I mean, in a default configuration, rejecting a master zone, simply
because some name in the zone does not conform to RFC 952 or some other
non-DNS standard. I think the change to the check-names default is
ill-considered.
- Kevin