ishenwei/nexus

Fork 0

Files

admin af7633f9dc SRE weekly 所有文章

2026-09-12 17:23:01 +08:00

71 KiB

Raw Blame History

(All) DNS Resource Records

期号: SRE Weekly Issue #281（2021-08-01）
作者: Jan Schaumann
链接: https://www.netmeister.org/blog/dns-rrs.html

简介

A list with descriptions of all DNS record types, even the obscure ones. Tag yourself, I’m HIP.

正文

[

| July 15th, 2021 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 /etc/hosts , but yeah. Now of course you all know the common DNS Resource Records (RRs), right? You got your A ,AAAA ,CNAME ,NS ,MX ,PTR , and... oh, right,TXT records. And sure, you're probably aware that there are more. But just how many more? All in all, IANA has almost 100 record types assigned ! A small number of them arereserved , some areexperimental , 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: I created a DNS zone dns.netmeister.org. that contains RRs for every RR type, each one named after the type and each one holding two additionalTXT records, one noting the RR format, and one the purpose and originating RFC(s). This zone isavailable on GitHub , and is served live frompanix.netmeister.org : $ 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) ) $ (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 dig ordelv``@panix.netmeister.org directly.) Here, let's go through the RRs, shall we? (You can jump to any individual RR on this page via its respective "#" anchor.) RRs from A toZONEMD |

Okay, no secrets or surprises here. Just an IPv4 address. But let's use this example to illustrate the convenience of this zone:

$ 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" $

RFCs: 882, 1035

Also no surprises -- your regular old IPv6 address in colon-separated hextets:

$ 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)" $

RFCs: 1884, 4291

But... wait a second. Before there were AAAA records, there were...

... A6 records. This early version included a prefix field and allowed you to recursively construct IPv6 addresses from multiple A6 records, or to simply provide a final address. The following examples illustrate this:

$ 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> " "Early IPv6 record, obsoleted by AAAA. RFC2874 (2000)" $

RFCs: 2874

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 Andrew File System database server in an AFS cell:

$ 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> " $

RFCs: 1183

Note: the responses panix.netmeister.org 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.

Okay, now we're deep in wonky territory, where we are offering records to publish Automatic Multicast Tunneling (AMT) relays for source-specific multicast channels, aka DNS Reverse IP AMT Discovery (DRIAD):

$ 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> " "Automatic Multicast Tunneling Relay. RFC8777 (2020)" $

RFCs: 8777

Here we see for the first time a common pattern in DNS service discovery: the encoding of a preference or weight, as well as conditional RDATA based on other selectors. We'll see many more examples of this below.

I know, I know, I'm cheating. ANY isn't really an RR type, it's a QTYPE. When asked for ANY (QTYPE=*), the DNS server will return all of the records for the given name:

$ 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)"
$

This shows the various records found in the zone for any.dns.netmeister.org., which include the DNSSEC relevant records that we'll see in more detail below.

RFCs: 882

(Some resolvers may choose not to answer QTYPE=* (see also: HINFO); some simply won't have any data in their cache. Try to ask @panix.netmeister.org directly.)

Oh, and note that of course the QTYPE=* is different from the wildcard * in a zone. That is used to return results for a query for a name that's not in the zone:

$ 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."
$

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:

$ 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"
$

Here, the afi is the Address Family Indicator, defining IPv4 or IPv6 prefixes.

RFCs: 3123

RFCs? Who needs RFCs? Why not just go with a paper/proposal from the ATM Forum that nowadays is only available from (the admittedly wonderful) Internet Archive?

The ATMA record operates within the Asynchronous Transfer Mode (ATM) Name System (ANS) (acronyms of acronyms!), allowing you to map a name to an ATM address:

$ dig +short atma atma.dns.netmeister.org. 39246f000e7c9c03120001000100001234567800 $ dig +short txt atma.dns.netmeister.org. "Format:

" "ATM End System Address. ATM Forum Publication (2000)" $

RFCs: nope

The AVC resource record was requested by Cisco to map IP Flow Information Export (IPFIX) names into the DNS:

$ 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: " $

RFCs: 6759

See also: EID

This record was initially requested to be named ZS 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 SOA record.)

$ 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: " $

Hey, NS 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 nowadays distribute across different TLDs for global redundancy.

