2305 lines
89 KiB
HTML
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>]
|
|
[<a href="index.html">index</a>]
|
|
[<a href="mailto:jschauma@netmeister.org">jschauma@netmeister.org</a>]
|
|
[<a href="https://mstdn.social/@jschauma">@jschauma</a>]
|
|
[<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
|
|
"#<rr>" 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: <8-bit prefix> <128-bit hex IPv6 address> <prefix-name>"
|
|
"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: <16-bit subtype> <domain-name>"
|
|
$ </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: <8-bit precedence> <1-bit discover> <7-bit type> <domain-name>"
|
|
"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: <address>"
|
|
"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: <RFC6759 shortened names>"
|
|
$ </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: <flags> <tag> <value> -- flag is commonly 1;
|
|
tag one of 'issue', 'issuewild', 'iodef' (others reserved or not yet defined);
|
|
value is a '<character-string>'"
|
|
</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: <16-bit flags> <8-bit protocol> <8-bit algorithm> <base64-encoded pubkey>"
|
|
$ </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: <16-bit key tag> <8-bit algorithm> <8-bit digest type>
|
|
<digest of owner name concatenated with the DNSKEY RDATA>"
|
|
"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: <16-bit type> <16-bit key tag> <8-bit algorithm> <base64-encoded certificate or CRL>"
|
|
"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: <domain-name>"
|
|
$ 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: <32-bit SOA serial> <16-bit flags> <16-bit type bit map>"
|
|
$ </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(<identifier> <FQDN>)"
|
|
"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: <16-bit key tag> <8-bit algorithm> <8-bit digest type>
|
|
<digest of owner name concatenated with the DNSKEY RDATA>"
|
|
"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: <domain-name>"
|
|
"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: <16-bit flags> <8-bit protocol> <8-bit algorithm> <base64-encoded pubkey>"
|
|
$ </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: <32-bit doa-enterprise> <32-bit doa-type> <16-bit doa-location> <doa-media-type> <doa-data>"
|
|
$ </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: <16-bit key tag> <8-bit algorithm> <8-bit digest type>
|
|
<digest of owner name concatenated with the DNSKEY RDATA>"
|
|
$ </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: <octets>"
|
|
"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: <longitude> <latitude> <altitude>"
|
|
"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 <character-string>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: <pk-algorithm> <base16-encoded-hit> <base64-encoded-public-key>
|
|
<rendezvous-server[1]> ... <rendezvous-server[n]>"
|
|
$ </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: <16-bit SvcFieldPriority> <SvcDomainName> <SvcFieldValue>"
|
|
"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: <8-bit precedence> <8-bit gateway type> <8-bit algorithm> <40-bit gateway> <base64-encoded public-key>"
|
|
"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: <ISDN-address> <optional sa>"
|
|
"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: <16-bit flags> <8-bit protocol> <8-bit algorithm> <base64-encoded public key>"
|
|
"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: <16-bit preference> <domain-name>"
|
|
"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: <16-bit preference> <32-bit locator32>"
|
|
$ </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: <16-bit preference> <64-bit locator64>"
|
|
"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: <16-bit preference> <domain-name>"
|
|
"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: <domain-name>"
|
|
$ </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: <mailbox>"
|
|
"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: <responsible mailbox> <error mailbox>"
|
|
"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: <domain-name>"
|
|
"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: <16-bit preference> <domain-name>"
|
|
$ </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: <16-bit order> <16-bit preference> <character-string flags> <characer-string services>
|
|
<character-string regex> <domain-name>"
|
|
$ </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: <16-bit preference> <64-bit nodeid>"
|
|
$ </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: <octets>"
|
|
"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: <text>"
|
|
$ </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: <domain-name>"
|
|
"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: <nsap>"
|
|
$ </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: <domain-name>"
|
|
"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: <domain-name>gt; <16-bit type bit map>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: <8-bit hash algorithm> <8-bit flags> <16-bits iterations> <8-bit salt length> <24-bit salt>
|
|
<8-bit hash-length> <24-bit next hashed owner name> <16-bit type bit map>"
|
|
$ </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: <8-bit hash algorithm> <8-bit flags> <16-bit iterations> <8-bit salt length> <24-bit salt>"
|
|
$ </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: <domain-name> <16-bit type bit map>"
|
|
$ </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: <domain-name>"
|
|
"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: <16-bit preference> <domain-name> <x400-in-domain-syntax>"
|
|
$ </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: <mbox-dname> <txt-dname>"
|
|
"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: <16-bit type covered> <8-bit algorithm> <8-bit labels> <32-bit TTL> \
|
|
<32-bit signature expiration> <32-bit signature inception> <16-bit key tag> \
|
|
<40-bit signers name> <base64-encoded signature>"
|
|
$ </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: <16-bit preference> <intermediate-host>"
|
|
"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: <coding> <subcoding> <base64 data>"
|
|
$ </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: <8-bit cert usage> <8-bit selector> <8-bit matching type>
|
|
<base64-encoded certificate data>"
|
|
$ </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: <domain-name> <domain-name> <32-bit serial> <32-bit refresh interval> \
|
|
<32-bit retry interval> <32-bit expiration interval> <32-bit minimum TTL>"
|
|
$ </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: <spf text>"
|
|
"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: <16-bit priority> <16-bit weight> <16-bit port> <domain-name>"
|
|
"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: <8-bit algorithm> <8-bit fingerprint type> <fingerprint>"
|
|
$ </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: <16-bit SvcFieldPriority> <SvcDomainName> <SvcFieldValue>"
|
|
$ </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: <16-bit key tag> <8-bit algorithm> <8-bit digest type>
|
|
<digest of owner name concatenated with the DNSKEY RDATA>"
|
|
$ </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: <domain-name> <domain-name>"
|
|
"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: <8-bit usage> <8-bit selector> <8-bit matching type> <cert data>"
|
|
"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: <algorithm name> <48-bit time signed> <16-bit fudge> <16-bit MAC size>
|
|
<MAC> <16-bit oid> <16-bit error> <16-bit other size> <other data>"
|
|
"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: <text>"
|
|
"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: <16-bit priority> <16-bit weight> <uri>"
|
|
"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: <32-bit IP address> <16-bit protocol> <8-bit bit map>"
|
|
"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: <PSDN-address>"
|
|
"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: <32-bit serial> <8-bit scheme> <8-bit hash algorithm> <digest>"
|
|
$ </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> </p>
|
|
<hr width="75%">
|
|
<p> </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>
|
|
←[<a href="urls.html">URLs: It's complicated...</a>]
|
|
<div style="float: right;">[<a href="ddg-tor.html">DuckDuckGo Onion Search for Firefox</a>] →</div>
|
|
</small>
|
|
<hr class="noshade" style="width:100%;">
|
|
<small>
|
|
[<a href="../index.html">homepage</a>]
|
|
[<a href="index.html">blog</a>]
|
|
[<a href="mailto:jschauma@netmeister.org">jschauma@netmeister.org</a>]
|
|
[<a href="https://mstdn.social/@jschauma/">@jschauma</a>]
|
|
[<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>
|