What's the REAL DEAL with Underscores in BIND8.X?

[Mark_Andrews at isc.org]

> Scott Morizot wrote:
> 
> > On Fri, 15 Oct 1999, Ray Galuszka wrote:
> > > On page 77 in Albitz/Liu's DNS & BIND 3rd Edition, the authors state tha
> t
> > > underscores are not allowed in hostnames.  However, on the next page the
> y
> > > talk about how you can specify either fail, warn or ignore on the
> > > check-names option.
> > >
> > > I have LOTS of underscores in my BIND4.x environment now and we're migra
> ting
> > > to BIND8.  I set up our test server to "ignore" on the check-names optio
> n
> > > and the thing is resolving these names with no problem!
> > >
> > > The question is: if I set this ignore option and use underscores in
> > > hostnames and aliases, what might I break??   It sure beats putting out
> > > fires later because some server on my network somewhere expects an
> > > underscore that I changed to a hyphen in a hostname.
> >
> > Underscores in hostnames have always been illegal per RFC 952.
> > Versions of BIND before about 4.9.3 simply didn't enforce the
> > requirement at all.  (Actually, BIND 4.8 pretty much accepted
> > anything.)
> >
> > Allowing underscores will cause a problem with any software or
> > device that expects names to be compliant with RFC952.  Since
> > you apparently aren't having a problem now, you may not have
> > any at the moment.
> >
> > The long-term solution is to rename the systems using hyphens
> > instead of underscores and create aliases with the underscore.
> > Then you can age the aliases off your DNS gradually over time.
> 
> What cost-justifications could there possibly be for such a forced
> migration? "RFC compliance" doesn't mean a hell of a lot to a beancounter;
> where's the money? And we're not talking chump change either: we have over
> 7,000+ underscored names in our DNS database here, thanks to BIND's longstan
> ding
> permissiveness.
> 
> Separating underscore-checks from other kinds of name-checking within BIND w
> ould
> seem to be a far more practical solution to this "problem", at least until
> RFC 1035's ban on underscores can be officially obsoleted on the basis that 
> the
> stated justification for it -- migration from the HOSTS.TXT file -- has long
> since passed.
> 
> 
> - Kevin
> 
> 
> 

	It's not forced migration.  It's enforced compliance.  There is
	zero cost to those sites that actually took the time to find out
	what is a legal hostname.  RFC 1035 said "go look up what is a
	legal hostname and use that".

	This is not being done in the name of RFC compliance, though you
	should be RFC compliant if you wish to interoperate, it is being
	done to eleminate security threats that result from NOT enforcing
	RFC compliance.  

	BIND's gethostbyaddr() ensures that only RFC compliant hostnames
	are returned because there were attempts made to break into
	systems when this returned whatever was in the PTR record.  We
	had to choose what this should be returning and there was only
	one clearly correct answer.  Hostnames as described by RFC 952
	as modified by RFC 1123.  This was that only thing that *all*
	applications could be expecting.

	Now if we are not allowing non-compliant names through in the
	library we should also ensure that the can't be entered into
	PTR records.  If we don't allow them in PTR records, then we
	should not allow them in A records.  This last chain is simple
	the result of applying the principle of least suprise.

	If we didn't apply these checks we would be getting "You allow
	us to put this name in but gethostbyaddr() does not work with
	it" complaints.  We also had to supply a mechanism that could
	be used when you could not update the libraries to safe version.

	Strictly its not BIND's job to enforce this.  It should be done
	when the hostnames are being selected however the OS vendors were
	not doing this.

	As for those who say make "_" special.  I've see '$', '/' and ':'
	all used in a similar fashion.  Would you make the "special" as
	well.  This way leads to a very slippery slope.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org