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.
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.
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.
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
Record Wizard at the official SPF site.
djbdns / tinydns DomainKeys (Generic Text) Record Builder (RFC Draft)
Yahoo's DomainKeys plan calls for the use of
DNS TXT records to distribute public keys that can be used to verify the authenticity of individual
emails. 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 768 bit private key using openssl: openssl genrsa -out rsa.private 768 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:
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.
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" signifies a terminal rule in ENUM and URI applications, so the output of this
rewrite will be the answer we are looking for. 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.
Here we find that example.com suggests "SIP+D2T" or SIP over TCP at _sip._tcp.example.com.
Our next step is to find the SRV record for _sip._tcp.example.com.
We get two answers here so we'll use sip-tcp01.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-tcp01.example.com
sip-tcp01.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. Check your tinydns /
dnscache logs to see what clients are asking for.
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: You must have 8 hex numbers seperated by 7 colons (:) in your IPv6 address however zero-compressed
notation (a:b:::::c:d instead of 000a:000b:0000:0000:0000:0000:000c:000d) will also work.
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.
Once to every man and nation,
comes the moment to decide,
In the strife of truth with falsehood,
for the good or evil side;
Some great cause,
some great decision,
offering each the bloom or blight,
And the choice goes by forever,
'twixt that darkness and that light.
"In our sleep, pain that cannot forget falls drop by drop upon the heart and in our despair, against our will comes wisdom through the awful grace of God."
~ Aeschylus
"Some men see things as they are and ask 'Why?'. I dream of things
things that never were and ask 'Why not?'"
~ RFK
"In dreams begin responsibilities."
~ U2
"... we do these things not because they are easy, but because they are hard!"