Are underscores no longer supported in Bind 9.4?

[Kevin Darcy]

Mark Andrews wrote:
>> Jake Morrisey wrote:
>>     
>>> On 2/28/07, Mark Andrews <Mark_Andrews at 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.
>>>
>>>       
>> 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.
>>
>> Danny
>>     
>
> 	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.  
I interpret RFC 1035's references to RFC 952 to be non-normative. If 
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