$ dig +short ns ns.dns.netmeister.org. panix.netmeister.org. $ dig +short txt ns.dns.netmeister.org. "Format: " "Naming Authority Pointer; delegates authority of the given domain to the given name server. RFC883 (1983); RFC1035 (1987)" $

Here we have Network Service Access Point addresses used in the Connectionless-mode Network Service (CLNS) datagram services mapped into the DNS, why not:

$ dig +short nsap nsap.dns.netmeister.org. 0x47000580005a0000000001e133ffffff00016100 $ dig +short txt nsap.dns.netmeister.org. "Network Service Access Point. RFC1706 (1994)" "Format: " $

RFCs: 1706

Reversing NSAP addresses is done via the NSAP-PTR record, which would normally be found in the respective nsap.int domain:

$ dig +short nsap-ptr nsap-ptr.dns.netmeister.org. nsap.dns.netmeister.org. $ dig +short txt nsap-ptr.dns.netmeister.org. "Format: " "NSAP to name mapping. Usually found in the 'nsap.int' domain. RFC1706 (1994)" $

And we're back to DNSSEC. In DNSSEC, the NSEC record indicates the next secure 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.

$ 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: gt; <16-bit type bit map>gt;" $

RFCs: 4304

Now since iterating over an entire zone may not be what you want to let everybody do, we then came up with...

...the next secure record, version 3. This record doesn't leak the names, but uses the next hashed owner name, which still lets you prove non-existence:

$ 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>"
$

RFCs: 5155

Note that you need the records are generated by the server, and you thus need to query a resolver that supports DNSSEC (+dnssec).

The NSEC3 records are calculated using specific paramters which are included in the NSEC3PARAM record. They include the hash algorithm, iterations, and a salt:

$ 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>" $

Note: the NSEC3PARAM value is actually included in the NSEC3 response and can then be used to confirm the correct next name using, e.g., this useful tool:

$ dig +dnssec +nocmd +nocomments +noquestion +nostats nsec3 nsec3.dns.netmeister.org. | \
        grep "IN NSEC3"
2RM96JUOJE08UCPDC2LVLUDUEFAPNLHE.nsec3.dns.netmeister.org. 3600 IN NSEC3                \

1 0 15 1C9B2F7BBFB115E4
08R5BALN9R7QHEACJTNHAKHFDMD89ULQ
NS SOA TXT RRSIG DNSKEY NSEC3PARAM CDS CDNSKEY $ python nsec3hash.py 1C9B2F7BBFB115E4 1 15 nsec3.dns.netmeister.org. 2RM96JUOJE08UCPDC2LVLUDUEFAPNLHE $ dig +short txt next.nsec3.dns.netmeister.org. "A text record so that we can show the use of NSEC3." $ python nsec3hash.py 1C9B2F7BBFB115E4 1 15 next.nsec3.dns.netmeister.org. 08R5BALN9R7QHEACJTNHAKHFDMD89ULQ $ dig +dnssec +nocmd +nocomments +noquestion +nostats nsec3 next.nsec3.dns.netmeister.org. |
grep "IN NSEC3" 08R5BALN9R7QHEACJTNHAKHFDMD89ULQ.nsec3.dns.netmeister.org. 3600 IN NSEC3
1 0 15 1C9B2F7BBFB115E4
2RM96JUOJE08UCPDC2LVLUDUEFAPNLHE
TXT RRSIG In other words, we have shown that there are no other records in the zone besides the apex records and the "next" text record, but we could not have discovered "next" without knowing it!

This one's sneaky: RFC1035 defines it as an "experimental" RR allowing any data whatsoever, "so long as it is 65535 octets or less." However, it also specifies that NULL records are not allowed in master files, so, e.g., bind will refuse to load a zone with a NULL record.

However, you can specify it in the zone file using the generic opaque record format:

null IN TYPE10 # 7 61766f6361646f $ dig +short null.dns.netmeister.org null # 7 61766F6361646F $ dig +short null.dns.netmeister.org txt "Format: " "Placeholder records in some experimental extensions. RFC883 (1983)" $

RFCs: 883, 1035

