TXT records are somewhat of a catch-all DNS record. Their use in tinydns requires escaping some reserved characters such as colons, (:) carriage returns (\r) and line feeds. (\n) Use the form below to generate properly escaped tinydns TXT records.

SPF records let mailservers check through DNS whether a host sending an email is authorized to send for that domain. SPF uses TXT records, and tinydns silently splits TXT records larger than 127 characters, leaving the reconstruction to the client DNS software. Usually this isn't a problem, but if your record is longer than 127 characters and you don't want to trust arbitrary client DNS implementations to reconstruct it, a generic record can be used instead. Generic records support a maximum of 255 characters, so if your record is longer than that, use a TXT record instead. The example below suggests only servers with an example.com MX record are permitted to send example.com email.

The dedicated SPF record type (type 99) that once appeared here was deprecated by RFC 7208 — publish SPF in TXT records instead.

DKIM is the standards-track successor to DomainKeys and is how mail is actually signed today: your mail server signs each outgoing message, and receivers fetch the public key from a TXT record at selector._domainkey.domain to verify it. Records longer than 255 characters (any RSA key of 2048 bits or more) are automatically split into multiple character-strings within the one record, which is exactly the case the generic record syntax handles better than tinydns' native TXT support.

Create a 2048 bit key and extract the public key in the form DKIM wants (the p= value):

openssl genrsa -out dkim.private 2048
openssl rsa -in dkim.private -pubout -outform DER | openssl base64 -A

Ed25519 keys (RFC 8463) are also supported — note DKIM uses the raw 32 byte ed25519 public key in base64, not the DER wrapper.

DMARC ties SPF and DKIM together: it tells receivers what to do with mail that fails authentication and where to send reports. The record is published as TXT at _dmarc.domain, which this builder prepends for you. If you are deploying DMARC for the first time, start with a policy of none and watch the aggregate reports before tightening to quarantine or reject.

Historic — DomainKeys was superseded by DKIM in 2007. Unless you are supporting a very old system, use the DKIM builder above instead. This builder is kept for compatibility with the original page.

DomainKeys is a technology developed by Yahoo which uses DNS TXT records to distribute public keys that can be used to verify the authenticity of individual emails. As of May 2007, DomainKeys was issued as a "historical" protocol and DKIM was issued as its standards-track replacement.

Using standard TXT records in djbdns can be problematic because djbdns splits TXT records longer than 127 characters — possibly in the middle of a key, leaving the rejoin up to the client DNS software. A generic record gets around this issue.

Create a 1024 bit private key and extract its public key using openssl:

openssl genrsa -out rsa.private 1024
chmod 600 rsa.private
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

Then put the public key (the contents of rsa.public) into a DomainKeys format DNS record:

SRV records specify a server for a given service / protocol / name combination. For example, an SRV compliant SIP phone looking to place a call to info@example.com does a lookup for _sip._tcp.example.com and gets a response listing the SIP services talking TCP for the domain example.com along with priority and weight ranking information. After sorting by priority (lowest first) then by weight (higher is a proportionally better chance of being selected) the end server is picked and contacted. This way load for a service at a domain can be distributed over multiple servers.

tinydns doesn't support SRV records natively, so this builder uses the generic record format. Be aware that some applications (OpenSER) prepend the protocol information (_sip._tcp or _sip._udp) automatically before doing SRV lookups.

NAPTR records support regular expression based rewrite rules that, when applied to an existing string, produce a new domain label or URI. The DDDS (Dynamic Delegation Discovery System, RFC 3401) uses NAPTR records for rewriting as described by RFC 3403. A record can go through any number of rewrites before reaching a terminal condition. For example, the ENUM Working Group specifies a way to map E.164 phone numbers to a URI: the number +17705551212 becomes 2.1.2.1.5.5.5.0.7.7.1.e164.arpa, which is then used to retrieve rewrite rules from NAPTR records:

$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
 IN NAPTR 100 10 "U" "SIP+D2U"  "!^.*$!sip:information@pbx.example.com!i" .
 IN NAPTR 102 10 "U" "SMTP+D2U" "!^.*$!mailto:information@example.com!i"  .

Of these two records, the first is at order 100 which is lower than 102 so it is picked first. The "U" flag means the output of the regexp field is a URI rather than another DNS lookup, so our original request is rewritten to sip:information@pbx.example.com. Another common use with SIP is an "S" flag record pointing at an SRV name (like _sip._udp.example.com) to discover the protocol and server for a service. Either the regular expression field or the replacement field should be used, but not both — the replacement field, if used, contains the domain name for the next DDDS query.

tinydns doesn't support NAPTR records natively, so this builder uses the generic record format. It is often easiest to check your tinydns / dnscache logs to see what clients are requesting.

Traditional IPv4 A records return a 32 bit IPv4 address. IPv6 addresses occupy 128 bits, hence the AAAA record. This version of tinydns doesn't support AAAA records natively, so a generic record does the job. This builder also provides a reverse (ip6.arpa) delegation record to more closely mimic what tinydns supplies for A records. You can use both standard and short (::) notation, and zero-compressed quads (a:b::c:d) also work. Thanks to Matija Nalis for patches on this.

HTTPS (type 65) and SVCB (type 64) are the newest widely deployed record types — browsers query for HTTPS records on nearly every page load. They let a name advertise supported protocols (like HTTP/3 via alpn), alternative ports, address hints and Encrypted ClientHello configuration in a single lookup. SVCB is the general form used by other services (for example DNS-over-TLS at _dns.domain); HTTPS is the web-specific form.

A priority of 0 is AliasMode: the record just points at the target name and carries no parameters. Priority 1 or higher is ServiceMode, where lower priorities are tried first. A target of "." means the service is at the record's own name. tinydns predates all of this, so the builder emits generic records.

TLSA records pin the TLS certificate (or public key) a service should present, published at _port._protocol.domain. They are the basis of DANE, most commonly deployed for SMTP between mail servers (Postfix and others verify DANE automatically). The usual modern choice is usage 3, selector 1, matching 1: pin the SHA-256 of the server's own public key.

Get the SHA-256 of a certificate's public key with openssl:

openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256

Note: validators only trust TLSA (and SSHFP) records served from DNSSEC signed zones. Stock djbdns doesn't sign zones, so to get real value from these you'll need a signing solution in front of tinydns.

SSHFP records publish a host's SSH key fingerprints in DNS so clients can verify a host key on first connect instead of prompting. With VerifyHostKeyDNS yes in ssh_config, OpenSSH checks these automatically (they carry weight only from DNSSEC signed zones — see the note under TLSA). Generate the records for a host with:

ssh-keygen -r host.example.com

which prints one line per host key; the last two numbers on each line are the algorithm and fingerprint type selected below, followed by the hex fingerprint.

CAA records specify the Certificate Authorities (CAs) authorized to issue certificates for the listed domain. Traditionally clients trust a list of commonly accepted CAs, but this lets you explicitly list what CAs are authorized to issue certificates for your domain. A CA should check that they are listed in your CAA records before granting a certificate.

The issue tag defines the host names of CAs to trust — for example, example.com can restrict certificate issuance to ca.example.net. Multiple CAs can be configured with multiple CAA records, and setting issue to ; means no certificates should be issued at all. The issuewild tag specifies that a CA is allowed to issue wildcard certificates (like *.example.com) and takes precedence over any issue declarations, so be careful with these! The iodef tag defines where to report invalid certificate requests — an email address (mailto:ca-issues@example.com), a host or a web address. Additional parameters may be added with a semicolon, a space and then key=value pairs, like ca.example.net; account=abc123. The newer contactemail and contactphone tags publish contact information used for domain control validation.