Is _ (underscore) illegal in a CNAME record?

Question

We're having trouble creating the long TXT record for the DKIM key on the web interface on our hoster.

Each line can only accept 256 characters.

We tried multiple lines, then tried adding (" at the first and ") after the last as some suggest. Neither works.

Then we tried making a cname to a record on another hoster, where we can make the DKIM TXT records.

But now the webinterface complains about illegal name in the CNAME record.

mail._domainkey.example.com TXT is ok
mail._domainkey.example.com CNAME is not ok
mail.domainkey.example.com CNAME is ok, but not what we want.

Is the webinterface just determined to drive us crazy, or is it really "illegal" to have underscores in CNAME?

Solution 1

Hostnames may only contain [0-9], [a-z], -, so the underscore is not valid in a hostname. Note that a TXT record is not a hostname, and this restriction doesn't apply for it. (- may not be used as the first character either, so mail.-domainkey.our.dom wouldn't be valid.)

https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

When a CNAME is used as a hostname, the above restrictions apply.

But it appears a CNAME is not considered a hostname in the DKIM context and in that case, _ should be a valid part of a CNAME entry. See Underscore in CNAME required by SES not allowed by registrar [closed]

Solution 2

@Sven's answer, with the edit, is already right but just to phrase things directly.

TL;DR yes underscore is valid in a CNAME record on both sides, read below for why.

RFC 1034 and others define records based on "domain names" which are labels with any character, so including _.

But some records have stricter rules for either the owner name and/or the resource data (RDATA). There only an hostname will be accepted and indeed the rules are now (they were relaxed in the past where an hostname could not started with a digit) that you can use any ASCII letter (no case sensitivity), any ASCII digits, and the hyphens, plus some extra position rules: no hyphen at start or end and no double hyphens at position 3 and 4 (because of "reservation" for IDNs that are of the form xn-- which is only case allowed).

For example the owner name of an A or AAAA record is an hostname, not a domain name. So test.example.com A 192.0.2.1 is valid why all of these are not:

_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1

It is easy to test things with the named-checkzone program (part of the bind nameserver software but may be used and installed separately and others nameservers may have similar checking tools and there are probably online interfaces for that too anyway), just put records in a file and run it on:

$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)

(the number before the IN is the TTL, this is unrelated to our problem here, but needed just to pass syntax validation of a record).

For other records, it is the opposite: for NS there are no restrictions on the owner, but restrictions on the "target" that is the data. The data can only be an hostname, not a domain name, because you need to point to authoritative nameservers that are physical hosts that respond to DNS queries.

Now about CNAME, here are the relevant quotes from RFC 1034, in section 3.6:

"owner: which is the domain name where the RR is found." which means by default any name, not just an hostname (as source of the CNAME record)

"RDATA: which is the type and sometimes class dependent data which describes the resource:"

"CNAME a domain name."

So both the owner of a CNAME (what is on the left of it), and the resource data attached to it, its destination/target (what is on the right of it) are domain names, and not hostnames only. Basically any character, so including _ is allowed on both sides.

Again, easy to test with named-checkzone:

$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.

No errors whatsoever about the CNAME (the other errors are expected since in my fake zone I did not put any SOA or NS records like a true zone would have)

Solution 3

Any valid characters are allowed in DNS. See https://www.rfc-editor.org/rfc/rfc2181#section-11

"DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets."

The client must validate name values EG an MX record might contain the value "Alice" but after lookup that value should be rejected since "Alice" is not a valid email address.

In this case it looks like your hoster is "validating" your input, and they should be able to enter it manually for you.

Comments

[Lenne]

But is a CNAME a hostname? Some documentation shows to use underscore in a cname, so appearently it works. kb.mailchimp.com/accounts/email-authentication/…

[Todd Wilcox]

Also, underscores appear in the DNS entries on MS Windows Active Directory-integrated zones that underlie Windows Domains, at least in Microsoft's DNS management tool, but I'm not sure if those underscores are actually part of the name and Windows supports underscores in DNS requests, or if the underscores only appear in the DNS management snap-in and are actually not part of the names.

[raja]

Note that the Wikipedia entry cited has to do with internet names not DNS.

[mirabilos]

@ Lenne: A CNAME is a valid hostname because it’s an alias for a host. @ToddWilcox: yes, this is known, and this is a (deliberate?) spec violation by MS that caused other systems no amsll amounts of trouble as they do appear in DNS, DHCP, … packets despite not being legal.

[raja]

@mirabilos please show me the rfc that contradicts the RFC I quoted in my answer.

[user2284570]

@Sven : In pratice it was proven such things are possible over public internet. Though, it will depends on implementations. If a null byte works in a A record, then maybe a _can work with a CNAME, isn’t it ?

[Lenne]

Host names can not contain underscores. But _domainkey.some.dom is not the name of a host, it is the label for some value.

[Lenne]

I also have problems with Arduino, where some libs gives a hostname like ESP_245537, this name gets rejected when the DHCPserver tries to update the DNS.

[Patrick Mevzek]

This is wrong. The label of a CNAME is not necessarily an hostname, so all characters are valid here, including the _.

[Patrick Mevzek]

@Lenne "But is a CNAME a hostname?" no, not necessarily. RFC1034 is clear. Section 3.6: "owner: which is the domain name where the RR is found." which means any name, not just an hostname (as source of the CNAME record) and "RDATA: which is the type and sometimes class dependent data which describes the resource:" + "CNAME a domain name." so the target/destination is also any other name, not just hostname. Contrast with NS for example that says RDATA is specifically an hostname (not a domain name).

[Patrick Mevzek]

@mirabilos "A CNAME is a valid hostname" no, target (RDATA) of a CNAME is a domain name, not an hostname (a domain name is a superset of all possible hostnames). _foo CNAME _bar is completely legit, you can test with named-checkzone.

[Patrick Mevzek]

"Any valid characters are allowed in DNS" it is a little more complicated than that. There are domain names and host names. Except if said otherwise, everywhere you have labels that are domain names which means indeed any character, so _ or whatever else you fancy too. But, for some records, you can only use hostnames and not domain names. Hostnames are only letters digits and hyphens, nothing else. For example the owner of an A or AAAA record is an hostname, not a domain name. The RDATA (target) of a NS record is an hostname too, not a domain name.

[Patrick Mevzek]

And even without that, these are the old rules. They were prohibiting hostnames starting with a digit, but to accomodate 3com.com for example this rule was relaxed, see tools.ietf.org/html/rfc1123#page-13 "One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit."

[Patrick Mevzek]

@Lenne if esp_245537 is used as an hostname then the DNS update has to be refused since it is not a valid hostname. If this is used as domain name, then the DNS update should succeed (otherwise it is a bug), because it is a valid DNS label.

[Lenne]

I've seen hints that it's possible to translate invalid characters from DHCP to DNS, but never got it to work.

[user]

"an MX record might contain the value "Alice" but after lookup that value should be rejected since "Alice" is not a valid email address." Since when do MX RRs reference e-mail addresses?

[törzsmókus]

“The client must validate name values” where is this specified?

[Patrick Mevzek]

"an MX record might contain the value "Alice" but after lookup that value should be rejected since "Alice" is not a valid email address." This sentence makes no sense as the RDATA part of an MX record is a priority (integer) and an hostname. Not an email address.