TXT
TXT adds an TXT record To a domain. The name should be the relative label for the record. Use @ for the domain apex.
The contents is either a single or multiple strings. To specify multiple strings, specify them as an array.
Each string is a JavaScript string (quoted using single or double quotes). The (somewhat complex) quoting rules of the DNS protocol will be done for you.
Modifiers can be any number of record modifiers or JSON objects, which will be merged into the record's metadata.
NOTE: In the past, long strings had to be annotated with the keyword AUTOSPLIT. This is no longer required. The keyword is now a no-op.
Long strings
Strings that are longer than 255 octets (bytes) will be quietly split into 255-octets chunks or the provider may report an error if it does not handle multiple strings.
TXT record edge cases
Most providers do not support the full possibilities of what a TXT record can store. DNSControl can not handle all the edge cases and incompatibles that providers have introduced. Instead, it stores the string(s) that you provide and passes them to the provider verbatim. The provider may opt to accept the data, fix it, or reject it. This happens early in the processing, long before the DNSControl talks to the provider's API.
The RFCs specify that a TXT record stores one or more strings, each is up to 255 octets (bytes) long. We call these individual strings chunks. Each chunk may be zero to 255 octets long. There is no limit to the number of chunks in a TXT record, other than IP packet length restrictions. The contents of each chunk may be octets of value from 0x00 to 0xff.
In reality DNS Service Providers (DSPs) place many restrictions on TXT records.
Some DSPs only support a single string of 255 octets or fewer. Multiple strings, or any one string being longer than 255 octets will result in an error. One provider limits the string to 254 octets, which makes me think they're code has an off-by-one error.
Some DSPs only support one string, but it may be of any length. Behind the scenes the provider splits it into 255-octet chunks (except the last one, of course).
Some DSPs support multiple strings, but API requests must be 512-bytes or fewer, and with quoting, escaping, and other encoding mishegoss you can't be sure what will be permitted until you actually try it.
Regardless of the quantity and length of strings, some providers ban double quotes, back-ticks, or other chars.
Testing the support of a provider
How can you tell if a provider will support a particular TXT() record?
Include the TXT() record in a D() as usual, along with the DnsProvider() for that provider. Run dnscontrol check to see if any errors are produced. The check command does not talk to the provider's API, thus permitting you to do this without having an account at that provider.
What if the provider rejects a string that is supported?
Suppose I can create the TXT record using the DSP's web portal but DNSControl rejects the string?
It is possible that the provider code in DNSControl rejects strings that the DSP accepts. This is because the test is done in code, not by querying the provider's API. It is possible that the code was written to work around a bug (such as rejecting a string with a back-tick) but now that bug has been fixed.
All such checks are in providers/${providername}/auditrecords.go. You can try removing the check that you feel is in error and see if the provider's API accepts the record. You can do this by running the integration tests, or by simply adding that record to an existing dnsconfig.js and seeing if dnscontrol push is able to push that record into production. (Be careful if you are testing this on a domain used in production.)
Last updated