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.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
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)
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 1024chmod 600 rsa.privateGet your public key:
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEMPut 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.txtThe 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.txtIf 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.
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.44Of 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.
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.
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=abc123How 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.- Doug Kelly's PowerDNS to djbdns converter