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?

  • 1
    The provider is fixing the webinterface as I'm writing this! – Lenne Mar 1 '17 at 11:48

Yes, DNS names (this also includes A/AAAA) may only contain [0-9], [a-z], -, so the underscore is not valid. Note that a TXT record is not a hostname, and this restriction doesn't apply for it. And one last edit: - may not be used as the first character either, so mail.-domainkey.our.dom wouldn't be valid.


Final edit: I was partially wrong. When a CNAME is used as a hostname, the above restrictions apply. 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 https://stackoverflow.com/questions/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491

| improve this answer | |
  • 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/… – Lenne Feb 24 '17 at 11:55
  • 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. – Todd Wilcox Feb 24 '17 at 15:42
  • Note that the Wikipedia entry cited has to do with internet names not DNS. – Jim B Feb 24 '17 at 16:13
  • @ 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. – mirabilos Feb 24 '17 at 20:24
  • 2
    @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 Aug 27 '18 at 18:56

Any valid characters are allowed in DNS. See https://tools.ietf.org/html/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.

| improve this answer | |
  • "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 Aug 27 '18 at 19:04
  • 1
    "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? – a CVn Aug 27 '18 at 20:22

RFC 1034: The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

| improve this answer | |
  • 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. – Lenne Aug 27 '18 at 12:43
  • This is wrong. The label of a CNAME is not necessarily an hostname, so all characters are valid here, including the _. – Patrick Mevzek Aug 27 '18 at 18:42
  • 1
    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 Aug 27 '18 at 19:27
  • @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. – Patrick Mevzek Aug 27 '18 at 19:29
  • I've seen hints that it's possible to translate invalid characters from DHCP to DNS, but never got it to work. – Lenne Aug 27 '18 at 19:38

@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 is valid why all of these are not:

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

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
_test.example.com. 1 IN A
-test.example.com. 1 IN A
test-.example.com. 1 IN A
$ /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)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.