Re: Messages On Startup
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.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
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
> Barry Margolin wrote:
>>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
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 ??
--
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.
Kevin Darcy
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-----