11

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
  • 1
    The provider is fixing the webinterface as I'm writing this!
    – Lenne
    Mar 1, 2017 at 11:48

4 Answers 4

18

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]

9
  • 2
    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, 2017 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. Feb 24, 2017 at 15:42
  • 1
    Note that the Wikipedia entry cited has to do with internet names not DNS.
    – Jim B
    Feb 24, 2017 at 16:13
  • 3
    @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). Aug 27, 2018 at 18:55
  • 4
    @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. Aug 27, 2018 at 18:56
4

@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)

2

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.

4
  • "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. Aug 27, 2018 at 19:04
  • 3
    "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?
    – user
    Aug 27, 2018 at 20:22
  • “The client must validate name values” where is this specified? Jan 22, 2021 at 9:38
  • 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." This sentence makes no sense as the RDATA part of an MX record is a priority (integer) and an hostname. Not an email address. Jan 22, 2021 at 19:20
0

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.

5
  • 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, 2018 at 12:43
  • 1
    This is wrong. The label of a CNAME is not necessarily an hostname, so all characters are valid here, including the _. Aug 27, 2018 at 18:42
  • 2
    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." Aug 27, 2018 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. Aug 27, 2018 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, 2018 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .