Anders Brownworth

djbdns / tinydns Record Builder

tinydns is the authoritative nameserver from the popular djbdns package written by D. J. Bernstein. Configuration through a text based data file requires escaping several characters. (for example, the colon (:) character) Also, some newer data types such as SRV and NAPTR records aren't nativly supported by tinydns but can be represented through the generic record syntax. Use the tools below to create standard djbdns records for these record types.

Record Builders: Please use the email address at the bottom of the page or the form on my homepage to contact me. Please feel free to correct mistakes or suggest additional record builders.

Take a look at GeoIPDNS to taylor DNS responses based on the location of the requester. http://geoipdns.org/

djbdns / tinydns TXT (Text) Record Builder

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

Domain:
Text:
Time To Live:


djbdns / tinydns SPF (Sender Policy Framework) Record Builder

SPF records are part of a larger effort to reduce spam by describing a framework where mailservers can check through DNS to see if a host sending an email is authorized to send for that domain. SPF employs text records and tinydns silently splits text records larger than 127 characters leaving the reconstruction to the client DNS software. Usually this isn't a problem, but if your records are longer than 127 characters and you don't want to trust arbitrary client DNS implementations to reconstruct your SPF records, a generic record can be used instead. Generic records support a maximum of 255 characters so if your record is longer than that, you should look at TXT records instead. The example in the form below creates an SPF (TXT) record through the generic record syntax suggesting only servers with an example.com MX record are permitted to send example.com email. If you need help figuring out SPF syntax for your domain, take a look at the SPF Tools Page at the official SPF site.

Old TXT based SPF Records
Domain:
SPF Rules:
Time To Live:

New Type 99 based SPF Records
SPF records now have their very own record type. (type 99) These newer records use the v=spf3 designation. You can run both TXT and type 99 records but the older TXT records must use the older v=spf1 designation and not v=spf3. (thanks to Richard Lucassen for pointing out type 99 records to me)
Domain:
SPF Rules:
Time To Live:


djbdns / tinydns DomainKeys (Generic Text) Record Builder (RFC Draft)

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 has been 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 when they are longer than 127 characters. This split might happen in the middle of a key leaving the rejoin up to the client DNS software. You can use a generic record instead to get around this issue. The example in the form below creates a generic TXT record that publishes a DomainKeys format key (BEg1nHtnGxxSJjclWjZwP56LRqdg5ZX15b...) for the user joe at example.com.

Create a 1024 bit private key using openssl:
  openssl genrsa -out rsa.private 1024
  chmod 600 rsa.private
Get your public key:
  openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
Put your public key (contents of rsa.public) into a DomainKeys format DNS record using this form:

Domain:
Type: (only rsa is supported by DomainKeys at the moment)
Key:
Carrage returns will be stripped out automatically. Keys larger than 2048 bits
won't fit within a 512 byte UDP DNS packet.
Time To Live:

Sign your email: (hopefully done automatically by your email client)
  openssl dgst -sign rsa.private -sha1 < email.txt
The resulting signature is included with the email in a header labeled DomainKey-Signature:.

When the remote side receives your email, it gets your public key from your DomainKey record in DNS, removes the DomainKey-Signature: header and checks the validity of your email given the public key and the signature:
  openssl dgst -verify rsa.public -sha1 -signature signature.txt < email.txt
If the key checks out, the email is authentic.


djbdns / tinydns SRV (Service Location RFC 2782) Record Builder

tinydns doesn't support SRV records nativly, but Michael Handler patched djbdns to support SRV records with a standard record type. This ends up being a much easier format to administrate than using the generic record format in the example below, but you have to patch djbdns. The form below creates SRV records using the generic record format so you don't have to patch djbdns.

SRV records are used to specify a server for a given service / protocol / name combination. For example, an SRV compliant SIP phone may want to find a server to talk to for a call placed to info@example.com. By convention, the device 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) than 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.

Be aware that some applications (OpenSER) prepend the protocol information (_sip._tcp or _sip._udp) automatically before doing SRV lookups.

Service:
Priority: lower is picked first
Weight: higher is proportionally better for records of the same priority
Port:
Target:
Time To Live:


djbdns / tinydns NAPTR (Naming Authority Pointer RFC 3403) Record Builder

tinydns doesn't support NAPTR nativly, but Guilherme Balena Versiani extended Michael Handler's SRV patch to support NAPTR records with a standard record type. This ends up being a much easier format to administrate than using the generic record format in the example below, but you have to patch djbdns. The form below creates NAPTR records in the generic record format so you don't have to patch djbdns.

