Files
nexus/sreweekly/articles/281/04-all-dns-resource-records.html
2026-09-12 17:23:01 +08:00

2305 lines
89 KiB
HTML

<!DOCTYPE html>
<html lang="en">
<head>
<title>(All) DNS Resource Records</title>
<meta property="og:url" content="https://www.netmeister.org/blog/dns-rrs.html">
<meta name="robots" content="noai,noimageai">
<meta property="og:title" content="(All) DNS Resource Records">
<meta property="og:description" content="Just how many weird Resource Records can you stuff into a zone file? And what do these weird RRs actually return?">
<meta property="og:image" content="https://www.netmeister.org/blog/images/rrs.png">
<link rel="made" href="mailto:jschauma@netmeister.org">
<link rel="alternate" type="application/rss+xml" title="Signs of Triviality" href="https://www.netmeister.org/blog/rss.xml">
<link rel="stylesheet" type="text/css" href="blog.css">
</head>
<body>
<h1>Signs of Triviality</h1>
<em>Opinions, mostly my own, on the importance of being and other things. </em>
<hr width="100%" size=2 align="center" noshade>
<small>
[<a href="../index.html">homepage</a>]&nbsp;
[<a href="index.html">index</a>]&nbsp;
[<a href="mailto:jschauma@netmeister.org">jschauma@netmeister.org</a>]&nbsp;
[<a href="https://mstdn.social/@jschauma">@jschauma</a>]&nbsp;
[<a href="rss.xml">RSS</a>]
</small>
<input type="checkbox" id="theme-checker" hidden>
<div class="container">
<label class="switch" for="theme-checker" title="Dark/Light mode">
<span class="slider round"></span>
</label>
</div>
<hr width="100%" size=2 align="center" noshade>
<h2>(All) DNS Resource Records</h2>
<table border="0" width="75%">
<tr>
<td>
<p><small>July 15th, 2021</small></p>
<p>Okay, the Domain Name System (DNS) is wild. We all
know that. Nothing works without it, and when things
go really funky and make no sense, chances are it's
the DNS. Well, chances are somebody monkeyd around
with <tt>/etc/hosts</tt>, but yeah. </p>
<p>Now of course you all know the common DNS Resource
Records (RRs), right? You got your <tt>A</tt>,
<tt>AAAA</tt>, <tt>CNAME</tt>, <tt>NS</tt>,
<tt>MX</tt>, <tt>PTR</tt>, and... oh, right,
<tt>TXT</tt> records. And sure, you're probably aware
that there are more. But just how many more?</p>
<p>All in all, <a
href="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml">IANA
has almost 100 record types assigned</a>! A small
number of them are <em>reserved</em>, some are
<em>experimental</em>, and many are rarely, if ever,
actually used in the wild. But what if you'd like to
observe such records on the wire, make such queries
and receive a response? Well, here's your answer:</p>
<p>I created a DNS zone <tt>dns.netmeister.org.</tt>
that contains RRs for every RR type, each one named
after the type and each one holding two additional
<tt>TXT</tt> records, one noting the RR format, and
one the purpose and originating RFC(s). This zone is
<a
href="https://github.com/jschauma/dns-rrs/">available
on GitHub</a>, and is served live from
<tt>panix.netmeister.org</tt>:</p>
<div style="text-align: center;"><pre class="code">
$ dig +nocmd +nocomments +noquestion +nostats +multiline soa dns.netmeister.org.
dns.netmeister.org. 2082 IN SOA panix.netmeister.org. jschauma.netmeister.org. (
2021071323 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
3600000 ; expire (5 weeks 6 days 16 hours)
3600 ; minimum (1 hour)
)
$ </pre></div>
<p>(If you run into errors or do not get the responses
you expect -- perhaps because something on your local
network is monkeying around with your queries -- try
to <tt>dig</tt> or <tt>delv</tt>
<tt>@panix.netmeister.org</tt> directly.)</p>
<p>Here, let's go through the RRs, shall we? (You can
jump to any individual RR on this page via its respective
"#&lt;rr&gt;" anchor.)</p>
<hr width="75%">
<h2>RRs from <tt>A</tt> to <tt>ZONEMD</tt></h2>
<h3><a name="a"></a><tt>A</tt></h3>
<p>
Okay, no secrets or surprises here. Just an IPv4
address. But let's use this example to illustrate the
convenience of this zone:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short a a.dns.netmeister.org.
166.84.7.99
$ dig +short txt a.dns.netmeister.org.
"A 32-bit IPv4 host address. RFC882 (1983); RFC1035 (1987)"
"Format: a single dotted decimal quad IPv4 address"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc882">882</a>,
<a href="https://datatracker.ietf.org/doc/html/rfc1035">1035</a></p>
<h3><a name="aaaa"></a><tt>AAAA</tt></h3>
<p>Also no surprises -- your regular old IPv6 address
in colon-separated hextets:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short aaaa aaaa.dns.netmeister.org.
2001:470:30:84:e276:63ff:fe72:3900
$ dig +short txt aaaa.dns.netmeister.org.
"Format: single a hexadecimal IPv6 address"
"A 128-bit IPv6 host address. RFC1884 (1995); RFC4291 (2006)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc1884">1884</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc4291">4291</a></p>
<p>But... wait a second. Before there were
<tt>AAAA</tt> records, there were...</p>
<h3><a name="a6"></a><tt>A6</tt></h3>
<p>... <tt>A6</tt> records. This early version
included a <em>prefix</em> field and allowed you to
recursively construct IPv6 addresses from multiple
<tt>A6</tt> records, or to simply provide a final
address. The following examples illustrate this:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short a6 a6.dns.netmeister.org.
64 ::e276:63ff:fe72:3900 a6-prefix.dns.netmeister.org.
0 2001:470:30:84:e276:63ff:fe72:3900
$ dig +short a6 a6-prefix.dns.netmeister.org.
0 2001:470:30:84::
$ dig +short txt a6.dns.netmeister.org.
"Format: &lt;8-bit prefix&gt; &lt;128-bit hex IPv6 address&gt; &lt;prefix-name&gt;"
"Early IPv6 record, obsoleted by AAAA. RFC2874 (2000)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc2874">2874</a></p>
<h3><a name="afsdb"></a><tt>AFSDB</tt></h3>
<p>Yep, the DNS is not just a phone book for IP
addresses. It's long been used as a service discovery
mechanism, and this record type here allows for the
definition of an <a
href="https://en.wikipedia.org/wiki/Andrew_File_System">Andrew
File System</a> database server in an AFS cell:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short afsdb afsdb.dns.netmeister.org.
1 panix.netmeister.org.
$ dig +short txt afsdb.dns.netmeister.org.
"Location of a database server of an Andrew File System (AFS) cell. RFC1183 (1990)"
"Format: &lt;16-bit subtype&gt; &lt;domain-name&gt;"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc1183">1183</a></p>
<p>Note: the responses <tt>panix.netmeister.org</tt>
gives may or may not be meaningful. That is, I don't
actually run an AFS database server on this host, so
don't bother knocking.</p>
<h3><a name="amtrelay"></a><tt>AMTRELAY</tt></h3>
<p>Okay, now we're deep in wonky territory, where we are
offering records to publish Automatic Multicast
Tunneling (<a
href="https://datatracker.ietf.org/doc/html/rfc7450">AMT</a>)
relays for source-specific multicast channels, aka DNS
Reverse IP AMT Discovery (DRIAD):</p>
<div style="text-align: center;"><pre class="code">
$ dig +short amtrelay amtrelay.dns.netmeister.org.
10 0 2 2001:470:30:84:e276:63ff:fe72:3900
$ dig +short txt amtrelay.dns.netmeister.org.
"Format: &lt;8-bit precedence&gt; &lt;1-bit discover&gt; &lt;7-bit type&gt; &lt;domain-name&gt;"
"Automatic Multicast Tunneling Relay. RFC8777 (2020)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc8777">8777</a></p>
<p>Here we see for the first time a common pattern in
DNS service discovery: the encoding of a
<em>preference</em> or weight, as well as conditional
RDATA based on other selectors. We'll see many more
examples of this below.</p>
<h3><a name="any"></a><tt>ANY</tt></h3>
<p>I know, I know, I'm cheating. <tt>ANY</tt> isn't
really an RR type, it's a <tt>QTYPE</tt>. When asked
for <tt>ANY</tt> (<tt>QTYPE=*</tt>), the DNS server
will return all of the records for the given
name:</p>
<div style="text-align: center;"><pre class="code">
$ dig +nocmd +nocomments +noquestion +nostats +multiline any any.dns.netmeister.org.
any.dns.netmeister.org. 3600 IN RRSIG NSEC 13 4 3600 (
20210721144850 20210712212436 56039 dns.netmeister.org.
/7MZYmD6foyk/SUvQYo1VSBPE4iNqRcbrWE/FOJaOQXd
DxnNcS3u69rINdxhT2H94U5japP1JV+uWBE5+EC9XA==
)
any.dns.netmeister.org. 3600 IN NSEC apl.dns.netmeister.org. TXT RRSIG NSEC
any.dns.netmeister.org. 3600 IN RRSIG TXT 13 4 3600 (
20210721144850 20210712212436 56039 dns.netmeister.org.
Bxzo6dvL9O+06AKjjixoAm3Olhq5nivIFMudZ735MZs0
rwrdIanFFmAbNh2YmCi3TMze7CWVCtmknvSoW39SOA==
)
any.dns.netmeister.org. 3600 IN TXT "Pseudo-RR QTYPE value 255 ('*'). Returns all records. RFC1035 (1987)"
$ </pre></div>
<p>This shows the various records found in the zone
for <tt>any.dns.netmeister.org.</tt>, which include
the DNSSEC relevant records that we'll see in more
detail below.</p>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc882">882</a></p>
<p>(Some resolvers may choose not to answer
<tt>QTYPE=*</tt> (see also: <a
href="#hinfo"><tt>HINFO</tt></a>); some simply won't
have any data in their cache. Try to ask
<tt>@panix.netmeister.org</tt> directly.)</p>
<p>Oh, and note that of course the <tt>QTYPE=*</tt> is
different from the <em>wildcard</em> <tt>*</tt> in a
zone. <em>That</em> is used to return results for a
query for a name that's <em>not</em> in the zone:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short txt $$.dns.netmeister.org.
"Wildcard record matching any names _not_ in the zone."
$ dig +short txt ${RANDOM}.dns.netmeister.org.
"Wildcard record matching any names _not_ in the zone."
$ dig +short txt not-actually-found-in-the-zone.dns.netmeister.org.
"Wildcard record matching any names _not_ in the zone."
$ </pre></div>
<h3><a name="apl"></a><tt>APL</tt></h3>
<p>This one's a fun one. This record can be used to
translate a name into not a single address, but an
Address Prefix List (APL). What you do with the
results is, of course, up to you:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short apl apl.dns.netmeister.org.
1:192.168.32.0/21 !1:192.168.38.0/28 2:2001:db8::/32 !2:2001:470:30:84::/64
$ dig +short txt apl.dns.netmeister.org.
"Address Prefix List. RFC3123 (2001)"
"Format: {[!]afi:address/prefix}* -- whitespace separated strings; an
optional '!', a numerical address family indicator, ':', an address
prefix in CIDR notation"
$ </pre></div>
<p>Here, the <tt>afi</tt> is the Address Family
Indicator, defining IPv4 or IPv6 prefixes.</p>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc3123">3123</a></p>
<h3><a name="atma"></a><tt>ATMA</tt></h3>
<p>RFCs? Who needs RFCs? Why not just go with a
paper/proposal from the <a
href="https://web.archive.org/web/20190112072924/http://www.broadband-forum.org/ftp/pub/approved-specs/af-dans-0152.000.pdf">ATM
Forum</a> that nowadays is only available from (the
admittedly wonderful) <a
href="https://archive.org">Internet Archive</a>?</p>
<p>The <tt>ATMA</tt> record operates within the
Asynchronous Transfer Mode (ATM) Name System (ANS)
(acronyms of acronyms!), allowing you to map a name to
an ATM address:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short atma atma.dns.netmeister.org.
39246f000e7c9c03120001000100001234567800
$ dig +short txt atma.dns.netmeister.org.
"Format: &lt;address&gt;"
"ATM End System Address. ATM Forum Publication (2000)"
$ </pre></div>
<p>RFCs: <em>nope</em></p>
<h3><a name="avc"></a><tt>AVC</tt></h3>
<p>The <tt>AVC</tt> resource record was <a
href="https://www.iana.org/assignments/dns-parameters/AVC/avc-completed-template
">requested by Cisco</a> to map IP Flow Information
Export (IPFIX) names into the DNS:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short avc avc.dns.netmeister.org.
"app-name:Unix" "time|business:default|server-port:TCP/4242,UDP/4242"
$ dig +short txt avc.dns.netmeister.org.
"Application Visibility and Control. RR Submission (2016)"
"Format: &lt;RFC6759 shortened names&gt;"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc6759">6759</a></p>
<p>See also:<br>
<a
href="https://www.dns-as.org/what-is/metadata/">https://www.dns-as.org/what-is/metadata/</a><br>
<a
href="https://www.dns-as.org/support/avc-rdata/">https://www.dns-as.org/support/avc-rdata/</a></p>
<h3><a name="caa"></a><tt>CAA</tt></h3>
<p>You've probably come across those, as in recent
years Certificate Authorities (CAs) <a
href="https://archive.cabforum.org/pipermail/public/2017-March/009988.html">have
been required</a> to honoring these records to
determine whether they are actually allowed to issue a
certificate for the given domain name:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short caa caa.dns.netmeister.org.
0 iodef "mailto:abuse@netmeister.org"
0 issue ";"
0 issuewild ";"
$ dig +short txt caa.dns.netmeister.org.
"Indication of certificate authorities authorized to issue certificates for this
domain. RFC6844 (2013)"
"Format: &lt;flags&gt; &lt;tag&gt; &lt;value&gt; -- flag is commonly 1;
tag one of 'issue', 'issuewild', 'iodef' (others reserved or not yet defined);
value is a '&lt;character-string&gt;'"
</pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc6844">6844</a></p>
<p>The algorithm by which a CA will determine this
authorization starts at the most specific name and
then walks up the hierarchy. There is, however, one
caveat when you are using <tt><a
href="#cname">CNAME</a></tt> records to point to, e.g.,
third parties, as you (currently) <em>can't</em> set a
<tt>CAA</tt> record on a <tt>CNAME</tt>.</p>
<h3><a name="cdnskey"></a><tt>CDNSKEY</tt></h3>
<p>Yay, our first <a
href="https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions">DNSSEC</a>
related RR! The <tt>CDNSKEY</tt> is the child copy of
its <tt><a href="#dnskey">DNSKEY</a></tt> record, for
transfer to parent. In other words, it's what the
child zone would like its parent to use as its
<tt>DNSKEY</tt> record.</p>
<p>In order to facilitate updates to a child zone's <a
href="#dnskey"><tt>DNSKEY</tt></a>, a child can
advertize what the parent should include in its zone.
This record, like the <tt><a href="#cds">CDS</a></tt>
record discussed below, must then be signed by the
<em>current</em> <tt>DNSKEY</tt>.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short cdnskey cdnskey.dns.netmeister.org.
257 3 13 JErBf5lZ1osSWg7r51+4VfEiWIdONph0L70X0ToT7DkbikKQIp+qvuOOZri7j3qVComv7tgTIBhKxeDQercdKQ==
$ dig +short txt cdnskey.dns.netmeister.org.
"Child Copy of DSNKEY record, for transfer to parent. RFC7344 (2014)"
"Format: &lt;16-bit flags&gt; &lt;8-bit protocol&gt; &lt;8-bit algorithm&gt; &lt;base64-encoded pubkey&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc7344">7344</a></p>
<h3><a name="cds"></a><tt>CDS</tt></h3>
<p>Just like the <tt><a
href="#cdnskey">CDNSKEY</a></tt> record, the
<tt>CDS</tt> record is a child copy of the <tt><a
href="#ds">DS</a></tt> resource record for transfer to
the parent:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short cds cds.dns.netmeister.org.
56039 13 2 4104805B43928FC573F0704A2C1B5A10BAA2878DE26B8535DDE77517C154CE9F
$ dig +short txt cds.dns.netmeister.org.
"Format: &lt;16-bit key tag&gt; &lt;8-bit algorithm&gt; &lt;8-bit digest type&gt;
&lt;digest of owner name concatenated with the DNSKEY RDATA&gt;"
"Child Copy of DS record, for transfer to parent. RFC7344 (2014)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc7344">7344</a></p>
<h3><a name="cert"></a><tt>CERT</tt></h3>
<p>There's a whole lot of different ways of encoding
and distributing certificates or public keys via the
DNS. Which makes sense, since as a distributed lookup
table, it neatly solves many discovery problems
inherent in public key cryptography. Of course you do
need DNSSEC to be able to assign any trust to any of
these, but fortunately that's not a problem, because
of course your zone is signed. Right?</p>
<p>The <tt>CERT</tt> record can include a certificate
for many uses, including x509, S/MIME, PGP or IPSec.
Here are three examples, an OpenPGP signed public key,
a PGP fingerprint, and an x509 certificate (the actual
records are shortened here to make the display
easier):</p>
<div style="text-align: center;"><pre class="code">
$ dig +nocmd +nocomments +noquestion +nostats +multiline cert cert.dns.netmeister.org.
cert.dns.netmeister.org. 3544 IN CERT PGP 0 0 (
mQENBE2L+QkBCADx6DXFdqDEAK1OYYtOeLp54Z0G87t6
Nmz+nodbd9f4Uw0T6v32O2O0yVwA07fCGfPc+3oeCgDa
[...]
odY5Nsz1QchbMHN2FVmmFfrVpocnRQPm1lxqzxwoqJrU
TyWpk/J8/0PbKlSTjRKziFLqudSy/dqFWmk= )
cert.dns.netmeister.org. 3600 IN CERT IPGP 0 0 (
99CE1DC7770AC5A809A60DCD66CE4FE96F6BD3D7
)
cert.dns.netmeister.org. 3522 IN CERT PKIX 12848 RSASHA256 (
MIIFMzCCBBugAwIBAgISA5tDkCDwHTfvefYEFuzWCFaJ
MA0GCSqGSIb3DQEBCwUAMDIxCzAJBgNVBAYTAlVTMRYw
[...]
a22la0im/nvFrnQ9exW3T0YkDYGnIE8EewBAJjkBHoxg
5CNK5Rj2aPAwNZvWbkXp )
$ dig +short txt cert.dns.netmeister.org. | more
"Format: &lt;16-bit type&gt; &lt;16-bit key tag&gt; &lt;8-bit algorithm&gt; &lt;base64-encoded certificate or CRL&gt;"
"A certificate or certificate revocation list, including x509, S/MIME, PGP or
IPSec certificates. RFC2538 (1999); RFC4398 (2006)"
$ </pre></div>
<p>(By the way: GnuPG ships with a tool, <a
href="https://github.com/gpg/gnupg/blob/master/tools/make-dns-cert.c">make-dns-cert</a>,
to generate the CERT RR as a <tt>TYPE37</tt> hex
encoded record if your server does not support
<tt>CERT</tt>.)
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc2538">2538</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc4398">4398</a></p>
<p>See also: <a
href="#openpgpkey"><tt>OPENPGPKEY</tt></a></p>
<h3><a name="cname"></a><tt>CNAME</tt></h3>
<p>Ah, yes, the infamous <tt>CNAME</tt>. The record
that points to the <em>canonical name</em>. The
symlink of the DNS zone, endlessly used to redirect
people on the internet, and frequent cause of
certificate name mismatches.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short cname cname.dns.netmeister.org.
cname-txt.dns.netmeister.org.
$ dig +short txt cname.dns.netmeister.org
cname-txt.dns.netmeister.org.
"Additional records (besides DNSSEC related records) are not allowed on CNAMEs."
"Format: &lt;domain-name&gt;"
$ dig +short cname cname-loop.dns.netmeister.org.
cname-loop.dns.netmeister.org.
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc882">882</a></p>
<p>That's right: a <tt>CNAME</tt> can point to
anything. A valid name in the same zone, a name in
another zone, a name that doesn't exist, another
<tt>CNAME</tt>, or even <em>itself</em>. That is,
<tt>CNAME</tt>s have the potential to cause loops, and
you better be prepared to handle those:
<tt>cname01.dns.netmeister.org.</tt></p>
<p>As noted <a href="#caa">above</a>, a <tt>CNAME</tt>
cannot have other RRs associated -- well, aside from
the required DNSSEC records -- so there is no
accompanying <tt><a href="#txt">TXT</a></tt> record
here.</p>
<p>See also: <a href="#dname"><tt>DNAME</tt></a></p>
<h3><a name="csync"></a><tt>CSYNC</tt></h3>
<p>This record is used by a child zone to indicate to
a parent that it can copy certain records from its
zone. This is commonly used for, e.g., glue records,
like <a href="#ns"><tt>NS</tt></a>:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short csync csync.dns.netmeister.org.
2021071001 3 NS
$ dig +short txt csync.dns.netmeister.org.
"Child-to-Parent Synchronization, commonly used for glue records. RFC7477 (2015)"
"Format: &lt;32-bit SOA serial&gt; &lt;16-bit flags&gt; &lt;16-bit type bit map&gt;"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc7477">7477</a></p>
<p>Note that this is explicitly not intended to
synchronize DNSSEC records; for that, see <a
href="#cdnskey"><tt>CDNSKEY</tt></a> and <a
href="#cds"><tt>CDS</tt></a>.</p>
<h3><a name="dhcid"></a><tt>DHCID</tt></h3>
<p>Why yes, every Sysadmin's favorite magic service,
DHCP, joins in on the fun! Here's a record to encode
DHCP information to allow dynamic updates of FQDNs
after a client has obtained a lease without
conflicts.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short dhcid dhcid.dns.netmeister.org.
AAIBMmFjOTc1NzMyMTk0ZWE1ZTBhN2MzN2M4MzE2NTFiM2M=
$ dig +short txt dhcid.dns.netmeister.org.
"Format: SHA-256(&lt;identifier&gt; &lt;FQDN&gt;)"
"DHCP identifier. RFC4701 (2006)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc4701">4701</a></p>
<h3><a name="dlv"></a><tt>DLV</tt></h3>
<p>More DNSSEC records! This one's the <em>DNSSEC
Lookaside Validation</em> record. Normally, DNSSEC
depends on building the trust chain from the trust
anchor at the root (<tt>.</tt>); this record
facilitates the use of trust anchors published in a
zone that's not directly within the hierarchical
chain: a <em>lookaside</em> record:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short dlv dlv.dns.netmeister.org.
56039 13 2 4104805B43928FC573F0704A2C1B5A10BAA2878DE26B8535DDE77517C154CE9F
$ dig +short txt dlv.dns.netmeister.org.
"Format: &lt;16-bit key tag&gt; &lt;8-bit algorithm&gt; &lt;8-bit digest type&gt;
&lt;digest of owner name concatenated with the DNSKEY RDATA&gt;"
"DNSSEC Lookaside Validation used for off-path validation. RFC4431 (2006); RFC5074 (2007)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc4431">4431</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc5074">5074</a></p>
<p><a href="https://isc.org">ISC</a> used to run a <a
href="https://dlv.isc.org/">DLV Registry</a>; since as
of 2021 most TLDs are signed by default, the
<tt>DLV</tt> registry is no longer needed and was
discontinued. The use of the <tt>DLV</tt> record is
thus effectively deprecated.</p>
<h3><a name="dname"></a><tt>DNAME</tt></h3>
<p>Much like <a href="#cname"><tt>CNAME</tt></a>
records, <tt>DNAME</tt> records function as a method
of redirection. Unlike <tt>CNAME</tt>s, however,
<tt>DNAME</tt> records allow for redirection of
<em>all</em> records in a zone without the need to
create individual RRs.</p>
<p>That is, if you have a domain <tt>example.com</tt>
and then decide that you want to also allow the use
of, e.g., <tt>foo.example.net</tt>, but want to ensure
that <em>all</em> existing records under the first
domain redirect implicitly in the second, you'd add a
<tt>DNAME</tt> record:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short dname dname.dns.netmeister.org.
dns.netmeister.org.
$ dig +short txt dname.dns.netmeister.org.
"Format: &lt;domain-name&gt;"
"Delegation name record, used to, e.g., redirect an entire domain. RFC2672 (1999); RFC6672 (2012)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc2672">2672</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc6672">6672</a></p>
<p>This example means that <em>any</em> of the records
under <tt>dns.netmeister.org.</tt> can be resolved
under <tt>dname.dns.netmeister.org.</tt> as well:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short txt a.dname.dns.netmeister.org.
a.dns.netmeister.org.
"Format: a single dotted decimal quad IPv4 address"
"A 32-bit IPv4 host address. RFC882 (1983); RFC1035 (1987)"
$ </pre></div>
<h3><a name="dnskey"></a><tt>DNSKEY</tt></h3>
<p>One of the many DNSSEC records. This one contains
the public key matching the private key used to sign
the given zone. This record must match the hash
stored in the <a href="#ds"><tt>DS</tt></a> record in
the <em>parent</em> zone.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short dnskey dnskey.dns.netmeister.org.
257 3 13 XEn4q8CbG2a4Hw47Ih244BDkwY1tOuprXWKEzMyLPtjO9iIRVt4HLLbx9YaeaYzRcH 91mvCstP8I5liQ0Mn1bA==
$ dig +short txt dnskey.dns.netmeister.org.
"The public key matching the private key used to sign the given zone. RFC4034 (2005)"
"Format: &lt;16-bit flags&gt; &lt;8-bit protocol&gt; &lt;8-bit algorithm&gt; &lt;base64-encoded pubkey&gt;"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc4034">4034</a></p>
<p>See also: <a href="#cdnskey"><tt>CDNSKEY</tt></a>, <a
href="#cds"><tt>CDS</tt></a>, <a
href="#ds"><tt>DS</tt></a>, <a
href="#key"><tt>KEY</tt></a></p>
<h3><a name="doa"></a><tt>DOA</tt></h3>
<p>A Resource Record to stuff the Digital Object
Architecture into the DNS, effectively.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short doa doa.dns.netmeister.org.
0 1 2 "" aHR0cHM6Ly93d3cubmV0bWVpc3Rlci5vcmcvYmxvZy9kbnMtcnJzLmh0bWwK
$ dig +short txt doa.dns.netmeister.org.
"Digital Object Architecture in the DNS. Internet Draft (2017)"
"Format: &lt;32-bit doa-enterprise&gt; &lt;32-bit doa-type&gt; &lt;16-bit doa-location&gt; &lt;doa-media-type&gt; &lt;doa-data&gt;"
$ </pre></div>
<p>RFCs: none -- <a
href="https://www.ietf.org/archive/id/draft-durand-doa-over-dns-03.txt">expired internet draft</a>;
I guess it was Dead On Arrival, amiright?</p>
<h3><a name="ds"></a><tt>DS</tt></h3>
<p>The DNSSEC Delegation Signer public key record of
the given child zone stored in the parent zone:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short ds ds.dns.netmeister.org.
56393 13 2 BD36DD608262A026083721FA19E2F7B474F531BB3179CC00A0C38FF0 0CA11657
$ dig +short txt ds.dns.netmeister.org.
"Delegation signer; the DNSSEC public key of the given child zone stored in the parent zone. RFC4034 (2005)"
"Format: &lt;16-bit key tag&gt; &lt;8-bit algorithm&gt; &lt;8-bit digest type&gt;
&lt;digest of owner name concatenated with the DNSKEY RDATA&gt;"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc4034">4034</a></p>
<p>See also: <a href="#cdnskey"><tt>CDNSKEY</tt></a>, <a
href="#cds"><tt>CDS</tt></a>, <a
href="#dnskey"><tt>DNSKEY</tt></a></p>
<h3><a name="eid"></a><tt>EID</tt></h3>
<p>There's no shortage of weird architectures that are
mapped into or otherwise referenced from within the
DNS. This one's for the <em>Nimrod Routing
Architecture</em> endpoint identifiers:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short eid eid.dns.netmeister.org.
CAFEFACE1234
$ dig +short txt eid.dns.netmeister.org.
"Format: &lt;octets&gt;"
"Endpoint Identifier in the Nimrod Routing Architecture. Internet Draft (1995)"
$ </pre></div>
<p>RFCs: none -- <a
href="http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt">expired
internet draft</a></p>
<p>See also: <a href="#nimloc"><tt>NIMLOC</tt></a></p>
<h3><a name="eui48"></a><tt>EUI48</tt></h3>
<p>Who needs ARP? Let's just stuff into the DNS, why
not. MAC address to DNS name mappings:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short eui48 eui48.dns.netmeister.org.
bc-a2-b9-82-32-a7
$ dig +short txt eui48.dns.netmeister.org.
"48-bit IEEE Extended Unique Identifier; MAC address. RFC7043 (2013)"
"Format: six two-digit hexadecimal numbers separated by hyphens"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc7043">7043</a></p>
<p>See also: <a href="#eui64"><tt>EUI64</tt></a></p>
<h3><a name="eui64"></a><tt>EUI64</tt></h3>
<p>Same as <a href="#eui48"><tt>EUI48</tt></a>, but
for 64-bit Extended Unique Identifiers:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short eui64 eui64.dns.netmeister.org.
be-a2-b9-ff-fe-82-32-a7
$ dig +short txt eui64.dns.netmeister.org.
"64-bit IEEE Extended Unique Identifier; MAC address. RFC7043 (2013)"
"Format: eight two-digit hexadecimal numbers separated by hyphens"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc7043">7043</a></p>
<p>See also: <a href="#eui48"><tt>EUI48</tt></a></p>
<h3><a name="gpos"></a><tt>GPOS</tt></h3>
<p>An older record allowing for the encoding of
geographical location, largely superseded by the <a
href="#loc"><tt>LOC</tt></a> record:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short gpos gpos.dns.netmeister.org.
"40.731" "-73.9919" "10.0"
$ dig +short txt gpos.dns.netmeister.org.
"Format: &lt;longitude&gt; &lt;latitude&gt; &lt;altitude&gt;"
"Geographical Location, similar to LOC. RFC1712 (1994)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc1712">1712</a></p>
<p>See also: <a href="#loc"><tt>LOC</tt></a></p>
<h3><a name="hinfo"></a><tt>HINFO</tt></h3>
<p>An interesting RR from back in the days, when on
the internet we regularly advertised just what
hardware we were running, what operating system, and
what services we might offer. The <tt>HINFO</tt>
record provides the CPU and OS information -- or
rather, it used to:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short hinfo hinfo.dns.netmeister.org.
"PDP-11" "UNIX"
$ dig +short txt hinfo.dns.netmeister.org.
"Originally 'host information' like CPU and OS; now used by
Cloudflare in response to 'ANY' requests. RFC883 (1983); RFC8482 (2019)"
"Format: two &lt;character-string&gt;s of up to 40 chars each"
$ </pre></div>
<P>It since has since been
overloaded by <a
href="https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/">Cloudflare</a>
to return minimal responses to <a
href="#any"><tt>ANY</tt></a> queries:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short @ns3.cloudflare.com any cloudflare.com
"RFC8482" ""
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc883">883</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc8482">8482</a></p>
<p>See also: <a href="#any"><tt>ANY</tt></a>; the
early <a
href="http://pdp-10.trailing-edge.com/tops20_v6_1_tcpip_installation_tp_ft6/06/new-system/hosts.txt">DoD
Internet Host Table</a></p>
<h3><a name="hip"></a><tt>HIP</tt></h3>
<p>The <a
href="https://en.wikipedia.org/wiki/Host_Identity_Protocol">Host
Identity Protocol</a> (HIP) eliminates the use of IP
addresses in favor of Host Identities Tags (HITs)
based on the hash of a public key. The <tt>HIP</tt>
RRs allow you to store this information in our
favorite distributed database:</p>
<div style="text-align: center;"><pre class="code">
$ dig +nocmd +nocomments +noquestion +nostats +multiline hip hip.dns.netmeister.org.
hip.dns.netmeister.org. 2835 IN HIP ( 2
200100107B1A74DF365639CC39F1D578
AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p9+LrV4...
rvs.example.com. )
$ dig +short txt hip.dns.netmeister.org.
"Host Identity Protocol mappings of Host Identities and Host Identity Tags to IP addresses.
RFC5205 (2008); RFC8005 (2016)"
"Format: &lt;pk-algorithm&gt; &lt;base16-encoded-hit&gt; &lt;base64-encoded-public-key&gt;
&lt;rendezvous-server[1]&gt; ... &lt;rendezvous-server[n]&gt;"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc8002">8002"</a>, <a
href="https://datatracker.ietf.org/doc/html/rfc8005">8005</a></p>
<h3><a name="https"></a><tt>HTTPS</tt></h3>
<p>This is the special purpose <a
href="#svcb"><tt>SVCB</tt></a> record for use with
HTTPS, allowing clients to discover HTTPS parameters
beyond the IP address, such as, e.g., alternate
service endpoints or ports and <a
href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-08">Encrypted
Client Hello</a> parameters.</p>
<p>bind-9.16.15 does not yet have support for this
resource record, so I defined it as a raw
<tt>TYPE65</tt> record:</p>
<div style="text-align: center;"><pre class="code">
;https IN HTTPS 1 . (
; alpn="h3,h2"
; ipv6hint="2001:470:30:84:e276:63ff:fe72:3900"
; port="8080"
; echconfig="ZW5jcnlwdGVkIGNsaWVudCBoZWxsbwo=" )
https IN TYPE65 \# 123 2d6e2031202e20616c706e3d2268332c6832222069707...
; IN HTTPS 0 www.netmeister.org.
IN TYPE65 \# 25 2d6e2030207777772e6e65746d6569737465722e6f72672e0a
$ dig +nocmd +nocomments +noquestion +nostats +multiline TYPE65 https.dns.netmeister.org.
https.dns.netmeister.org. 3600 IN TYPE65 \# 123 ( 2D6E2031202E20616C706E3D2268332C683222206970
763668696E743D22323030313A3437303A33303A3834
3A653237363A363366663A666537323A333930302220
706F72743D22383038302220656368636F6E6669673D
225A57356A636E6C776447566B49474E736157567564
43426F5A57787362776F3D220A
)
https.dns.netmeister.org. 3600 IN TYPE65 \# 25 ( 2D6E2030207777772E6E65746D6569737465722E6F72
672E0A )
$ dig +short txt https.dns.netmeister.org.
"Format: &lt;16-bit SvcFieldPriority&gt; &lt;SvcDomainName&gt; &lt;SvcFieldValue&gt;"
"SVCB variation specifically for HTTP/HTTPS. IETF Draft (2020)"
$ </pre></div>
<p>RFCs: <a
href="https://www.rfc-editor.org/rfc/rfc9460.html">RFC9460</a></p>
<p>See also:<br>
<a
href="https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/">Cloudflare
blog post</a><br>
<a
href="https://ypcs.fi/howto/2020/09/30/announce-https-via-dns/">Announce
HTTPS via DNS (HTTPS + SVCB records)</a></p>
<h3><a name="ipseckey"></a><tt>IPSECKEY</tt></h3>
<p>One more RR to share key materials. This one for
use with <a
href="https://en.wikipedia.org/wiki/IPsec">IPsec</a>.
(As we'll see in a moment, there is a generic <a
href="#key"><tt>KEY</tt></a> record as well, but
<tt>IPSECKEY</tt> was explicitly created as a special
purpose RR here.)</p>
<div style="text-align: center;"><pre class="code">
$ dig +short ipseckey ipseckey.dns.netmeister.org.
10 0 2 . AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ==
$ dig +short txt ipseckey.dns.netmeister.org.
"Format: &lt;8-bit precedence&gt; &lt;8-bit gateway type&gt; &lt;8-bit algorithm&gt; &lt;40-bit gateway&gt; &lt;base64-encoded public-key&gt;"
"Public Key for use with IPSec; usually stored in the relevant in-addr.arpa / ip6.arpa zone. RFC4025 (2005)"
$ </pre></div>
<p>RFCs: <a
href="https://datatracker.ietf.org/doc/html/rfc4025">4025"</a></p>
<p>As with other, similar, records, we get a
<em>precedence</em> as well as an <em>algorithm</em>
selector. Note also that in IPSec, you often don't
have a name, but only an IP address, so the
<tt>IPSECKEY</tt> RR would then generally be found in
the "<a
href="/twitter/713903333375868928">temporary</a>"
<tt>in-addr.arpa</tt> / <tt>ip6.arpa</tt> domain.</p>
<h3><a name="isdn"></a><tt>ISDN</tt></h3>
<p>The DNS is a phonebook -- everybody knows that. So
sure, let's put <a
href="https://en.wikipedia.org/wiki/Integrated_Services_Digital_Network">ISDN</a>
phone numbers in it:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short isdn isdn.dns.netmeister.org.
"150862028003217" "004"
$ dig +short txt isdn.dns.netmeister.org.
"Format: &lt;ISDN-address&gt; &lt;optional sa&gt;"
"ISDN Telephone Number. RFC1183 (1990)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1183">1183</a></p>
<p>See also: <a href="#x25"><tt>X25</tt></a></p>
<h3><a name="key"></a><tt>KEY</tt></h3>
<p>The initial DNSSEC <tt>KEY</tt> record, now
obsoleted for DNSSEC by <a
href="#dnskey"><tt>DNSKEY</tt></a> and for IPsec by <a
href="#ipseckey"><tt>IPSECKEY</tt></a>. Used in
combination with the <a href="#sig"><tt>SIG</tt></a>,
<a href="#tkey"><tt>TKEY</tt></a> / <a
href="#tsig"><tt>TSIG</tt></a> records.
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short key key.dns.netmeister.org.
512 255 2 ACDtkdVR2HWmc0HPEwkrM+SOrWZd8yPTAytLYZj2u33KgwABAgAg6jav 9rTK68C8j+kfLv7+re8KAb1qJXqdSrmL+1l3Js4=
$ dig +short txt key.dns.netmeister.org.
"Format: &lt;16-bit flags&gt; &lt;8-bit protocol&gt; &lt;8-bit algorithm&gt; &lt;base64-encoded public key&gt;"
"Public Key associated name; used with, e.g., TSIG / SIG(0). Obsoleted for DNSSEC keys via DNSKEY,
for IPSec via IPSECKEY RRs. RFC2535 (1999); RFC2930 (2000); RFC2931 (2000)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2931">2931</a></p>
<h3><a name="kx"></a><tt>KX</tt></h3>
<p>
Key distribution and discovery is hard. So what do
you do if you need to find a specific key, but don't
know whom to ask? You ask the DNS!
</p>
<p>This record, again useful in, e.g., an IPSec
context, lets you discover the remote key exchanger
systems for a given destination:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short kx kx.dns.netmeister.org.
1 panix.netmeister.org.
$ dig +short txt kx.dns.netmeister.org.
"Format: &lt;16-bit preference&gt; &lt;domain-name&gt;"
"Key Exchange Delegation. RFC2230 (1997)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2230">2230</a></p>
<h3><a name="l32"></a><tt>L32</tt></h3>
<p> The <a
href="https://en.wikipedia.org/wiki/Identifier/Locator_Network_Protocol">Identifier/Locator
Network Protocol</a> (ILNP) is a network protocol
aimed to address multi-homing and inter-domain routing
scalabilitiy issues. It comes in two flavors (v4 and
v6); the <tt>L32</tt> record is used to provide a
32-bit locator value: </p>
<div style="text-align: center;"><pre class="code">
$ dig +short l32 l32.dns.netmeister.org.
10 203.0.113.44
$ dig +short txt l32.dns.netmeister.org.
"Identifier-Locator Network Protocol; 32-bit Locator. RFC6742 (2012)"
"Format: &lt;16-bit preference&gt; &lt;32-bit locator32&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc6742">6742</a></p>
<p>See also: <a href="#l64"><tt>L64</tt></a>, <a
href="#lp"><tt>LP</tt></a>, <a
href="#nid"><tt>NID</tt></a></p>
<h3><a name="l64"></a><tt>L64</tt></h3>
<p>The v6 version of the <a
href="#l32"><tt>L32</tt></a> record. Looks like an
IPv6 address, but is only 64 bits and must not use
the compressed display format (<tt>::</tt>):</p>
<div style="text-align: center;"><pre class="code">
$ dig +short l64 l64.dns.netmeister.org.
10 2001:db8:1140:1000
$ dig +short txt l64.dns.netmeister.org.
"Format: &lt;16-bit preference&gt; &lt;64-bit locator64&gt;"
"Identifier-Locator Network Protocol; 64-bit Locator. RFC6742 (2012)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc"></a></p>
<p>See also: <a href="#l32"><tt>L32</tt></a>, <a
href="#lp"><tt>LP</tt></a>, <a
href="#nid"><tt>NID</tt></a></p>
<h3><a name="loc"></a><tt>LOC</tt></h3>
<p>Similar to <a href="#gpos"><tt>GPOS</tt></a>, but
providing more detail, this record is used to stash
geolocation information in the DNS:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short loc loc.dns.netmeister.org.
40 44 9.000 N 73 59 26.000 W 10.00m 1m 10000m 10m
$ dig +short txt loc.dns.netmeister.org.
"Format: d-lat [m-lat [s-lat]] {" "N" "|" "S" "}
d-long [m-long [s-long]] {" "E" "|" "W" "} alt[" "m""]
[siz[" "m" "] [hp[" "m" "] [vp[" "m" "]]]]"
"Geographical information associated with a domain name. RFC1876 (1996)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1876">1876</a></p>
<p>See also: <a href="#gpos"><tt>GPOS</tt></a></p>
<h3><a name="lp"></a><tt>LP</tt></h3>
<p>Another ILNP record, this time used to hold the
name of a subnetwork, which should be a FQDN to then
be queried for their <tt>L32</tt>/<tt>L64</tt>
records:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short lp lp.dns.netmeister.org.
lp.dns.netmeister.org.
20 l32.dns.netmeister.org.
10 l64.dns.netmeister.org.
$ dig +short txt lp.dns.netmeister.org.
"Format: &lt;16-bit preference&gt; &lt;domain-name&gt;"
"Identifier-Locator Network Protocol; Locator Pointer. RFC6742 (2012)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc6742">6742</a></p>
<p>See also: <a href="#l32"><tt>L32</tt></a>, <a
href="#l64"><tt>L64</tt></a>, <a
href="#nid"><tt>NID</tt></a></p>
<h3><a name="maila"></a><tt>MAILA</tt></h3>
<p>The first of a number of mail related entries
largely obsoleted by the <a href="#mx"><tt>MX</tt></a>
record. This is not actually a resource record, but
again a <tt>QTYPE</tt> that would match the (equally
obsolete) <tt>MF</tt> and <tt>MD</tt> records. </p>
<h3><a name="mailb"></a><tt>MAILB</tt></h3>
<p>Similar to <a href="#maila"><tt>MAILA</tt></a>, a
query of type <tt>MAILB</tt> would return the
<tt>MB</tt>, <tt>MB</tt>, or <tt>MR</tt> records.
</p>
<h3><a name="mb"></a><tt>MB</tt></h3>
<p>While obsolete, the <tt>MB</tt> RR is still
supported and points to a mailbox name:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short mb mb.dns.netmeister.org.
panix.netmeister.org.
$ dig +short txt mb.dns.netmeister.org.
"Mailbox record. RFC883 (1983); not formally obsoleted"
"Format: &lt;domain-name&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a></p>
<h3><a name="md"></a><tt>MD</tt></h3>
<p>An obsolete and no longer supported "mail delivery"
record, specifying the host that is expected to have
the mailbox in question.
</p>
<h3><a name="mf"></a><tt>MF</tt></h3>
<p>An obsolete and no longer supported "mail
forwarding" record to specify hosts that are expected
to be intermediaries willing to accept the
mail for eventual forwarding.
</p>
<h3><a name="mg"></a><tt>MG</tt></h3>
<p>
A "mail group". That is, we used to use the DNS as a
mailing list expander, allowing you to point one name
to multiple mailboxes. Unlike some of the other
mailbox related records, <tt>MG</tt> is not formally
obsoleted:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short mg mg.dns.netmeister.org.
jschauma.netmeister.org.
digestingducks.netmeister.org.
jschauma.yahoo.com.
$ dig +short txt mg.dns.netmeister.org.
"Format: &lt;mailbox&gt;"
"Mail Group (mailing list) record. RFC883 (1983); not formally obsoleted"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a></p>
<h3><a name="minfo"></a><tt>MINFO</tt></h3>
<p>Mail Information. This record is generally
associated with an <a href="#mg"><tt>MG</tt></a> and
contains two mailbox names: one listing the
responsible person for the mail group (i.e., the list
owner whom you can bother to subscribe or unsubscribe
you), the second a mailbox that should receive error
messages relating to the mail group:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short minfo minfo.dns.netmeister.org.
jschauma.netmeister.org. postmaster.netmeister.org.
$ dig +short txt minfo.dns.netmeister.org.
"Format: &lt;responsible mailbox&gt; &lt;error mailbox&gt;"
"Responsible and error handling mailbox. RFC883 (1983); not formally obsoleted"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a></p>
<h3><a name="mr"></a><tt>MR</tt></h3>
<p>A Mail Rename record. The mailer should replace
the old mailbox with the new record:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short mr mr.dns.netmeister.org.
panix.netmeister.org.
$ dig +short txt mr.dns.netmeister.org.
"Format: &lt;domain-name&gt;"
"Mail Rename record. RFC883 (1983); not formally obsoleted"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc833">833</a></p>
<h3><a name="mx"></a><tt>MX</tt></h3>
<p>Finally, a record that we're familiar with, the
Mail Exchange delegation. Like so many other service
discovery records, it comes with a <em>preference</em>
to let you specify multiple mail servers that should
be tried in order
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short mx mx.dns.netmeister.org.
50 panix.netmeister.org.
$ dig +short txt mx.dns.netmeister.org.
"Mail Exchange Delegation. RFC1035 (1987)"
"Format: &lt;16-bit preference&gt; &lt;domain-name&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc974">974</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc1035">1035</a></p>
<h3><a name="naptr"></a><tt>NAPTR</tt></h3>
<p>
Okay, we're back to weird again. The <a
href="https://en.wikipedia.org/wiki/Dynamic_Delegation_Discovery_System">Dynamic Delegation
Discovery System</a> uses the DNS as, what else, a
convenient distributed database, encoding rules in
"Naming Authority Pointer" records.
</p>
<p>These records allow you to specify, e.g., regular
expressions to rewrite domain names or URNs, and,
depending on the context, may be found in the reverse
<tt>.arpa</tt> zones. Here are some contrived
examples:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short naptr naptr.dns.netmeister.org.
10 10 "u" "smtp+E2U" "!.*([^.]+[^.]+)$!mailto:postmaster@$1!i" .
20 10 "s" "http+N2L+N2C+N2R" "" www.netmeister.org.
$ dig +short txt naptr.dns.netmeister.org.
"Naming Authority Pointer; regular expression rewriting of domain names, commonly used
with, e.g., SIP. RFC2915 (2000); RFC3403 (2002)"
"Format: &lt;16-bit order&gt; &lt;16-bit preference&gt; &lt;character-string flags&gt; &lt;characer-string services&gt;
&lt;character-string regex&gt; &lt;domain-name&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc3403">3403</a></p>
<p>See also: <a
href="https://en.wikipedia.org/wiki/Telephone_number_mapping">Telephone
number mapping</a> using <a
href="https://en.wikipedia.org/wiki/E.164">E.164</a>
number to URI mapping (ENUM); <a
href="https://datatracker.ietf.org/doc/html/rfc6116">RFC6116</a></p>
<h3><a name="nid"></a><tt>NID</tt></h3>
<p><p>Another ILNP record, this time used to hold the
<em>Node Identifier</em> with an assigned preference:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short nid nid.dns.netmeister.org.
10 14:4fff:ff20:ee64
$ dig +short txt nid.dns.netmeister.org.
"Identifier-Locator Network Protocol; Node Identifier. RFC6742 (2012)"
"Format: &lt;16-bit preference&gt; &lt;64-bit nodeid&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc"></a></p>
<p>See also: <a href="#l32"><tt>L32</tt></a>, <a
href="#l64"><tt>L64</tt></a>, <a
href="#lp"><tt>LP</tt></a></p>
<h3><a name="nimloc"></a><tt>NIMLOC</tt></h3>
<p>Part of the Nimrod Routing Architecture, the
<tt>NIMLOC</tt> record is used ro reference a Nimrod
"Locator", a topologically significant "name=" for a
Nimrod node:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short nimloc nimloc.dns.netmeister.org.
DEADBEEF1234
$ dig +short txt nimloc.dns.netmeister.org.
"Format: &lt;octets&gt;"
"Nimrod Locator in the Nimrod Routing Architecture. Internet Draft (1995)"
$ </pre></div>
<p>RFCs: none -- <a
href="http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt">expired
internet draft</a></p>
<p>See also: <a href="#eid"><tt>EID</tt></a></p>
<h3><a name="ninfo"></a><tt>NINFO</tt></h3>
<p>
This record was initially requested to be named
<tt>ZS</tt> for Zone Status, and is intended to
provide (arbitary) information about the zone itself,
such as the significance of its contents or the last
update date etc. (Some of this information is relayed
via the <a href="#soa"><tt>SOA</tt></a> record.)
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short ninfo ninfo.dns.netmeister.org.
"The zone owner is asleep, so don't bother trying voice-based communication."
$ dig +short txt ninfo.dns.netmeister.org.
"Zone Status information, initially requested as 'ZS'. Internet Draft (2008)"
"Format: &lt;text&gt;"
$ </pre></div>
<p>RFCs: none -- <a
href="https://www.ietf.org/archive/id/draft-reid-dnsext-zs-01.txt">expired internet draft</a></p>
<h3><a name="ns"></a><tt>NS</tt></h3>
<p>Hey, <tt>NS</tt> records! I know what those are!
Records that tell you what nameservers are
authoritative for a given zone. The records that
completely pwn you when controlled by an adversary.
The ones that take down your entire site if they go
down, and which several companies <a
href="/twitter/1373019238470983680">nowadays
distribute across different TLDs for global
redundancy</a>. </p>
<div style="text-align: center;"><pre class="code">
$ dig +short ns ns.dns.netmeister.org.
panix.netmeister.org.
$ dig +short txt ns.dns.netmeister.org.
"Format: &lt;domain-name&gt;"
"Naming Authority Pointer; delegates authority of the given domain to the given name server.
RFC883 (1983); RFC1035 (1987)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a></p>
<h3><a name="nsap"></a><tt>NSAP</tt></h3>
<p>Here we have Network Service Access Point addresses
used in the <a
href="https://en.wikipedia.org/wiki/Connectionless-mode_Network_Service">Connectionless-mode
Network Service</a> (CLNS) datagram services mapped
into the DNS, why not: </p>
<div style="text-align: center;"><pre class="code">
$ dig +short nsap nsap.dns.netmeister.org.
0x47000580005a0000000001e133ffffff00016100
$ dig +short txt nsap.dns.netmeister.org.
"Network Service Access Point. RFC1706 (1994)"
"Format: &lt;nsap&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1706">1706</a></p>
<h3><a name="nsap-ptr"></a><tt>NSAP-PTR</tt></h3>
<p>Reversing <a href="#nsap"><tt>NSAP</tt></a>
addresses is done via the <tt>NSAP-PTR</tt> record,
which would normally be found in the respective
<tt>nsap.int</tt> domain:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short nsap-ptr nsap-ptr.dns.netmeister.org.
nsap.dns.netmeister.org.
$ dig +short txt nsap-ptr.dns.netmeister.org.
"Format: &lt;domain-name&gt;"
"NSAP to name mapping. Usually found in the 'nsap.int' domain. RFC1706 (1994)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1706">1706</a></p>
<h3><a name="nsec"></a><tt>NSEC</tt></h3>
<p>And we're back to DNSSEC. In DNSSEC, the
<tt>NSEC</tt> record indicates the <em>next
secure</em> record. This can be used to prove the
non-existence of a given record, and by walking these
records, you are able to iterate the entire zone.
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short nsec nsec.dns.netmeister.org.
nsec3.dns.netmeister.org. TXT RRSIG NSEC
$ dig +short txt nsec.dns.netmeister.org.
"Next secure record. Used to, e.g., prove non-existence of a record. RFC4034 (2005)"
"Format: &lt;domain-name&gt;gt; &lt;16-bit type bit map&gt;gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc4304">4304</a></p>
<p>Now since iterating over an entire zone may not be
what you want to let everybody do, we then came up
with...
<h3><a name="nsec3"></a><tt>NSEC3</tt></h3>
<p>...the <em>next secure record, version 3</em>.
This record doesn't leak the names, but uses the next
<em>hashed</em> owner name, which still lets you prove
non-existence:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +dnssec +nocmd +nocomments +noquestion +nostats +multiline nsec3 nsec3.dns.netmeister.org.
nsec3.dns.netmeister.org. 3600 IN SOA panix.netmeister.org. jschauma.netmeister.org. (
2021071404 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
3600000 ; expire (5 weeks 6 days 16 hours)
3600 ; minimum (1 hour)
)
nsec3.dns.netmeister.org. 3600 IN RRSIG SOA 13 4 3600 (
20210728163906 20210714153906 24381 nsec3.dns.netmeister.org.
f7EGHoqXBB20QAQEqyxuVZPcWWwQXqMWsbJkp/2viWtt
oOvI4elv3l4MJle/4GlaTO4sBan9oPxU/r7B+pO1cQ== )
SVFTOLJMUBKMAV5F31Q74AIE460GHTPE.nsec3.dns.netmeister.org. 3600 IN NSEC3 1 0 15 B07196F16C26C4EA (
SVFTOLJMUBKMAV5F31Q74AIE460GHTPE
NS SOA TXT RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY )
SVFTOLJMUBKMAV5F31Q74AIE460GHTPE.nsec3.dns.netmeister.org. 3600 IN RRSIG NSEC3 13 5 3600 (
20210728001204 20210714153906 24381 nsec3.dns.netmeister.org.
ZmRCKWj3Puqor3gTgOlxKrv1wvVl62deOKm1U+YmhGHR
UQOKsQzvUJ7fb9jshIo3cyN1GpKQmGfH1F9NrxhSfQ== )
$ dig +short txt nsec3.dns.netmeister.org.
"Next secure record, v3, to prove authenticated denial of existence. RFC5155 (2008)"
"Format: &lt;8-bit hash algorithm&gt; &lt;8-bit flags&gt; &lt;16-bits iterations&gt; &lt;8-bit salt length&gt; &lt;24-bit salt&gt;
&lt;8-bit hash-length&gt; &lt;24-bit next hashed owner name&gt; &lt;16-bit type bit map&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc5155">5155</a></p>
<p>Note that you need the records are generated by the
server, and you thus need to query a resolver that
supports DNSSEC (<tt>+dnssec</tt>).</p>
<h3><a name="nsec3param"></a><tt>NSEC3PARAM</tt></h3>
<p>The <tt>NSEC3</tt> records are calculated using
specific paramters which are included in the
<tt>NSEC3PARAM</tt> record. They include the hash
algorithm, iterations, and a salt:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short nsec3param nsec3param.dns.netmeister.org.
1 0 15 4DE657B8A848081D
$ dig +short txt nsec3param.dns.netmeister.org.
"Parameters used for NSEC3. RFC5155 (2008)"
"Format: &lt;8-bit hash algorithm&gt; &lt;8-bit flags&gt; &lt;16-bit iterations&gt; &lt;8-bit salt length&gt; &lt;24-bit salt&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc5155">5155</a></p>
<p>Note: the <tt>NSEC3PARAM</tt> value is actually
included in the <tt>NSEC3</tt> response and can then
be used to confirm the correct next name using, e.g.,
<a href="https://github.com/shuque/nsec3hash">this
useful tool</a>:</p>
<div style="text-align: center;"><pre class="code">
$ dig +dnssec +nocmd +nocomments +noquestion +nostats nsec3 nsec3.dns.netmeister.org. | \
grep "IN NSEC3"
<font color="blue">2RM96JUOJE08UCPDC2LVLUDUEFAPNLHE</font>.nsec3.dns.netmeister.org. 3600 IN NSEC3 \
<b>1 0 15 1C9B2F7BBFB115E4</b> \
<font color="red">08R5BALN9R7QHEACJTNHAKHFDMD89ULQ</font> \
NS SOA TXT RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY
$ python nsec3hash.py <b>1C9B2F7BBFB115E4 1 15</b> nsec3.dns.netmeister.org.
<font color="blue">2RM96JUOJE08UCPDC2LVLUDUEFAPNLHE</font>
$ dig +short txt next.nsec3.dns.netmeister.org.
"A text record so that we can show the use of NSEC3."
$ python nsec3hash.py <b>1C9B2F7BBFB115E4 1 15</b> next.nsec3.dns.netmeister.org.
<font color="red">08R5BALN9R7QHEACJTNHAKHFDMD89ULQ</font>
$ dig +dnssec +nocmd +nocomments +noquestion +nostats nsec3 next.nsec3.dns.netmeister.org. | \
grep "IN NSEC3"
<font color="red">08R5BALN9R7QHEACJTNHAKHFDMD89ULQ</font>.nsec3.dns.netmeister.org. 3600 IN NSEC3 \
<b>1 0 15 1C9B2F7BBFB115E4</b> \
<font color="blue">2RM96JUOJE08UCPDC2LVLUDUEFAPNLHE</font> \
TXT RRSIG
</pre></div>
<p>In other words, we have shown that there are no
other records in the zone besides the apex records and
the "<tt>next</tt>" text record, but we could not have
discovered "<tt>next</tt>" without knowing it!</p>
<h3><a name="null"></a><tt>NULL</tt></h3>
<p>This one's sneaky: <a
href="https://datatracker.ietf.org/doc/html/rfc1035">RFC1035</a>
defines it as an "experimental" RR allowing any data
whatsoever, "so long as it is 65535 octets
or less." However, it also specifies that
<tt>NULL</tt> records are not allowed in master files,
so, e.g., <tt>bind</tt> will refuse to load a zone with
a <tt>NULL</tt> record.</p>
<p>However, you can specify it in the zone file using
the <a
href="https://www.rfc-editor.org/rfc/rfc3597">generic
opaque record format</a>:</p>
<div style="text-align: center;"><pre class="code">
null IN TYPE10 \# 7 61766f6361646f
$ dig +short null.dns.netmeister.org
null \# 7 61766F6361646F
$ dig +short null.dns.netmeister.org txt
"Format: <anything>"
"Placeholder records in some experimental extensions. RFC883 (1983)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a>, <a href="https://datatracker.ietf.org/doc/html/rfc1035">1035</a></p>
<h3><a name="nxt"></a><tt>NXT</tt></h3>
<p>When DNSSEC was first drafted, the problem of how
to assert authoritatively the non-existence of a
record was initially solved using the <tt>NXT</tt>
record. This is no longer automatically calculated
(since we have <a href="#nsec"><tt>NSEC</tt></a> and
<a href="#nsec3"><tt>NSEC3</tt></a>), so I've stubbed
one out here:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short nxt nxt.dns.netmeister.org.
openpgpkey.dns.netmeister.org. TXT OPENPGPKEY
$ dig +short txt nxt.dns.netmeister.org.
"Precursor to NSEC/NSEC3. RFC2065 (1997)"
"Format: &lt;domain-name&gt; &lt;16-bit type bit map&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2065">2065</a>, <a href="https://datatracker.ietf.org/doc/html/rfc3755">3755</a></p>
<h3><a name="openpgpkey"></a><tt>OPENPGPKEY</tt></h3>
<p>We already saw one way to store a PGP key in the
DNS by using the <a href="#cert"><tt>CERT</tt></a>
record above. But there are <a
href="https://slxh.nl/blog/2016/pgp-and-dns/">quite a
few ways</a>, and here we use the <tt>OPENPGP</tt>
record, in context of <a
href="https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities">DANE</a>:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +multiline +nocmd +nocomments +noquestion +nostats openpgpkey openpgpkey.dns.netmeister.org.
openpgpkey.dns.netmeister.org. 3600 IN OPENPGPKEY ( mQENBE2L+QkBCADx6DXFdqDEAK1OYYtOeLp54Z0G87t6
Nmz+nodbd9f4Uw0T6v32O2O0yVwA07fCGfPc+3oeCgDa
[...]
odY5Nsz1QchbMHN2FVmmFfrVpocnRQPm1lxqzxwoqJrU
TyWpk/J8/0PbKlSTjRKziFLqudSy/dqFWmk= )
$ dig +short txt openpgpkey.dns.netmeister.org.
"OpenPGP Public Key record, used within DANE. RFC7929 (2016)"
"Format: base64-encoded OpenPGP Transferable Public Key"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc7929">7929</a></p>
<p>DNSSEC is valuable here, since you want to
establish authenticity of the key. But you also want
to have a way to automatically discover these records
without having to know what the owner name to look
up is. For that, RFC7929 establishes a standardized
location -- only, that gets tricky, because of course
<a href="email.html">email addresses can be all sorts
of funky</a>. So instead of the rather convenient
<tt>jschauma.netmeister.org.</tt> label, I have to
use:</p>
<div style="text-align: center;"><pre class="code">
$ dig +multiline +nocmd +nocomments +noquestion +nostats openpgpkey \
f6d6048431f8b67313b5b8011e0be5b03f21b4458a7e67f3fb298900._openpgpkey.netmeister.org.
f6d6048431f8b67313b5b8011e0be5b03f21b4458a7e67f3fb298900._openpgpkey.netmeister.org. \
10800 IN OPENPGPKEY ( \
mQENBE2L+QkBCADx6DXFdqDEAK1OYYtOeLp54Z0G87t6 \
Nmz+nodbd9f4Uw0T6v32O2O0yVwA07fCGfPc+3oeCgDa \
ct5cpicAm1C1nF3XrcV6YCAccswybl11ZnlJBOtu1ieP \
[...]
odY5Nsz1QchbMHN2FVmmFfrVpocnRQPm1lxqzxwoqJrU \
TyWpk/J8/0PbKlSTjRKziFLqudSy/dqFWmkAAguQ )
$ </pre></div>
<p>You can use <a
href="https://www.huque.com/bin/openpgpkey">this
site</a> to generate the right <tt>OPENPGPKEY</tt>
entry from your key.</p>
<p>See also: <a href="cert"><tt>CERT</tt></a>,
<a href="dnssec-dane.html">New Adventures in DNSSEC and DANE</a></p>
<h3><a name="ptr"></a><tt>PTR</tt></h3>
<p>Okay, back in save waters. <tt>PTR</tt> is something
we all know and use all the time. Although virtually
every lookup you perform of this type is likely to be
for IP addresses reversed in the <tt>in-addr.arpa</tt>
/ <tt>ip6.arpa</tt> domains, but you can add it in any
zone (even if that may not be useful):
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short ptr ptr.dns.netmeister.org.
ptr.dns.netmeister.org.
$ dig +short txt ptr.dns.netmeister.org.
"Format: &lt;domain-name&gt;"
"Domain Name Pointer; commonly found in the in-addr.arpa and ip6.arpa domains and
used in reverse lookups. RFC1035 (1987)"
$ </pre></div>
<p>As you probably know, the usual host lookup
requires you to reverse the IP address (and translate
from hex to decimal for IPv6 nibbles). So a normal
<tt>PTR</tt> lookup of an address will not actually
work. Fortunately, your common host lookup tools are
kind enough to do the right thing for you when you
pass it an IP address without specifying the RR
type:</p>
<div style="text-align: center;"><pre class="code">
$ host www.netmeister.org
www.netmeister.org is an alias for panix.netmeister.org.
panix.netmeister.org has address 166.84.7.99
panix.netmeister.org has IPv6 address 2001:470:30:84:e276:63ff:fe72:3900
$ dig +short ptr 166.84.7.99
$ dig +short ptr 2001:470:30:84:e276:63ff:fe72:3900
$ dig +short ptr 99.7.84.166.in-addr.arpa
panix.netmeister.org.
$ dig +short ptr 0.0.9.3.2.7.e.f.f.f.3.6.6.7.2.e.4.8.0.0.0.3.0.0.0.7.4.0.1.0.0.2.ip6.arpa
panix.netmeister.org.
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a></p>
<h3><a name="px"></a><tt>PX</tt></h3>
<p>Aaaaaaand we're back to stashing weird things into
the DNS. This time mapping information needed by <a
href="https://datatracker.ietf.org/doc/html/rfc2156">Mime
Internet X.400 Enhanced Relay</a> (MIXER) conformant
e-mail gateways and other tools to map <a
href="https://datatracker.ietf.org/doc/html/rfc822">RFC822</a>
domain names into X.400 O/R names and vice versa.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short px px.dns.netmeister.org.
10 px.dns.netmeister.org. PRMD-netmeister.C-us.G-Jan.S-Schaumann.dns.netmeister.org.
$ dig +short txt px.dns.netmeister.org.
"Map domain names into X.400 O/R names. RFC2163 (1998)"
"Format: &lt;16-bit preference&gt; &lt;domain-name&gt; &lt;x400-in-domain-syntax&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2163">2163</a></p>
<h3><a name="rp"></a><tt>RP</tt></h3>
<p>The <tt>RP</tt> record assigns a <em>responsible
person</em> for the given domain name. Because we
know that there's a lot of responsible people involved
in putting data into the DNS, I suppose.
</p>
<p>The <a href="#soa"><tt>SOA</tt></a> record includes
a responsible person for the zone, but that person may
not be responsible for each individual node, so the
<tt>RP</tt> record lets you be more specific by (a)
defining a contact and (b) a separate domain name,
which should contain additional information in it's
<a href="#txt"><tt>TXT</tt></a> record:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short rp rp.dns.netmeister.org.
jschauma.netmeister.org. contact.netmeister.org.
$ dig +short txt rp.dns.netmeister.org.
"Format: &lt;mbox-dname&gt; &lt;txt-dname&gt;"
"Responsible Person. RFC1183 (1990)"
$ dig +short txt contact.netmeister.org.
"Email preferred, but you can also find me at https://mstdn.social/@jschauma."
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1183">1183</a></p>
<h3><a name="rrsig"></a><tt>RRSIG</tt></h3>
<p>The DNSSEC <em>Resource Record Digital
Signature</em> <tt>RRSIG</tt> record contains the
digital signatures associated with the given name and
are generated automatically by the (DNSSEC enabled)
nameserver:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +multiline +nocmd +nocomments +noquestion +nostats rrsig rrsig.dns.netmeister.org.
rrsig.dns.netmeister.org. 3521 IN RRSIG NSEC 13 4 3600 (
20210726001627 20210713021645 56039 dns.netmeister.org.
zp+/jdn4LXLMcsrg47CvsykcTh3gQBrq+f78yOVqwjgE
P9iWJOoSk3mK/rNu0VeBLSwMEpWCu4H6DFv6cFJWVw== )
rrsig.dns.netmeister.org. 3521 IN RRSIG TXT 13 4 3600 (
20210728112730 20210714104850 56039 dns.netmeister.org.
voZozkv+icMI8Z4Whg2QxcboK2RUbXMS/2IHqxcLUc62
ATR1zo4RwlacuspVqzcbvKYq7o8aCfCZh7rIiPG4rA== )
$ dig +short txt rrsig.dns.netmeister.org.
"DNSSEC Signature of the Resource Record Set. RFC4034 (2005)"
"Format: &lt;16-bit type covered&gt; &lt;8-bit algorithm&gt; &lt;8-bit labels&gt; &lt;32-bit TTL&gt; \
&lt;32-bit signature expiration&gt; &lt;32-bit signature inception&gt; &lt;16-bit key tag&gt; \
&lt;40-bit signers name&gt; &lt;base64-encoded signature&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc4034">4034</a></p>
<p>Here we again see the <a
href="#nsec"><tt>NSEC</tt></a> record, which is signed
just like the <a href="#txt"><tt>TXT</tt></a> record.
The records are signed with the domain's private key
matching the <a href="#dnskey"><tt>DNSKEY</tt></a>
record.</p>
<p>Note that a given <tt>RRSIG</tt> covers
<em>all</em> records of a given type, which is why we
see only <em>one</em> <tt>RRSIG</tt> in the above for
<em>two</em> <tt>TXT</tt> records.</p>
<h3><a name="rt"></a><tt>RT</tt></h3>
<p>The <em>Route Through</em> (<tt>RT</tt>) record
provides a preference and intermediate host to be used
to route or relay through when talking to the owner:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short rt rt.dns.netmeister.org
10 panix.netmeister.org.
$ dig +short txt rt.dns.netmeister.org
"Format: &lt;16-bit preference&gt; &lt;intermediate-host&gt;"
"Route Through RR. RFC1183 (1990)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1183">1183</a></p>
<h3><a name="sig"></a><tt>SIG</tt></h3>
<p>Another signature record! This was replaced
in DNSSEC by the <a href="#rrsig"><tt>RRSIG</tt></a>
records, but may still be used in other context.
These records are generated by the server in
combination with the <a href="#key"><tt>KEY</tt></a>,
<a href="#tkey"><tt>TKEY</tt></a> / <a
href="#tsig"><tt>TSIG</tt></a> records.
</p>
<p><tt>bind(8)</tt> only uses <tt>SIG</tt> records
when using <tt>nsupdate(8)</tt>.</p>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2535">2535</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc2931">2931</a>,
<a
href="https://datatracker.ietf.org/doc/html/rfc4034">4034</a></p>
<h3><a name="sink"></a><tt>SINK</tt></h3>
<p>Ah, finally a record that speaks the truth! The
<tt>SINK</tt> record was intended to provide a general
purpos "kitchen sink" record to obviate the need to
stuff weird things into, say, <a
href="#txt"><tt>TXT</tt></a> records. It never took
off, though, and <a
href="https://gitlab.isc.org/isc-projects/bind9/-/issues/1202">bind
even implements it with an undocumented additional
field</a>. But this is what it'd look like:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short sink sink.dns.netmeister.org
0 64 1 ZG5zLm5ldG1laXN0ZXIub3JnLg==
$ dig +short txt sink.dns.netmeister.org
"Kitchen Sink record to allow stuffing just about anything into the DNS without
requiring new RRs to be defined. Internet draft (1997)"
"Format: &lt;coding&gt; &lt;subcoding&gt; &lt;base64 data&gt;"
$ </pre></div>
<p>RFCs: none -- <a
href="https://tools.ietf.org/html/draft-eastlake-kitchen-sink">expired internet draft</a></p>
<h3><a name="smimea"></a><tt>SMIMEA</tt></h3>
<p>
This one's kind of like <a
href="#openpgpdata"><tt>OPENPGPDATA</tt></a>, in that
you want to make an <a
href="https://en.wikipedia.org/wiki/S/MIME">S/MIME</a>
certificate to an identity, and so normally you'd also
use the same mechanism to map a user's email address.
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short smimea smimea.dns.netmeister.org
3 1 1 8CE14CBE1FAFAE9FB25845D335E00E416BC2FAE02E8746689C006DA5 9C1F9382
$ dig +short txt smimea.dns.netmeister.org
"S/MIME certificate association. RFC8162 (2017)"
"Format: &lt;8-bit cert usage&gt; &lt;8-bit selector&gt; &lt;8-bit matching type&gt;
&lt;base64-encoded certificate data&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc8162">8162</a></p>
<h3><a name="soa"></a><tt>SOA</tt></h3>
<p>Every zone has a <em>Start of Authority</em>
record, which includes the responsible name server,
responsible person, and information about the zone:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +multiline +nocmd +nocomments +noquestion +nostats soa soa.dns.netmeister.org.
soa.dns.netmeister.org. 3600 IN SOA panix.netmeister.org. jschauma.netmeister.org. (
2021071108 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
3600000 ; expire (5 weeks 6 days 16 hours)
3600 ; minimum (1 hour)
$ dig +short txt soa.dns.netmeister.org
"Start of Authority information about the given zone. RFC883 (1983); RFC1035 (1987)"
"Format: &lt;domain-name&gt; &lt;domain-name&gt; &lt;32-bit serial&gt; &lt;32-bit refresh interval&gt; \
&lt;32-bit retry interval&gt; &lt;32-bit expiration interval&gt; &lt;32-bit minimum TTL&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc883">883</a></p>
<h3><a name="spf"></a><tt>SPF</tt></h3>
<p>The <a
href="https://en.wikipedia.org/wiki/Sender_Policy_Framework">Sender
Policy Framework</a> started using <a
href="#txt"><tt>TXT</tt></a> records to define a
policy for a domain, but of course stashing even more
information into <tt>TXT</tt> records is silly, so a
new RR was created: <tt>SPF</tt>. Nobody adopted this
record, and everybody still uses <tt>TXT</tt> records,
however.
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short spf spf.dns.netmeister.org
"v=spf1 a mx -all"
$ dig +short txt spf.dns.netmeister.org
"Format: &lt;spf text&gt;"
"Sender Policy Framework alternative to TXT record. RFC4408 (2006)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc4408">4408</a></p>
<h3><a name="srv"></a><tt>SRV</tt></h3>
<p>The <tt>SRV</tt> record is used to help clients
find the correct service endpoint for the given name.
It is most commonly used via <tt>_port._protocol</tt>
records, such as, e.g., <tt>_kerberos._udp</tt> or
<tt>_ldap._tcp</tt>:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short srv srv.dns.netmeister.org
0 1 80 panix.netmeister.org.
$ dig +short txt srv.dns.netmeister.org
"Format: &lt;16-bit priority&gt; &lt;16-bit weight&gt; &lt;16-bit port&gt; &lt;domain-name&gt;"
"Service location records. Commonly something like _port._protocol. RFC2052 (1996); RFC2782 (2000)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2782">2782</a></p>
<p>See also: <a href="#svcb"><tt>SVCB</tt></a>, <a
href="https://datatracker.ietf.org/doc/html/rfc6763">RFC6763</a></p>
<h3><a name="sshfp"></a><tt>SSHFP</tt></h3>
<p>What do you do when you <tt>ssh</tt> to a host and
get this warning?</p>
<div style="text-align: center;"><pre class="code">
$ ssh somehost
The authenticity of host 'somehost' ([203.0.113.4]:22)' can't be established.
ECDSA key fingerprint is SHA256:YkdaIvHk8JWUIGU5qv+Qpu2qurG6b0pnqzkGF3RVz4Q.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
</pre></div>
<p>You type <tt>yes</tt>. And in all likelihood, you
change your <tt>~/.ssh/config</tt> to set
<tt>StrictHostKeyChecking no</tt>, to boot. In the
history of the internet, not a single person has ever
validated the SSH hostkey.
</p>
<p>And it's a difficult problem, anyway. Rebuilding a
system changes the key and then you get a conflict.
Now, you <em>could</em> use SSH certificates, which
solves many of these problems, but you could also...
guess what... stuff the information into the DNS!</p>
<div style="text-align: center;"><pre class="code">
$ dig +short sshfp sshfp.dns.netmeister.org
3 2 62475A22F1E4F09594206539AAFF90A6EDAABAB1BA6F4A67AB390617 7455CF84
1 1 53A76D5284C91E140DEC9AD1A757DA123B95B081
$ dig +short txt sshfp.dns.netmeister.org
"SSH Public Key Fingerprints. RFC4255 (2006)"
"Format: &lt;8-bit algorithm&gt; &lt;8-bit fingerprint type&gt; &lt;fingerprint&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc4255">4255</a></p>
<p>Now note that of course you (again) need DNSSEC for
OpenSSH to accept and trust the fingerprints from the
DNS. It's almost as if DNSSEC was a good idea to
assert the authenticity of the data in our favorite
globally distributed database...</p>
<h3><a name="svcb"></a><tt>SVCB</tt></h3>
<p>The more generic version of the <a
href="#https"><tt>HTTPS</tt></a> record we saw above.
Similar to before, we're using <tt>TYPE64</tt> since
<tt>bind(8)</tt> hasn't implemented <tt>SVCB</tt> yet:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +multiline +nocmd +nocomments +noquestion +nostats TYPE64 svcb.dns.netmeister.org.
svcb.dns.netmeister.org. 3575 IN TYPE64 \# 85 ( 2D6E20312070616E69782E6E65746D6569737465722E
6F72672E206970763668696E743D22323030313A3437
303A33303A38343A653237363A363366663A66653732
3A333930302220706F72743D2238383838220A )
$ dig +short txt svcb.dns.netmeister.org.
"General Purpose Service Binding. IETF Draft (2020)"
"Format: &lt;16-bit SvcFieldPriority&gt; &lt;SvcDomainName&gt; &lt;SvcFieldValue&gt;"
$ </pre></div>
<p>RFCs: none -- <a
href="https://www.rfc-editor.org/rfc/rfc9460.html">RFC9460</a></p>
<p>See also: <a href="#https"><tt>HTTPS</tt></a><br>
<a
href="https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/">Cloudflare
blog post</a><br>
<a
href="https://ypcs.fi/howto/2020/09/30/announce-https-via-dns/">Announce
HTTPS via DNS (HTTPS + SVCB records)</a></p>
<h3><a name="ta"></a><tt>TA</tt></h3>
<p>DNSSEC depends on an established trust hierarchy
down from the root (<tt>.</tt>). The proposal for a
<tt>TA</tt> record allows for DNSSEC without a signed
root by defining <em>Trusted Authorities</em> that may
make statements for their target zones:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short ta ta.dns.netmeister.org.
56039 13 2 4104805B43928FC573F0704A2C1B5A10BAA2878DE26B8535DDE77517 C154CE9F
$ dig +short txt ta.dns.netmeister.org.
"DNSSEC Trust Authorities; proposed for DNSSEC without a signed root. No RFC (2005)."
"Format: &lt;16-bit key tag&gt; &lt;8-bit algorithm&gt; &lt;8-bit digest type&gt;
&lt;digest of owner name concatenated with the DNSKEY RDATA&gt;"
$ </pre></div>
<p>RFCs: none -- <a
href="http://www.watson.org/~weiler/INI1999-19.pdf">proposal
from CMU</a>
<h3><a name="talink"></a><tt>TALINK</tt></h3>
<p>In a way similar to the <a
href="#ta"><tt>TA</tt></a> record, this record allows
the zone administrator to establish a doubly linked
list of names that contain <a
href="#dnskey"><tt>DNSKEY</tt></a> data.
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short talink talink.dns.netmeister.org.
. _talink1.dns.netmeister.org.
$ dig +short talink _talink1.dns.netmeister.org.
talink.dns.netmeister.org. _talink2.dns.netmeister.org.
$ dig +short talink _talink2.dns.netmeister.org.
_talink2.dns.netmeister.org. .
$ dig +short txt talink.dns.netmeister.org.
"Format: &lt;domain-name&gt; &lt;domain-name&gt;"
"DNSSEC Trust Anchor History. Internet Draft (2009)"
$ </pre></div>
<p>RFCs: none -- <a
href="https://datatracker.ietf.org/doc/html/draft-wijngaards-dnsop-trust-history-02">expired
internet draft</a>
<h3><a name="tkey"></a><tt>TKEY</tt></h3>
<p>Hey, we have <em>yet</em> another record to hold
keys, this one for <em>Transaction Keys</em>, used to
establish shared secret keys for use with Transaction
Signature (<a href="#tsig"><tt>TSIG</tt></a>) records.
This record is really a meta-RR that is not actually
stored in the DNS, nor found in the zone. </p>
<p><tt>bind(8)</tt> only supports Diffie-Hellman key
exchange modes and requires that the client includes
an appropriate <a href="#key"><tt>KEY</tt></a> record
in the "additional" section of the query and be signed
using either a <a href="#tsig"><tt>TSIG</tt></a> or <a
href="#sig"><tt>SIG(0)</tt></a> using a previously
established key.</p>
<p>In other words: it's complicated.</p>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc2930">2930</a></p>
<h3><a name="tlsa"></a><tt>TLSA</tt></h3>
<p>Look, it's our <a
href="dnssec-dane.html">good friend DANE</a>! This
time coming to the rescue and making the traditional
public CA hierarchy for Transport Layer Security (TLS) obsolete.
</p>
<p>That is, using the <tt>TLSA</tt> records in a
DNSSEC signed zone, a client could verify the
authenticity of the certificate offered by a given
remote service without having to rely on a trust
bundle of hundreds of certificates provided by CAs
with a profit interest in selling certificates.</p>
<div style="text-align: center;"><pre class="code">
$ dig +short tlsa tlsa.dns.netmeister.org.
3 1 1 8CE14CBE1FAFAE9FB25845D335E00E416BC2FAE02E8746689C006DA5 9C1F9382
$ dig +short txt tlsa.dns.netmeister.org.
"Format: &lt;8-bit usage&gt; &lt;8-bit selector&gt; &lt;8-bit matching type&gt; &lt;cert data&gt;"
"DANE record for TLS. RFC6698 (2012)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc6698">6698</a></p>
<p>Note: the TLSA record is usually associated with a
service name using the <tt>_port._protocol</tt>
format. The above result is actually the correct TLSA
record for this website, found at
<tt>_443._tcp.panix.netmeister.org.</tt>.</p>
<h3><a name="tsig"></a><tt>TSIG</tt></h3>
<p>
This signature record is generated by the server and
requires a shared key between the client and server.
That is, you'd first generate a secret key to be
included in your server configuration, then share this
with the client and allow the client to make the
request:
</p>
<div style="text-align: center;"><pre class="code">
$ tsig-keygen tsig.dns.netmeister.org.
key "tsig.dns.netmeister.org." {
algorithm hmac-sha256;
secret "g3VNiujhmzuXdEVTV0SiVG0ad2ViTI/AtiPMCDjj77s=";
};
$ dig +multiline +nocmd +nocomments +noquestion +nostats \
-y hmac-sha256:tsig.dns.netmeister.org:g3VNiujhmzuXdEVTV0SiVG0ad2ViTI/AtiPMCDjj77s= \
tsig tsig.dns.netmeister.org.
tsig.dns.netmeister.org. 0 ANY TSIG hmac-sha256. 1626303929 300 32 (
qNZ1VviSJTtqX+czOMuAxU34Zx2FG0qsTb/EypPLOC8= ) 30681 NOERROR 0
# Using an old or invalid key:
$ dig +multiline +nocmd +nocomments +noquestion +nostats \
-y hmac-sha256:tsig.dns.netmeister.org:d2hhdGV2ZXIK \
tsig tsig.dns.netmeister.org.
;; Couldn't verify signature: tsig indicates error
tsig.dns.netmeister.org. 0 ANY TSIG hmac-sha256. 1626304045 300 0 44982 BADSIG 0
$ dig +short txt tsig.dns.netmeister.org.
"Format: &lt;algorithm name&gt; &lt;48-bit time signed&gt; &lt;16-bit fudge&gt; &lt;16-bit MAC size&gt;
&lt;MAC&gt; &lt;16-bit oid&gt; &lt;16-bit error&gt; &lt;16-bit other size&gt; &lt;other data&gt;"
"Transaction Signature, used to authenticate, e.g., dynamic client updates or server responses
by way of a shared secret (e.g., TKEY). RFC2845 (2000); RFC8945 (2020)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc8945">8945</a></p>
<p>See also: <a href="#key"><tt>KEY</tt></a>, <a
href="#sig"><tt>SIG</tt></a>, <a
href="#tkey"><tt>TKEY</tt></a>.</p>
<p>Note: since I'm sharing the shared key here, there
is of course now <em>no</em> guarantee of authenticity
of the signatures. Don't trust <tt>TSIG</tt>'s from
this DNS server. :-)</p>
<h3><a name="txt"></a><tt>TXT</tt></h3>
<p>Our true kitchen sink. None of this <a
href="#sink"><tt>SINK</tt></a> nonsense. A record
intended for "descriptive text" that is now completely
overloaded and used for... well, let's see:
</p>
<ul>
<li>GnuPG <a
href="https://www.grepular.com/Publishing_PGP_Keys_in_the_DNS">discovery of public keys</a> using
<tt>local._pka</tt> labels</li>
<li>SPF instead of, uhm, <a href="#spf"><tt>SPF</tt></a> records</li>
<li><a href="https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail">DKIM records</a></li>
<li><a href="https://en.wikipedia.org/wiki/DMARC">DMARC</a> records</li>
<li><a href="https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_MTA_Strict_Transport_Security">SMTP MTA Strict Transport Security</a></li>
<li><a
href="https://datatracker.ietf.org/doc/html/rfc8460">SMTP TLS Reporting</a></li>
<li>proof of domain overship for <a href="https://uk.godaddy.com/help/verify-domain-ownership-html-or-dns-for-my-ssl-certificate-7452">Certificate Authority Domain Validation</a></li>
<li><a href="https://support.google.com/webmasters/answer/9008080">Google Site Verification</a></li>
<li><a href="https://developers.facebook.com/docs/sharing/domain-verification/">Facebook Domain Verification</a></li>
<li><a
href="https://docs.aws.amazon.com/ses/latest/DeveloperGuide/dns-txt-records.html">Amazon SES domain validation</a></li>
<li><a
href="/twitter/1361437634648805378">Use of domain validation by just about any cloud service</a></li>
<li><a href="https://dnssecuritytxt.org/">Security
contacts via DNS records</a>, similar to <a
href="https://securitytxt.org/">security.txt</a>: e.g.,
<tt>_security.netmeister.org</tt></li>
<li><a
href="https://datatracker.ietf.org/doc/html/rfc6763">DNS-based
Service Discovery</a> (RFC6763)</li>
<li>...</li>
</ul>
<div style="text-align: center;"><pre class="code">
$ dig +short txt txt.dns.netmeister.org.
"Format: &lt;text&gt;"
"Descriptive text. Completely overloaded for all sorts of things. RFC1035 (1987)"
$ dig +short txt jschauma._pka.netmeister.org.
"v=pka1;fpr=99CE1DC7770AC5A809A60DCD66CE4FE96F6BD3D7;uri=https://www.netmeister.org/public_key.gpg.asc"
$ dig +short txt netmeister.org.
"v=spf1 a mx -all"
$ dig +short txt 2021._domainkey.netmeister.org.
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwSwZZHRcoVIHxjlETstEBKt/
YiLFpZ0VGvz1ufZLVWKuOF1iKJOF/rDjzehyNK2CkJscPzcuMV6zMQyxiEOOPl4Pkugd4G27G4klqLK9TZ
EC3a77Iy4c1gu+10CSjsPPZgNCflLxmw/VtPs6n/ENgZyH6HUAv04yw8aMQnVnwlQIDAQAB"
$ dig +short txt _dmarc.netmeister.org.
"v=DMARC1; p=quarantine; pct=100; rua=mailto:postmaster@netmeister.org"
$ dig +short txt _mta-sts.netmeister.org.
"v=STSv1; id=20210324T224413"
$ dig +short txt _smtp._tls.netmeister.org.
"v=TLSRPTv1; rua=https://www.netmeister.org/cgi-bin/report-uri?tls-rpt,mailto:postmaster@netmeister.org"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1035">1035</a>,
<a href="https://datatracker.ietf.org/doc/html/rfc6376">6376</a>,
<a href="https://datatracker.ietf.org/doc/html/rfc7489">7489</a>,
<a href="https://datatracker.ietf.org/doc/html/rfc7208">7208</a>,
<a href="https://datatracker.ietf.org/doc/html/rfc8461">8461</a>
</p>
<h3><a name="uri"></a><tt>URI</tt></h3>
<p>This is another one of those service discovery
records overlapping with <a
href="#srv"><tt>SRV</tt></a> and <a
href="#naptr"><tt>NAPTR</tt></a> records, for example.
Normally, you'd set these on <tt>_service._proto</tt>
names.
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short uri uri.dns.netmeister.org.
10 1 "https://www.netmeister.org/blog/dns-rrs.html"
$ dig +short txt uri.dns.netmeister.org.
"Format: &lt;16-bit priority&gt; &lt;16-bit weight&gt; &lt;uri&gt;"
"URI selection. Improvement / complement to NAPTR / SRV. RFC7553 (2015)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc7553">7553</a></p>
<h3><a name="wks"></a><tt>WKS</tt></h3>
<p>The <em>Well Known Services</em> record again
reflects the olden days much like <a
href="#hinfo"><tt>HINFO</tt></a> did: a way to tell the
world what services your host is offering, i.e., what
ports it has open:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short wks wks.dns.netmeister.org.
166.84.7.99 6 25 80 443
166.84.7.99 17 53
$ dig +short txt wks.dns.netmeister.org.
"Format: &lt;32-bit IP address&gt; &lt;16-bit protocol&gt; &lt;8-bit bit map&gt;"
"Well Known Services. RFC883 (1983); not formally obsoleted, but recommended
against in, e.g., RFC1123 (1989)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc833">833</a></p>
<h3><a name="x25"></a><tt>X25</tt></h3>
<p>Similar to <a href="#isdn"><tt>ISDN</tt></a>
records, <a
href="https://en.wikipedia.org/wiki/X.25">X.25</a>
Public Switched Data Network (PSDN) addresses can be
mapped into the DNS using the <tt>X25</tt> RR:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short x25 x25.dns.netmeister.org.
"311061700956"
$ dig +short txt x25.dns.netmeister.org.
"Format: &lt;PSDN-address&gt;"
"Experimental representation of X.25 addresses. RFC1183 (1990)"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc1183">1183</a></p>
<h3><a name="zonemd"></a><tt>ZONEMD</tt></h3>
<p>
A message digest for the entire zone - why would you
need that, if you have DNSSEC? Well, DNSSEC covers
individual records, but <tt>ZONEMD</tt> covers the
entire zone all in one go, and as such is set on the
apex:
</p>
<div style="text-align: center;"><pre class="code">
$ dig +short zonemd zonemd.dns.netmeister.org.
2021071219 1 1 4274F6BC562CF8CE512B21AA0A4CCC1EB9F4FAAAECD01642D0A07BDE A890C8845849D6015CC590F54B0AC7E87B9E41ED
$ dig +short txt zonemd.dns.netmeister.org.
"Message Digest for zone data. RFC8976 (2021)"
"Format: &lt;32-bit serial&gt; &lt;8-bit scheme&gt; &lt;8-bit hash algorithm&gt; &lt;digest&gt;"
$ </pre></div>
<p>RFCs: <a href="https://datatracker.ietf.org/doc/html/rfc8976">8976</a></p>
<p>You can calculate the <tt>ZONEMD</tt> hash using,
e.g., <a
href="https://github.com/niclabs/dns-tools">this
tool</a>.</p>
<p>&nbsp;</p>
<hr width="75%">
<p>&nbsp;</p>
<p>And there you have it: 80 DNS Resource Records from
<a href="#a"><tt>A</tt></a> to <a
href="#zonemd"><tt>ZONEMD</tt></a>, all
able to be queried and returning reasonable results.
Quite a few more than you normally would encounter,
I'd wager, but all in all a pretty good illustration
of the ubiquity and flexibility of the DNS beyond just
mapping hostnames to IP addresses.</p>
<p>You may also encounter an RR of <tt>TYPE65534</tt>,
which <tt>bind(8)</tt> <a
href="https://bind9.readthedocs.io/en/latest/advanced.html#private-type-records">uses
to signal the signing state</a>, or the <tt>OPT</tt> pseudo-RR used
per <a
href="https://datatracker.ietf.org/doc/html/rfc6891">RFC6891</a>
in the additional data section for EDNS requests
(e.g., <a
href="https://en.wikipedia.org/wiki/EDNS_Client_Subnet">EDNS
Client Subnet</a> (ECS)).</p>
<p>In addition it's worth noting that the DNS does not
only cover the <tt>IN</tt> (i.e., Internet) class, but
is also used within the <a
href="https://en.wikipedia.org/wiki/Hesiod_(name_service)">Hesiod</a>
and <a
href="https://en.wikipedia.org/wiki/Chaosnet">Chaosnet</a>
protocols. For example, you can ask the <a
href="https://www.isc.org/f-root/">F-Root</a> to show
you which of the many locations you conncted to by
querying it for a (what else) <tt>TXT</tt> record in
the <tt>CHAOS</tt> class:</p>
<div style="text-align: center;"><pre class="code">
$ dig +short @f.root-servers.net hostname.bind chaos txt
"EWR.cf.f.root-servers.org"
$ </pre></div>
<p>The first three letters of the returned hostname
are the IATA three letter airport code (although use
of the <a href="#loc"><tt>LOC</tt></a> record would
have been neat, I think).</p>
<p>As noted above, the zone file served from
<tt>panix.netmeister.org</tt> for the
<tt>dns.netmeister.org</tt> zone is available <a
href="https://github.com/jschauma/dns-rrs/">on
GitHub</a>, so if I made any mistakes, please <a
href="mailto:jschauma@netmeister.org">let me
know</a> and/or submit a pull request!</p>
<p><small>July 15th, 2021</small></p>
<hr width="90%">
<p><small>See also:</small></p>
<ul>
<li><small>A related Twitter thread: <a
href="https://twitter.com/pgl/status/1405614755000295427">Rule 53: if you can think of it, someone's done it in the DNS</a></small></li>
<li><small><a href="whois.html">WHOIS: Fragile, unparseable, obsolete... and universally relied upon</a></small></li>
<li><small><a href="hostnames.html">What's in a hostname?</a></small></li>
<li><small><a href="tlds.html">TLDs -- Putting the 'Fun' in the top of the DNS</a></small></li>
<li><small><a href="dnssec-dane.html">New Adventures in DNSSEC and DANE</a></small></li>
<li><small><a href="doh-dot-dnssec.html">DNS Security: Threat Modeling DNSSEC, DoT, and DoH</a></small></li>
<li><small><a href="dns-tcpdump.html">DNS tcpdump by example</a></small></li>
<li><small>Video series: The Domain Name System, <a href="https://youtu.be/-bpIT7M9i00">Part I</a>, <a href="https://youtu.be/z55ULZcKP8A">Part II</a>, <a href="https://youtu.be/XDJEJFVNoko">Part III</a></small></li>
<li><small><a href="https://www.bortzmeyer.org/dns-lg-usage.html">DNS Looking Glass</a></small></li>
<li><small>Discussion on <a href="https://news.ycombinator.com/item?id=27852601">Hacker News</a></small></li>
<li><small>Discussion on <a href="https://lobste.rs/s/a9ruj0">Lobsters</a></small></li>
</ul>
</td>
</tr>
</table>
<HR WIDTH="100%" SIZE=2 ALIGN="CENTER" NOSHADE>
<small>
&larr;[<a href="urls.html">URLs: It's complicated...</a>]
<div style="float: right;">[<a href="ddg-tor.html">DuckDuckGo Onion Search for Firefox</a>] &rarr;</div>
</small>
<hr class="noshade" style="width:100%;">
<small>
[<a href="../index.html">homepage</a>]&nbsp;
[<a href="index.html">blog</a>]&nbsp;
[<a href="mailto:jschauma@netmeister.org">jschauma@netmeister.org</a>]&nbsp;
[<a href="https://mstdn.social/@jschauma/">@jschauma</a>]&nbsp;
[<a href="rss.xml">RSS</a>]
</small>
<div class="container">
<label class="switch" for="theme-checker" title="Dark/Light mode">
<span class="slider round"></span>
</label>
</div>
<HR WIDTH="100%" SIZE=2 ALIGN="CENTER" NOSHADE>
</body>
</html>