Messages On Startup
Holdsworth, Matthew
I'm running BIND 8.2.1 on Solaris 6 and whenever I start named running I get
the following messages:
owner name "Brighton_RHE.lond.cwctv.net" IN (secondary) is invalid -
proceeding anyway
I get this message for numerous hosts and I'm getting the 'host name'
message to go along with that aswell.
I've checked the entries in the primary server and secondary server and it
all seems to be ok. I'm now wondering if it might have something to do with
the underscores in the hostnames?
Can anyone help or give me some advise please.
Regards
Matt
The contents of this email and any attachments are sent for the personal attention
of the addressee(s) only and may be confidential. If you are not the intended
addressee, any use, disclosure or copying of this email and any attachments is
unauthorised - please notify the sender by return and delete the message. Any
representations or commitments expressed in this email are subject to contract.
ntl Group Limited
KSP
> in the hostnames?
You are correct, sir!
ksp
Kevin Darcy
ancient versions of BIND (like the buggy, insecure version you're using)
actually try to enforce this restriction.
Upgrade. Later versions of BIND gave up trying to police hostname
restrictions.
- Kevin
Mark Andrews
> Well, technically, underscore is invalid in a "host name", and some
> ancient versions of BIND (like the buggy, insecure version you're using)
> actually try to enforce this restriction.
>
> Upgrade. Later versions of BIND gave up trying to police hostname
> restrictions.
By popular demand check-names is supported in BIND 9.3.
The correct fix is to get rid of the illegal hostname.
If you want to be on the Internet you need to play by
the rules of the Internet.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org
Kevin Darcy
>>Well, technically, underscore is invalid in a "host name", and some
>>ancient versions of BIND (like the buggy, insecure version you're using)
>>actually try to enforce this restriction.
>>
>>Upgrade. Later versions of BIND gave up trying to police hostname
>>restrictions.
>>
>>
>
> By popular demand check-names is supported in BIND 9.3.
>
One can only hope that the default setting is sensible.
> The correct fix is to get rid of the illegal hostname.
> If you want to be on the Internet you need to play by
> the rules of the Internet.
>
Is BIND "the Internet"? Why then does it presume to enforce "the
Internet"'s rules? The DNS protocol itself has no problems with
underscores, and IMO that's all BIND should be concerned with. Not to
mention the fact that BIND and DNS are also run on intranets where "the
Internet"'s rules don't apply...
- Kevin
Mark Andrews
Well you can run a RFC compliant intranet or not. Just
don't expect help from vendors if you choose to run outside
of the RFC requirements. The RFC are written to ensure
interoperation between products from different vendors.
There is no RFC recquirement to support underscores in
hostnames. There is a RFC requirement to support 'A'-'Z',
'a'-'z', '0'-'9', '.' and '-' in hostnames. There are
libraries that filter out non-compliant hostnames when the
name is used the context of a hostname. e.g. getnamebyaddr().
BIND just tries to stop you shooting yourself in the foot
by using names that appear to be non-compliant with RFC 952
(as modified by RFC 1123) as is required by RFC 1034.
RFC 1034:
For hosts, the mapping depends on the existing syntax for host names
which is a subset of the usual text representation for domain names,
together with RR formats for describing host addresses, etc.
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.
You are perfectly free to remove the trigger guard (check-names)
if you wish.
Various uses of the DNS depend upon namespace with the DNS
not colliding with each other. SRV's name syntax depends
was chosen so as to not collide with a legal hostname.
Microsoft did the same thing with their AD stuff. They have
a extended client to handle the few hostnames within AD that
are not compilent with RFC 952.
I'm sure there are still others applications that depend apon
non-colliding namespaces within the DNS.
You break the rules at your own peril.
Mark
> - Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
That's why there's a configuration option. Since BIND is usually used
on Internet hosts, it's not unreasonable for the default setting to
match this use.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Kevin Darcy
>In article <cg3dbh$17bj$1...@sf1.isc.org>,
> Kevin Darcy <k...@daimlerchrysler.com> wrote:
>
>
>
>That's why there's a configuration option. Since BIND is usually used
>on Internet hosts, it's not unreasonable for the default setting to
>match this use.
>
"Usually"? I have 4 production nameservers serving DNS to the Internet
and 50+ nameservers serving the intranet. I think most enterprise
customers have a similar ratio, or even more lopsided...
- Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
I'm guessing that enterprises like this amount to less than 10% of all
organizations. Most huge organizations with complex intranets.
Mark Andrews
> Barry Margolin wrote:
>
> >In article <cg3dbh$17bj$1...@sf1.isc.org>,
> > Kevin Darcy <k...@daimlerchrysler.com> wrote:
> >
> >
> >
> >>Mark Andrews wrote:
> >>
> >>
> >>
> >>>>Well, technically, underscore is invalid in a "host name", and some
> >>>>ancient versions of BIND (like the buggy, insecure version you're using)
> >>>>actually try to enforce this restriction.
> >>>>
> >>>>Upgrade. Later versions of BIND gave up trying to police hostname
> >>>>restrictions.
> >>>>
> >>>>
> >>>>
> >>>>
> >>> By popular demand check-names is supported in BIND 9.3.
> >>>
> >>>
> >>>
> >>One can only hope that the default setting is sensible.
> >>
> >>
> >>
> >>> The correct fix is to get rid of the illegal hostname.
> >>> If you want to be on the Internet you need to play by
> >>> the rules of the Internet.
> >>>
> >>>
> >>>
> >>Is BIND "the Internet"? Why then does it presume to enforce "the
> >>Internet"'s rules? The DNS protocol itself has no problems with
> >>underscores, and IMO that's all BIND should be concerned with. Not to
> >>mention the fact that BIND and DNS are also run on intranets where "the
> >>Internet"'s rules don't apply...
> >>
> >>
> >
> >on Internet hosts, it's not unreasonable for the default setting to
> >match this use.
> >
> "Usually"? I have 4 production nameservers serving DNS to the Internet
> and 50+ nameservers serving the intranet. I think most enterprise
> customers have a similar ratio, or even more lopsided...
And usually intranet's choose to follow the RFC's as well as
that is vendors manufacture products to. That what they list
in there purchace requirements documents etc.
The fact that you are a exception does not change this.
Kevin Darcy
>In article <cg3idf$1hba$1...@sf1.isc.org>,
>I'm guessing that enterprises like this amount to less than 10% of all
>organizations. Most huge organizations with complex intranets.
>
An enterprise which relies on DNS for its internal infrastructure needs
at least 1 authoritative nameserver for each mission-critical location,
otherwise it's at the mercy of WAN outages. But the number of
mission-critical locations for an enterprise is almost *always* less
than the number of Internet pipes the enterprise has, and unless the
enterprise is actually in the business of selling Internet technology,
services, products, etc. they probably can't justify more than 1 or 2
nameservers per pipe. Smaller enterprises might have only 1 or 2
authoritative nameservers serving their entire intranet, but such an
enterprise often/usually outsources its Internet DNS hosting to outfits
that serve their domains on the same set of nameservers as hundreds of
other customers'. This generally holds true even for enterprises which
have a disproportionately-large Internet presence in comparison to their
size (e.g. an online-only retailer). So, for any size of enterprise, it
seems unlikely to me, except for the "Internet" class of business noted
above, that a given enterprise has more Internet nameservers than
intranet ones.
- Kevin
Kevin Darcy
>>Barry Margolin wrote:
>>
>>
>>
>>>In article <cg3dbh$17bj$1...@sf1.isc.org>,
>>>Kevin Darcy <k...@daimlerchrysler.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Mark Andrews wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>Well, technically, underscore is invalid in a "host name", and some
>>>>>>ancient versions of BIND (like the buggy, insecure version you're using)
>>>>>>actually try to enforce this restriction.
>>>>>>
>>>>>>Upgrade. Later versions of BIND gave up trying to police hostname
>>>>>>restrictions.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> By popular demand check-names is supported in BIND 9.3.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>One can only hope that the default setting is sensible.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> The correct fix is to get rid of the illegal hostname.
>>>>> If you want to be on the Internet you need to play by
>>>>> the rules of the Internet.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Is BIND "the Internet"? Why then does it presume to enforce "the
>>>>Internet"'s rules? The DNS protocol itself has no problems with
>>>>underscores, and IMO that's all BIND should be concerned with. Not to
>>>>mention the fact that BIND and DNS are also run on intranets where "the
>>>>Internet"'s rules don't apply...
>>>>
>>>>
>>>>
>>>>
>>>That's why there's a configuration option. Since BIND is usually used
>>>on Internet hosts, it's not unreasonable for the default setting to
>>>match this use.
>>>
>>>
>>>
>>"Usually"? I have 4 production nameservers serving DNS to the Internet
>>and 50+ nameservers serving the intranet. I think most enterprise
>>customers have a similar ratio, or even more lopsided...
>>
>>
>
> And usually intranet's choose to follow the RFC's as well as
> that is vendors manufacture products to. That what they list
> in there purchace requirements documents etc.
>
I've never seen strict RFC 952 compliance listed as a requirement for a
vendor's product. In fact, many vendors use underscores in the names
they use in examples, documentation, etc., and sometimes even hard-code
underscored names into their products. From what I've seen, RFC 952's
underscore restriction has been ignored for a long long time.
> The fact that you are a exception does not change this.
>
>
An exception to what? For administrative IT functions (payroll,
accounting, office automation, groupware, etc.) we use the same vendors
as everyone else. We just get a higher volume discount, that's all :-)
- Kevin
p...@icke-reklam.ipsec.nu
> Dear All,
> I'm running BIND 8.2.1 on Solaris 6 and whenever I start named running I get
> the following messages:
> owner name "Brighton_RHE.lond.cwctv.net" IN (secondary) is invalid -
> proceeding anyway
> I get this message for numerous hosts and I'm getting the 'host name'
> message to go along with that aswell.
> I've checked the entries in the primary server and secondary server and it
> all seems to be ok. I'm now wondering if it might have something to do with
> the underscores in the hostnames?
underscores is invalid in hostnames. You better remove these as you won't
know if other nameservers/clients will refuse to deal with them.
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
Mark Andrews
> > And usually intranet's choose to follow the RFC's as well as
> > that is vendors manufacture products to. That what they list
> > in there purchace requirements documents etc.
> >
> I've never seen strict RFC 952 compliance listed as a requirement for a
> vendor's product. In fact, many vendors use underscores in the names
> they use in examples, documentation, etc., and sometimes even hard-code
> underscored names into their products. From what I've seen, RFC 952's
> underscore restriction has been ignored for a long long time.
Well did you bother to inform the vendors that they are
handing out *bad* advice, got a illegal hostname. Did
you ask the vendor to fix the product defect?
If I got a piece of hardware that was designed to be connected
to a IP network and had a hard coded illegal hostname I
would be sending it back to be repaired or to get a refund.
Mark
Kevin Darcy
>>> And usually intranet's choose to follow the RFC's as well as
>>> that is vendors manufacture products to. That what they list
>>> in there purchace requirements documents etc.
>>>
>>>
>>>
>>I've never seen strict RFC 952 compliance listed as a requirement for a
>>vendor's product. In fact, many vendors use underscores in the names
>>they use in examples, documentation, etc., and sometimes even hard-code
>>underscored names into their products. From what I've seen, RFC 952's
>>underscore restriction has been ignored for a long long time.
>>
>>
>
> Well did you bother to inform the vendors that they are
> handing out *bad* advice, got a illegal hostname. Did
> you ask the vendor to fix the product defect?
>
> If I got a piece of hardware that was designed to be connected
> to a IP network and had a hard coded illegal hostname I
> would be sending it back to be repaired or to get a refund.
>
>
Hmmm, okay, I'll go tell our plant-floor folks that they can't use their
paint-control/milling/stamping/machining/welding/electronics-testing
devices any more and they'll just have to improvise somehow...
In a manufacturing environment, "RFC compliance" and 50 cents might just
buy somebody a (small) cup of coffee. But, by itself, it's not going to
change anyone's purchasing or warranty-return decisions.
- Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
> Hmmm, okay, I'll go tell our plant-floor folks that they can't use their
> paint-control/milling/stamping/machining/welding/electronics-testing
> devices any more and they'll just have to improvise somehow...
What's your problem? Just put "check-names master ignore" in the
options section and you'll be all set.
Kevin Darcy
>In article <cg6c75$nm3$1...@sf1.isc.org>,
> Kevin Darcy <k...@daimlerchrysler.com> wrote:
>
>
>
>>Hmmm, okay, I'll go tell our plant-floor folks that they can't use their
>>paint-control/milling/stamping/machining/welding/electronics-testing
>>devices any more and they'll just have to improvise somehow...
>>
>>
>
>What's your problem? Just put "check-names master ignore" in the
>options section and you'll be all set.
>
My only point is that a default setting of "fail" would be rather
Internet-biased and misguided. I don't see why I should have to add a
check-names statement to all of *my* internal nameservers' configs, just
because some Internet-hosting outfit(s)' internal sanity-checking
processes are so pathetic that this is the only way they can keep
underscores out of the prohibited parts of their zone data (what, are
they paying college interns to edit the zone files by hand?).
I'm all for giving people the tools to prevent bad data -- for
somebody's definition of "bad" -- from getting into the DNS database. So
make RFC 952 compliance a flag to the "named-checkzone" utility or
something like that, so the Internet folks can sanity-check the zone
data before it actually gets loaded into the nameserver and published to
the Internet. But don't penalize those of us BIND users who, for
whatever historical reasons, have names with underscores in an
environment where RFC 952 doesn't apply.
It wasn't that long ago that I finally purged all of the check-names
crap out of my internal-nameserver configs from BIND 8's fling with RFC
952 enforcement. Now it looks like I'll have to go back and re-add it
all again. Bleah.
- Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
> Barry Margolin wrote:
>
> >In article <cg6c75$nm3$1...@sf1.isc.org>,
> > Kevin Darcy <k...@daimlerchrysler.com> wrote:
> >
> >
> >
> >>Hmmm, okay, I'll go tell our plant-floor folks that they can't use their
> >>paint-control/milling/stamping/machining/welding/electronics-testing
> >>devices any more and they'll just have to improvise somehow...
> >>
> >>
> >
> >What's your problem? Just put "check-names master ignore" in the
> >options section and you'll be all set.
> >
> My only point is that a default setting of "fail" would be rather
> Internet-biased and misguided.
Another point in favor of that default is that it's a safer setting. If
you're connecting to the Internet and don't have things configured in
the standard way, you can cause problems for others. So it's best to
have the defaults correct for the interoperation cases.
If the default doesn't match your needs for private use, they only
inconvenience you, not anyone else.
Kevin Darcy
>In article <cge2go$1ub7$1...@sf1.isc.org>,
> Kevin Darcy <k...@daimlerchrysler.com> wrote:
>
>
>
>>Barry Margolin wrote:
>>
>>
>>
>>>In article <cg6c75$nm3$1...@sf1.isc.org>,
>>>Kevin Darcy <k...@daimlerchrysler.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hmmm, okay, I'll go tell our plant-floor folks that they can't use their
>>>>paint-control/milling/stamping/machining/welding/electronics-testing
>>>>devices any more and they'll just have to improvise somehow...
>>>>
>>>>
>>>>
>>>>
>>>What's your problem? Just put "check-names master ignore" in the
>>>options section and you'll be all set.
>>>
>>>
>>>
>>My only point is that a default setting of "fail" would be rather
>>Internet-biased and misguided.
>>
>>
>
>Another point in favor of that default is that it's a safer setting. If
>you're connecting to the Internet and don't have things configured in
>the standard way, you can cause problems for others. So it's best to
>have the defaults correct for the interoperation cases.
>
>If the default doesn't match your needs for private use, they only
>inconvenience you, not anyone else.
>
I can sort of see that point, Barry, but as I've already asserted in
this thread, it's usually large organizations that host DNS,
organizations that can be expected to have hardened processes that
prevent interoperability-causing data to be loaded into any nameserver
at all. So for that small category, a conservative check-names seems
rather superfluous. I would also point out that such large organizations
have an *incentive* to be as interoperable as possible, since more
interoperability means more visitors to the site(s), more interest in
the products, more sales, more revenue, etc. So if underscores cause
interoperability problems -- and I still remain rather skeptical about
that assertion -- then those orgs are going to crack down on
underscores, and if they have any brains at all, they'll stop the
underscores in a way that doesn't involve bringing down the whole zone
(which is basically the blunt-instrument approach that "check-names
fail" takes).
- Kevin
Barry Margolin
Kevin Darcy <k...@daimlerchrysler.com> wrote:
> >If the default doesn't match your needs for private use, they only
> >inconvenience you, not anyone else.
> >
> I can sort of see that point, Barry, but as I've already asserted in
> this thread, it's usually large organizations that host DNS,
> organizations that can be expected to have hardened processes that
> prevent interoperability-causing data to be loaded into any nameserver
> at all. So for that small category, a conservative check-names seems
> rather superfluous.
Small organizations are usually the ones without experienced server
administrators. Ideally they wouldn't be hosting publically-accessible
DNS in the first place, but we don't live in an ideal world. I've had
to deal with plenty of these types, and anything the software can do to
make it easier for them to avoid mistakes is a blessing for the rest of
us.
p...@icke-reklam.ipsec.nu
>
> - Kevin
I don't see why underscores should be used AT ALL, there have been
at various times problems, it _is_ against RFC. Why use something
that _might_ impare when other characters are available ??
Kevin Darcy
>I don't see why underscores should be used AT ALL, there have been
>at various times problems, it _is_ against RFC. Why use something
>that _might_ impare when other characters are available ??
>
Aesthetically, I don't particularly like underscores either, but lots of
folks do, and don't give a rat's ass about purely-theoretical
interoperability issues. And as long as the (internal or external)
customer is paying the bills, how am I, or any DNS admin, in a position
to say "no"?
- Kevin
Ed Schmollinger
> p...@icke-reklam.ipsec.nu wrote:
> >I don't see why underscores should be used AT ALL, there have been
> >at various times problems, it _is_ against RFC. Why use something
> >that _might_ impare when other characters are available ??
> >
> Aesthetically, I don't particularly like underscores either, but lots of
> folks do, and don't give a rat's ass about purely-theoretical
> interoperability issues. And as long as the (internal or external)
> customer is paying the bills, how am I, or any DNS admin, in a position
> to say "no"?
available for those who want that kind of functionality. Making the
default for check-names be "fail", though, is pretty lame. It strikes
me as an instance of shoving one's big meaty opinion down everybody
else's throat.
We have production zones which contain underscored names. We've asked,
encouraged, cajoled, and threatened, but our customers insist that there
are a few names for which underscores are required. What's easier,
turning off check-names, or continuing to beat our heads against the
wall? I have a good idea of what our choice will be when we put 9.3
into production. I'll also note that I've spent more time dealing with
check-names just today (~10 minutes reading and opining about it) than
I've ever spent on problems caused by underscored names. A default of
"fail" is not appropriate, in my ever so humble opinion.
--
Ed Schmollinger - schm...@frozencrow.org
-- Attached file included as plaintext by Ecartis --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBNJgfuUf1YjPlx/ARAvZYAJ9WHPY9s8MKarBhGHRDfISdDa6TZQCdHcJO
3UErgSfJVzd+kwjr03AbvqE=
=kA3O
-----END PGP SIGNATURE-----
Jonathan de Boyne Pollard
p> at various times problems, it _is_ against RFC.
No, it isn't. Read RFC 2181 section 11 again. Underscores are illegal
in _host_ names, and in the domain portions of SMTP mailbox names; but
they are perfectly acceptable in domain names. A flat ban on
underscores in domain names is not in conformance with the standards.
Barry Margolin
And indeed, no one has proposed such a total ban, and I don't think BIND
implements that.