NAPTR records support regular expression based rewrite rules that, when applied to an existing string, will 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 in RFC 2916. (the E.164 number +17705551212 is converted by killing all non digit characters (17705551212) reversing and spacing with dots (2.1.2.1.5.5.5.0.7.7.1) and adding ".e164.arpa" to the end. (2.1.2.1.5.5.5.0.7.7.1.e164.arpa). This domain name is then used to retrieve rewrite rules from NAPTR records. The BIND configuration for the records returned from a query for 2.1.2.1.5.5.5.0.7.7.1.e164.arpa might be:
$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 prefrence 100 which is lower than 102 so it is picked first. The weight of 10 is unimportant as no other rules are at prefrence 100. The "U" flag means that the next step is not a DNS lookup but that the output of the Regexp field is an URI. If we support the service designated with the key "SIP+D2U", we won't go on to investigate other rules with higher prefrence numbers. (the label "prefrence" is somewhat misleading here as lower prefrences are selected first) The rewrite regular expression "!^.*$!sip:information@pbx.example.com!i" is evaluated transforming our origional request of 2.1.2.1.5.5.5.0.7.7.1.e164.arpa into sip:information@pbx.example.com. Briefly, "!" will be our delimiter (lets avoid using slashes because they may be interpreted as escape sequences somewhere else) and "^.*$" says "starting at the beginning, any characters, ending at the end" (in other words, everything) is changed to "sip:information@pbx.example.com" and "i" ignores case. (although case doesn't matter as our regular expression is ".*") So the resulting URI "sip:information@pbx.example.com" will be used. If we didn't support SIP, we would effectivly fall back to the rule resulting in "mailto:information@example.com". The "replacement" field in the form below may seem redundant, but it is there for historical optimization reasons. Either the regular expression field or the replacement field should be used but not both. The replacement field, if used, would contain the domain name to be used in the next DDDS query.

Another example use of NAPTR records with SIP is in conjunction with SRV records to discover the protocol and "A" record to be used for SIP service. SIP can be run over UDP, TCP or TCP with TLS encryption among others however standard "A" record lookups won't tell you anything about the protocol. For example, we might want to call someone at example.com but we wouldn't know where to go nor what to talk. To find out, we start with a NAPTR lookup on example.
# host -t NAPTR example.com
example.com NAPTR 10 100 "S" "SIP+D2U" "" _sip\._udp\.example\.com.
Here we find that example.com suggests "SIP+D2U" or SIP over UDP at _sip._udp.example.com. Because we have an "S" flag, our next step is to do an SRV lookup on _sip._udp.example.com.
# host -t SRV _sip._udp.example.com
_sip._udp.example.com SRV 5 100 5060 sip-udp01.example.com.
_sip._udp.example.com SRV 10 100 5060 sip-udp02.example.com.
We get two answers here so we'll use sip-udp01.example.com because it has the lower priority (5) and do an "A" record lookup to find where to send the TCP SIP session.
# host sip-udp01.example.com
sip-udp01.example.com has address 11.22.33.44
Of course this isn't usually done on the command line, but you get the idea. It's a good way to test. Be aware that some applications (OpenSER) prepend the protocol information (_sip._tcp or _sip._udp) automatically before doing SRV lookups. It is often easiest to check your tinydns / dnscache logs to see what clients are requesting.

Domain: example.com or 2.1.2.1.5.5.5.0.7.7.1.e164.arpa
Order: lower is picked first
Prefrence: lower is picked first
Flag: One of "S" (SRV), "A" (A, AAAA, A6), "U" (URI - use the RegExp field) or "P" (protocol specific)
Services: "SIP+D2U" is SIP over UDP. "SIP+D2T" is SIP over TCP. "SIP+D2S" for SIP over SCTP, "SIPS+D2T" is SIP over TLS (TCP).
Regular Expression: leave blank for no translation. avoid using slashes - example: !^.*$!sip:info@example.com!
Replacement: leave blank if regular expression filled in above.
Time To Live:


djbdns / tinydns AAAA (IPv6 AAAA record RFC 3596) Record Builder

Traditional IPv4 A records return a 32 bit IPv4 address. IPv6 addresses can't be returned because they occupy 128 bits, hence the AAAA record was created. tinydns doesn't support AAAA records nativly, so you must use a generic record to do the job. Use the form below to create a generic tinydns AAAA record.

Note: This tool also provides a reverse address to more closely mimic what tinydns supplies for A addresses. You can use both standard and short notation (::) in your IPv6 address. Zero-compressed notation (a:b::c:d instead of 000a:000b:0000:0000:0000:0000:000c:000d) will also work. Thanks to Matija Nalis for patches on this.
Name:
IPv6 Address:
Time To Live:


djbdns / tinydns CAA (Certification Authority Authorization record RFC 6844) Record Builder

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 allows you to explicitly list what CAs are authorized to issue certificates for your domain. A CA should check that they are listed in your CCA records as authorized to publish certificates for your domain before granting you a certificate.

The tag issue defines the host names of CAs to trust. For exmaple, example.com can restrict certificate issuance to ca.example.net by setting issue to ca.example.net. Multiple CAs can be configured by using multiple CAA records. Restricting certificate issuance is also possible by setting the issue tag to ;. This means no certificates should be issued for example.com or any subdomains.

The issuewild tag specifies that a CA is allowed to issue wildcard certificates (like *.example.com) for this domain. issuewild takes precedence over any issue declarations so be careful with these!

The iodef tag defines where users should report invalid certificate requests to the domain owner. They can be of many formats including email, (such as mailto:ca-issues@example.com) a host (such as ca.example.net) or a web address. (such as http://issues.example.com/) (IODEF stands for Incident Object Description Exchange Format and is covered by RFC5070) Additional parameters may be added with a semicolon and a space and then key=value pairs like this: ca.example.net; account=abc123

Domain:
Flags:
Tag:
Value:
Time To Live:


How This Works

The forms above are submitted to a perl script which creates tinydns configurations. If you need the logic from this page for your own project, please take a look at buildRecord.cgi. If you have any changes or additions to this script, please email Anders Brownworth at the email address at the bottom of this page or tweet me @anders94 on Twitter.

Derivative Works

Let me know if you have a project that stems from the ideas here.