Hostname Naming Compliance

Kevin Darcy kcd at chrysler.com
Fri Mar 6 21:58:10 UTC 2009


Danny Mayer wrote:
> Kevin Darcy wrote:
>
>   
>> But, as far as I can tell, there's no *practical* reason to disallow
>> underscores, other than the fact that it may trip the standards-checking
>> code of some _other_ piece of software. So, piece of software A
>> disallows underscores because it's worried about causing a problem for
>> piece of software B, and piece of software B keeps the restriction
>> because it's worried about about causing a problem for piece of software
>> C, and piece of software C keeps the restriction because it's worried
>> about causing a problem for piece of software A.
>>
>>     
>
> I had a case a year or two ago where a system had a host name with an
> underscore in it and as a result it was unable to make a number of
> connections. I don't remember the details any more but removing the
> underscore solved the problem. It was running Windows which is why it
> was allowed to get that hostname in the first place. It was easier for
> me to point to the RFC's to get the sysadmins to change it than to
> figure out what was causing it to trip up and fail. There are too many
> failure paths.
>   

Yes, but by the same "too many failure paths" logic, we could never get 
rid of any obsolete restrictions ever. It's all very well to take the 
path of least resistance when the standards have a good reason for 
existing. But when that reason goes away, the standards should change 
and the implementation and operations should follow.

At a certain point, you have to say "time to move on", we don't use 
crude teletypes any more, underscores really aren't inherently a 
problem; they're only an interoperability problem when talking to 
systems that cling slavishly to the relevant standard. Maybe a few 
things will break here and there in the transition, that's why there are 
things like patches and updates and pre-production testing. The end 
result of the change is more flexibility and interoperability.

A standard that just sits and rots because everyone is afraid to change 
it, is a standard that is not serving its purpose, and once you get too 
many of those, people start looking at whole new paradigms. Witness the 
obsolence of OSI and SNA and the ascendance of TCP/IP. Learn from 
history. People were attracted to TCP/IP because it was more dynamic and 
flexible than what preceded it. We're in danger of losing that.

                                                                         
                                                         - Kevin




More information about the bind-users mailing list