Lesser known DNS entries
While the majority of people know about A, CNAME, and MX records, DNS actually has many dozens of types in common use, and many more dozens of faded historical use that aren’t used at all.
I wanted to mention a few current in use DNS records that you may or may not know about. There are many more, but here is just a sampling.
Many people use SPF DNS entries (although we question their utility), but use it with only a TXT record type. There has been a SFP DNS record type since 2006. The standard document for SPF (RFC 4408) specifies that either or both are currently recommend. The standard library that scans for SPF records can handle either or both. The only reason for keeping SPF records in TXT entries are that there are many online DNS editors that can’t deal with anything other than the most basic DNS types and they have no idea of anything other than TXT, A, MX, CNAME and SRV records (let alone any of the others I will mention here :)
We typically put in both or just the SPF entry if you ask for an SPF record, although, only the SPAMers and marketeers seem to have compliant SPF records, and nobody else..
The first useful application of DNSSec has actually been in use for a number of years in the form of SSHFP. DNSSec cryptographically authenticates the content of DNS, and if you follow the chain, you can be certain that the data obtained is authentic and correct. The SSH protocol used for remote access on Unix machines uses strong cryptography and the first things that you can do in most cryptography protocols is to verify the remote end is who they say they are. With SSH you get what is called a finger print, and verifying the finger print with the remote end tends to be a problem that many just skip.
With SSHFP, you put that finger print into the DNS records, so that the ssh command can verify the finger print for you. If the zone that has the SSHFP in it is DNSSec signed and authenticated, then ssh will trust that finger print to be authenticate and true, and will auto add it to your known hosts without going through the finger print verification stage you normall see for an unknown host.
One of the oldest on this list is LOC which simply lists the geographic location of the domain name down to a given longitude and latitude with a given precision of the information given.
There used to be some fun utilities that would traceroute through the country and show you physical locations based on the LOC DNS entries.
The geographic IP address databases maintained by companies like MaxMind and the like have negated the utility of the LOC entry, although MaxMind does get locations wrong all the time. It has become a big problem for operators getting new IP blocks (of what is left in the RIRs) that the geographic database providers have wrong info, and suddenly google redirects you to the Mexican google page or something on your new block.
If LOC were widely used, that wouldn’t happen, but now it is more historical curiosity than anything.
Many people know of CNAMEs, but there is also DNAME. With CNAME, you can map a single DNS FQDN over to a new FQDN. But with DNAME, you can alias a whole subdomain of a DNS record over to a whole new DNS tree.
Thus, you can make something like mail.iphouse.com DNAME over the top of mail.iphouse.net, and everything in mail.iphouse.net now would start to resolve for mail.iphouse.com as well.
Not many customers use subdomains at all but we do internally for our own internal machines and network gear. Another area where this record can be very useful is within the PTR trees, and mapping areas of PTRs over to other ones. (ie. especially for classless delegation of short prefixes); or for renumbering support while you are dealing with moves, instead of duplicating, just alias on top of the PTR trees.
while there isn’t a DANE record type, it is more memorable as the framework as a whole than the TLSA or SMIMEA record types that actually comprise it.
Like SSHFP, DANE will be the major DNSSec application in the future (this work hasn’t been finished yet at the IETF). DANE will cryptographicly authenticate TLS certificates in use for SSL/TLS websites, mail servers, jabber servers, S/MIME cryptographic encoded email, etc. etc. Everywhere an x.509 certificate is used today in order to protect services. DANE will authenticate that the certificate presented by that service is the one authorized by the domain holder.
DNSSec takes care of the cryptographically authentication, so that system needs to be in place already. Then the DNS admin needs to create TLSA entries with either the full x.509 certificate for a given service, or more likely, a secure SHA hash of the certificate to authenticate that a given cert is the correct use as deemed proper by the DNS admins as well as the server admins of a given domain name record.
I think that this framework will take off in a big way among the larger sites to provide robust cryptographic authentication of the SSL/TLS certificates to prevent the spoofing that can happen now-a-days due to weak CA security, or MiM attacks.
This is just a subset of all the DNS record types out there, but I find these to be some of the most interesting little known types out there. I’m especially looking forward to DANE being in common use, but will have to beef up our DNSSec implementations before that can become a reality.
Comments are closed.