When DNSSEC was first drafted, the problem of how to assert authoritatively the non-existence of a record was initially solved using the NXT record. This is no longer automatically calculated (since we have NSEC and NSEC3), so I've stubbed one out here:

$ 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: <16-bit type bit map>" $

RFCs: 2065, 3755

We already saw one way to store a PGP key in the DNS by using the CERT record above. But there are quite a few ways, and here we use the OPENPGP record, in context of DANE:

$ 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"
$

RFCs: 7929

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 email addresses can be all sorts of funky. So instead of the rather convenient jschauma.netmeister.org. label, I have to use:

$ 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 )
$

You can use this site to generate the right OPENPGPKEY entry from your key.

Okay, back in save waters. PTR 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 in-addr.arpa / ip6.arpa domains, but you can add it in any zone (even if that may not be useful):

$ dig +short ptr ptr.dns.netmeister.org. ptr.dns.netmeister.org. $ dig +short txt ptr.dns.netmeister.org. "Format: " "Domain Name Pointer; commonly found in the in-addr.arpa and ip6.arpa domains and used in reverse lookups. RFC1035 (1987)" $

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 PTR 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:

$ 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. $

Aaaaaaand we're back to stashing weird things into the DNS. This time mapping information needed by Mime Internet X.400 Enhanced Relay (MIXER) conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa.

$ 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> " $

RFCs: 2163

The RP record assigns a responsible person 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.

The SOA record includes a responsible person for the zone, but that person may not be responsible for each individual node, so the RP 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 TXT record:

$ dig +short rp rp.dns.netmeister.org. jschauma.netmeister.org. contact.netmeister.org. $ dig +short txt rp.dns.netmeister.org. "Format: " "Responsible Person. RFC1183 (1990)" $ dig +short txt contact.netmeister.org. "Email preferred, but you can also find me at https://mstdn.social/@jschauma." $

The DNSSEC Resource Record Digital Signature RRSIG record contains the digital signatures associated with the given name and are generated automatically by the (DNSSEC enabled) nameserver:

$ 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>"
$

Here we again see the NSEC record, which is signed just like the TXT record. The records are signed with the domain's private key matching the DNSKEY record.

Note that a given RRSIG covers all records of a given type, which is why we see only one RRSIG in the above for two TXT records.

The Route Through (RT) record provides a preference and intermediate host to be used to route or relay through when talking to the owner:

$ dig +short rt rt.dns.netmeister.org 10 panix.netmeister.org. $ dig +short txt rt.dns.netmeister.org "Format: <16-bit preference> " "Route Through RR. RFC1183 (1990)" $

Another signature record! This was replaced in DNSSEC by the RRSIG records, but may still be used in other context. These records are generated by the server in combination with the KEY, TKEY / TSIG records.

bind(8) only uses SIG records when using nsupdate(8).

RFCs: 2535, 2931, 4034

Ah, finally a record that speaks the truth! The SINK record was intended to provide a general purpos "kitchen sink" record to obviate the need to stuff weird things into, say, TXT records. It never took off, though, and bind even implements it with an undocumented additional field. But this is what it'd look like:

$ 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: " $

This one's kind of like OPENPGPDATA, in that you want to make an S/MIME certificate to an identity, and so normally you'd also use the same mechanism to map a user's email address.

$ 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>"
$

RFCs: 8162

Every zone has a Start of Authority record, which includes the responsible name server, responsible person, and information about the zone:

$ 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>"
$

The Sender Policy Framework started using TXT records to define a policy for a domain, but of course stashing even more information into TXT records is silly, so a new RR was created: SPF. Nobody adopted this record, and everybody still uses TXT records, however.

$ dig +short spf spf.dns.netmeister.org "v=spf1 a mx -all" $ dig +short txt spf.dns.netmeister.org "Format: " "Sender Policy Framework alternative to TXT record. RFC4408 (2006)" $

RFCs: 4408

The SRV record is used to help clients find the correct service endpoint for the given name. It is most commonly used via _port._protocol records, such as, e.g., _kerberos._udp or _ldap._tcp:

$ 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> " "Service location records. Commonly something like _port._protocol. RFC2052 (1996); RFC2782 (2000)" $

RFCs: 2782

71 KiB Raw Blame History Unescape Escape

(All) DNS Resource Records

简介

正文

71 KiB

Raw Blame History