Summary
A standard Valimail customer engagement requires that the customer point two DNS zones to Valimail, one for DKIM (e.g., _domainkey.example.com) and the other for DMARC (e.g., _dmarc.example.com). By definition, DNS delegation cedes control of a portion of the domain owner’s namespace to the delegated party, and some customers may have concerns that such delegation will not only give Valimail the ability to create arbitrary DNS records in the delegated namespace but that Valimail might exercise this ability. This article explains why customers should not be concerned about the NS records that Valimail asks you to implement, and it borrows heavily from RFC 8552, an Internet Best Current Practice for DNS names containing underscores.
DNS Delegation
The Domain Name System is a hierarchical, distributed namespace. Names in DNS are separated by dots (e.g., www.example.com) and those dots represent separators in the hierarchy.
Some DNS servers are designated as “authoritative” for a given branch of the DNS namespace. When a server is designated as authoritative, it is expected to be the one true source of answers for any query about its part of the namespace.
An authoritative server can delegate authority about smaller parts of its namespace to other servers, meaning that it cedes management of part of its namespace to other servers. For example, the DNS server that is authoritative for “example.com” (which we’ll call “ns1.example.com”) might want to delegate authority for “marketing.example.com” to a different server (which we’ll call “nsmktg.example.com”) to allow folks in the marketing department to manage that part of the space. In technical terms, ns1.example.com would publish the following record in DNS:
marketing.example.com NS nsmktg.example.com
In layman’s terms, when ns1.example.com is asked to answer any queries about any name ending in “marketing.example.com”, its response will be to effectively point to nsmktg.example.com and say “Go ask that server for your answer.”
Valimail usually asks its customers to point two names to its servers, using records like this:
_dmarc.example.com NS ns.vali.email
_domainkey.example.com NS ns.vali.email
The first example here is designed to allow Valimail to manage the customer’s DMARC policy record, while the second allows Valimail to manage the publication of the customer’s DKIM public key records. At first glance, these delegations seemingly also allow Valimail to publish any record in DNS ending in either “_dmarc.example.com” or “_domainkey.example.com”, but the rules of DNS are such that this is simply not so.
Syntax Rules for DNS Hostnames
First published in October, 1985, RFC 952 established the set of valid characters for use in DNS hostnames, limiting the set to letters, numbers, the hyphen, and the dot. RFC 952 was subsequently updated by RFC 1123, which reaffirmed the character set used for valid hostnames. This means that the underscore character, which is present in both domain names pointed to Valimail, cannot appear in the following types of DNS records:
The hostname part of a DNS A record, which maps hostnames to IP addresses
The hostname part of a DNS PTR record, which maps IP addresses to hostnames
The hostname part of a DNS MX record, which maps a domain name to the hostname of a server that accepts inbound mail on that domain’s behalf.
The hostname part of an DNS NS record, which maps a domain name to the hostname of a server that is authoritative for DNS for that domain.
Any hostname in a DNS CNAME record, which can map a DNS hostname or domain name to its canonical name, which in turn can be either a DNS hostname or domain name.
These restrictions prevent Valimail from creating any of the above record types using “_dmarc.example.com” or “_domainkey.example.com” in any hostname value in such records.
Valimail explicitly only asks for underscore domain names to be pointed, so that we cannot in any circumstance run a publicly accessible web server on behalf of our customers. This functionality has passed FedRAMP compliance in the United States and is used in this delegated manner by the US Department of the Interior, Federal Aviation Administration, and Environmental Protection Agency, amongst many others.
Valid DNS Record Types Using The Underscore Character
While underscores are not permitted in DNS hostnames, there are other DNS records that are not hostnames that allow for use of the underscore character in their names. Among these record types are the DNS TXT record (RFC 1035), the DNS SRV record (RFC 2782 and RFC 6335), and the DNS URI record (RFC 7553). These “generalized” resource record types don’t rely on hostnames, only domain names, and free text, and so the prohibition on the use of underscore characters does not apply to them.
DMARC, DKIM, and Domain Names with Underscores
Both the DMARC and DKIM protocols define domain names with labels that start with the underscore character, mimicking the DNS SRV record syntax. Both protocols also allow for the creation of names that are subordinate to the delegated domain name under very specific circumstances.
DMARC
The DMARC protocol allows for the possibility of a third-party domain receiving aggregate and/or failure reports for the domain publishing the DMARC policy record. RFC 7489 describes the DNS TXT record to be published under such circumstances, but such records exist in the domain of the third-party report receiving domain, not the domain publishing the DMARC policy record.
DKIM
The DKIM protocol (RFC 6376) relies on something called a “selector” to validate a DKIM signature. Each DKIM-signed message has within it the name of the “selector” that was used in signing the message, and the message recipient will use that name, along with the signing domain (also included in the message) to construct a DNS domain name at which a TXT record containing the DKIM public key used for signing that message should be published. The format of this name will be akin to “selector._domainkey.signingDomain.name” (e.g., “s1._domainkey.example.com for a message DKIM signed by domain example.com using selector “s1”).
In order to ensure that DKIM-signed messages have an opportunity to pass validation checks, Valimail would have to publish TXT records in DNS for each selector used by its customer in signing messages, with each TXT record being a domain name that is subordinate to the domain name pointed to Valimail (e.g., _domainkey.example.com) Further, sub labels within DKIM (such as selector1.region1._domainkey.example.com) are common and valuable for subdividing namespaces.
Conclusion
The delegation of authority to Valimail by customers of the “_dmarc” and “_domainkey” portions of the namespace for the customer domain does not give Valimail free reign to create any records it wants to in those spaces. While there are legitimate reasons for Valimail to create TXT records in the “_domainkey” namespace for the publication of DKIM public keys, the DNS protocol keeps a check on the creation of most other resource record types due to the presence of the underscore character in the namespaces pointed to Valimail.