Resource Record

Ein Resource Record (RR) ist die grundlegende Informationseinheit im Domain Name System (DNS). Er tritt in ASCII-Darstellung in Zonendateien oder in komprimierter Form in DNS-Transport-Paketen oder DNS-Caches auf.

RR-Format in Zonendateien

Das hier dargestellte Format bezieht sich auf die ASCII-Darstellung, die in Zonendateien verwendet wird. In Caches oder auf dem Transportweg wird ein inhaltsgleiches, aber komprimiertes Binärformat verwendet. RR-Typen werden im Binärformat durch 16-Bit-Zahlenwerte von 0 bis 65535 ausgedrückt. Ähnliches gilt für Class und TTL.

ASCII-Format: [<name>] [<ttl>] [<class>] <type> <rdata>

  • <name> Der Domainname des Objekts, zu dem der Resource Record gehört (optional)
  • <ttl> time to live (in Sekunden). Gültigkeit des Resource Records (optional)
  • <class> Protokollgruppe, zu der der Resource Record gehört (optional)
  • <type> beschreibt den Typ des Resource Records
  • <rdata> (resource data) Daten, welche den Resource Record näher beschreiben (zum Beispiel eine IP-Adresse für einen A-RR, oder einen Hostnamen für einen NS-RR)

Bei einigen Typen ist rdata in mehrere Subfelder unterteilt, beispielsweise beim MX Resource Record. Die optionalen Komponenten können in der Zonendatei weggelassen werden. Es wird dann vom Nameserver automatisch der zuletzt aufgetretene Wert dieser Komponente eingesetzt. Auf dem Transportweg werden alle Komponenten übertragen, auch die optionalen. Im Binärformat wird vor rdata eine weitere Komponente namens rdlength übertragen, die die Länge von rdata in Bytes angibt.

Beispiele

 test.example.com.        3600  IN  A       172.30.0.7
                                IN  TXT     "für DNS-Test"
 abc                      1800  IN  MX  10  test.example.com.
 dns1                               NS      nameserver.example.org.
 7.0.30.172.in-addr.arpa.           PTR     test.example.com.

Spezielle Arten von Resource Records

Pseudo-Record

Es gibt RR-Typen, die nie in Zonendateien eingetragen werden, sondern lediglich auf dem Transportweg zwischen Nameserver und Client zum Einsatz kommen, beispielsweise der OPT Resource Record. Diese werden als Pseudo-Resource-Records bezeichnet.

Wildcard-Record

Wenn ein Domainname mit *. beginnt (beispielsweise *.example.net), handelt es sich dabei um einen Wildcard-Record bzw. Wildcard-Domainnamen. Ein solcher hat eine besondere Bedeutung für den zuständigen Nameserver: der Platzhalter greift für beliebige Label in dem angefragten Domainnamen.[1] Der Nameserver erzeugt für die Antwort einen Resource Record, in dem statt des Sternchen-Platzhalters der angefragte Domainname enthalten ist und der so im Cache zwischengespeichert werden kann. Für den Client ist bei einer unsignierten DNS-Antwort nicht auf Anhieb ersichtlich, dass er eine Wildcard-Antwort erhalten hat.

Wildcards-Records können mit bestehenden Resource Records koexistieren. Die Wildcard greift nur dann, wenn kein anderer Resource Record vorhanden ist, der auf die Anfrage passt.

DNSSEC unterstützt Wildcard-Records. Damit eine Wildcard-Antwort nicht zum Zeitpunkt der Antwort signiert werden muss, sondern dies vorab geschehen kann (Offline-Signierung), enthält das DNSSEC-Protokoll eine Logik zur Validierung von Wildcard-Domainnamen.[2] Für diesen Zweck enthält der RRSIG Resource Record eine Zählerkomponente, die die Anzahl der Namensbestandteile wiedergibt, wobei der Sternchen-Platzhalter nicht mitgezählt wird. Dadurch kann der Client in einer signierten DNSSEC-Antwort ermitteln, dass es sich um einen Wildcard-Domainnamen handelt.

Negative DNSSEC-Antworten erfordern eine zusätzliche Komplexität, um nachzuweisen, dass nicht nur der angefragte Domainname nicht existiert, sondern dass auch kein Wildcard-Domainname existiert. Daher beinhalten negative DNSSEC-Antworten zwei NSEC Resource Records oder drei NSEC3 Resource Records.

Die zulässigen Klassen

In der Praxis wird nahezu ausnahmslos IN verwendet. Die anderen Klassen haben nur noch historische Bedeutung. Von BIND-Servern wird gelegentlich CH gebraucht, um die Versionsnummer eines Nameservers zu publizieren.

  • IN Internet
  • CH Chaosnet (selten verwendet)
  • HS Hesiod (selten verwendet)
  • CS CSNET (wird nicht mehr verwendet)

RR-Typen

Die folgenden Typen von Resource Records sind bei der Internet Assigned Numbers Authority registriert.[3]

TypWert (dezimal)Definierendes RFCBeschreibungFunktion
A1RFC 1035[4]Address recordGibt die 32 Bit lange IPv4-Adresse eines Hosts zurück. Am häufigsten für die Zuordnung eines Hostnamens zu einer IP-Adresse des Hosts gebräuchlich, wird aber auch für DNSBLs, Speichern von Subnetzmasken und derlei verwendet.
AAAA28RFC 3596[5]IPv6 Address recordGibt die 128 Bit lange IPv6-Adresse eines Hosts zurück. Am häufigsten für die Zuordnung eines Hostnamens zu einer IP-Adresse des Hosts gebräuchlich.
AFSDB18RFC 1183[6]AFS Database RecordResource Record für den Ort von Cell Database Server des Andrew File Systems. Dieser RR wird üblicherweise von AFS Clients benutzt, um AFS Cells außerhalb ihrer lokalen Domain zu benachrichtigen. Ein Subtyp dieses RR wird von dem mittlerweile veralteten DCE/DFS-Dateisystems verwendet.
APL42RFC 3123[7]Address Prefix ListAuflisten von Adressbereichen, z. B. im CIDR-Format, für verschiedene Adressfamilien. Versuchsweise eingeführt.
ATMA34ATM Address
A638Resource Record des Verfahrens A6 zur teilweisen Adressauflösung unter IPv6. Inzwischen veraltet.
CAA257RFC 6844[8]Certification Authority AuthorizationCertification Authority (CA) Blockierung, die zulässige CAs für einen Host bzw. eine Domain beschränken
CDNSKEY60RFC 7344[9]Child DNSKEYKindkopie eines DNSKEY-Records, um sie an sein Eltern-Record zu übertragen
CDS59RFC 7344[9]Child DSKindkopie eines DS-Records, um sie an sein Eltern-Record zu übertragen
CERT37RFC 4398[10]Certificate recordResource Record für das Speichern von Zertifikaten wie PKIX, SPKI und PGP
CNAME5RFC 1035[11]Canonical Name recordKanonischer Name für einen Host (die Domain mit diesem RR ist ein Alias)
CSYNC62RFC 7477[12]Child-To-Parent SynchronizationSignalisierungsmechanismus, welche Records in die Eltern-Zone kopiert werden sollen
DHCID49RFC 4701[13]DHCP IdentifierIn Verbindung mit der FQDN-Option für DHCP benutzt.
DLV32769RFC 4431[14]DNSSEC Lookaside Validation recordBenutzt zur Veröffentlichung von DNSSEC Trust Anchors außerhalb der DNS Delegationskette (delegation chain). Benutzt dasselbe Format wie der DS-Record. RFC 5074[15] beschreibt die Art der Benutzung dieser Records.
DNAME39RFC 2672[16]Delegation NameAlias für einen Namen und alle seine Subnamen. Ähnlich wie CNAME, aber anstatt eines Aliases nur für einen übereinstimmenden Namen, ist DNAME für komplette Domains zuständig. Ähnlich wie CNAME wird die Suche im DNS durch ständiges Probieren, den neuen Namen zu finden, weitergeführt.
DNSKEY48RFC 4034[2]DNS Key recordEnthält einen dem Namen zugeordneten Public-Key und löste ab 2004 bei DNSSEC den Typ KEY ab.
DS43RFC 4034[2]Delegation SignerDient der Identifizierung und Verkettung DNSSEC-signierter Zonen
EID31Endpoint Identifier
GPOS27Geographical PositionGeographische Position, veraltet.
HIP55RFC 5205[17]Host Identity ProtocolMethode zur Trennung der Endpunktkennzeichnung und Ortungsfunktionen von IP-Adressen.
HINFO13RFC 1035[4]Host InformationInformationen des Hosts wie Prozessortyp und Betriebssystem
HTTPS65RFC 9460[18]HTTPS BindingVerbesserte Performance für den direkten Zugriff auf HTTPS-Ressourcen
IPSECKEY45RFC 4025[19]IPsec KeySchlüsseleintrag, der mit IPsec verwendet werden kann
ISDN20ISDNISDN-Nummer, wird nur selten verwendet.
KEY25RFC 2535[20] und RFC 2930[21][22]Key recordEnthält einen dem Namen zugeordneten Public-Key und wird seit 2004 nicht mehr von DNSSEC verwendet.

Wurde nur für SIG(0) (RFC 2931) und TKEY (RFC 2930[21]) verwendet.[23] RFC 3445 schloss die Nutzung für Anwendungsschlüssel aus und beschränkte ihre Nutzung auf DNSSEC.[24] RFC 3755 kennzeichnet DNSKEY als den Ersatz innerhalb von DNSSEC.[25] RFC 4025 benennt IPSECKEY als Ersatz bei der Nutzung von IPsec.[26]

KX36RFC 2230[27]Key eXchanger recordWird in einigen kryptografischen Systemen (DNSSEC nicht eingeschlossen) verwendet, um einen Agenten zum Schlüsselmanagement für den zugehörigen Domainnamen zu bestimmen. Dieses hat nichts mit DNS-Sicherheit zu tun. Dieser Eintrag ist lediglich eine Informationsstatusangabe, anstatt von den IETF-Standards verfolgt zu werden. Er hatte immer eine eingeschränkte Entwicklung, ist aber immer noch in Benutzung.
LOC29RFC 1876[28]Location recordFührt einen geografischen Ort (Lokation) auf, der mit einem Domainnamen in Verbindung gebracht werden kann.
MB7Mailbox domain nameSpezifiziert einen Domainnamen in Verbindung mit einer Mailbox. Experimentell
MD3Mail DestinationNicht mehr in Gebrauch. Heutzutage wird MX verwendet.
MF4Mail ForwarderNicht mehr in Gebrauch. Heutzutage wird MX verwendet.
MG8Mail Group memberExperimentell
MINFO14Mailbox oder mail list information
MR9Mail Rename domain nameExperimentell
MX15RFC 1035[4] und RFC 7505[29]Mail eXchange recordOrdnet den für diese Domain zuständigen Mailserver einer Liste von Mail Transfer Agents zu.
NAPTR35RFC 3403[30]Naming Authority PointerEine Erweiterung des A Resource Record, die die Schreibung von Domainnamen mit regulären Ausdrücken erlaubt. Diese kann dann in URIs, weiteren Domainnamen zum Nachschlagen etc. benutzt werden.
NINFO56NINFO
NS2RFC 1035[4]Name Server recordHostname eines autoritativen Nameservers. Überträgt eine DNS Zone, um die vorgegebenen Nameserver zu nutzen.
NSAP22RFC 1706[31]Network Service Access Point
NSAP-PTR23RFC 1706[31]Network Service Access Point PTR
NSEC47RFC 4034[2]Next-Secure recordVerkettet DNS-Einträge in DNSSEC-signierten Zonen und wird für den Nachweis verwendet, dass ein Name nicht existiert. Benutzt dasselbe Format wie der 2004 abgelöste Typ NXT.
NIMLOC32Nimrod Locator
NSEC350RFC 5155[32]NSEC record version 3 or NSEC hashedAlternative zum NSEC RR ohne Zone Enumeration Problem (seit 2008). Ermöglicht den Nachweis, dass ein Name fehlt, ohne die Überschreitung einer Zone zuzulassen.
NSEC3PARAM51RFC 5155[32]NSEC3 ParametersParameter Eintrag für NSEC3.
NULL10Null Resource RecordExperimentell
NXT30Next Resource RecordVeraltet. Wurde durch den praktisch identischen NSEC Resource Record abgelöst.
OPENPGPKEY61RFC 7929[33]OpenPGP KeyVerknüpfung von OpenPGP-Schlüsseln mit Domainnamen
OPT41RFC 2671[34]Option Resource RecordPseudo RR[35], markiert ein Paket als Extended-DNS-Paket (EDNS), stellt 16 zusätzliche Flags bereit und erweitert Response-Codes um acht Bytes (damit können in einem Paket insgesamt drei Response-Codes untergebracht werden).
PTR12RFC 1035[4]Pointer recordDomain Name Pointer zu einem kanonischen Namen für das Reverse Mapping, um IP-Adressen Namen zuzuweisen. Im Gegensatz zu CNAME wird die DNS-Verarbeitung beendet und lediglich der Name zurückgegeben. Die häufigste allgemeine Verwendung von PTR ist die Implementierung von Reverse Mappings, aber es wird auch für DNS-SD eingesetzt.
RKEY57RKEY
RP17RFC 1183[6]Responsible PersonInformation über die verantwortliche(n) Person(en) für die Domain. Üblicherweise eine E-Mail-Adresse, wobei das '@' durch ein '.' ersetzt wurde.
RT21RFC 1183[6]Route Through
RRSIG46RFC 4034[2]DNSSEC SignatureEnthält eine digitale Unterschrift für den Eintrag. Wird seit 2004 von DNSSEC (=DNS Security) verwendet und ersetzt das gleichformatige SIG.
SIG24RFC 2535[36]SignatureEnthält eine digitale Unterschrift, die in SIG(0) (RFC 2931[37]) und TKEY (RFC 2930[21]) benutzt wird.[25] SIG ist veraltet und wurde bis 2004 von DNSSEC (=DNS Security) verwendet. RFC 2535 nennt RRSIG als Ersatz für SIG zur Benutzung in DNSSEC.[25]
SINK40SINK
SMIMEA53RFC 8162[38]S/MIME cert associationVerknüpfung von S/MIME-Zertifikaten mit Domainnamen
SOA6RFC 1035[4] und RFC 2308[39]Start Of [a zone of] AuthorityFührt verbindliche Informationen über eine DNS-Zone auf, einschließlich des Primary Nameservers, der E-Mail-Adresse des Administrators der Domäne, der Seriennummer der Domäne und Angaben über mehrere Zeitgeber in Bezug auf die Aktualisierung der Zone.
SPF99Sender Policy Framework (früher Sender Permitted From)Der Eintrag SPF soll das Fälschen der Absenderadresse einer E-Mail verhindern. Es entstand als Verfahren zur Abwehr von Spam. Der Record-Typ ist veraltet und wurde durch TXT ersetzt.
SRV33RFC 2782[40]Service locatorVerallgemeinernder Eintrag zu angebotenen Diensten (Services). Wird von neueren Protokollen benutzt anstatt protokollspezifische Einträge zu erstellen, wie dies bei MX der Fall ist.
SSHFP44RFC 4255[41]SSH public key FingerprintVeröffentlichung der Fingerprints von SSH-Schlüsseln in das DNS, um die Überprüfung der Echtheit eines Hosts zu unterstützen. RFC 6594[42] definiert die ECC SSH-Schlüssel und die SHA-256 Hashes. Details sind bei der IANA SSHFP RR parameters registry zu finden.[43]
SVCB64Service Binding type for use with HTTP
TA32768—DNSSEC Trust AuthoritiesTeil eines Entwicklungsvorschlages für DNSSEC ohne signierten DNS Root. Zu Details siehe die IANA[44] und die Weiler Spezifikationen.[45] TA benutzt dasselbe Format wie der DS Resource Record.
TKEY249RFC 2930[21]Secret KeyEine Methode, um Artikel für Schlüssel zur Verfügung zu stellen, die mit TSIG benutzt werden können und das dort innerhalb des öffentlichen Schlüssels mit dem begleitenden KEY Resource Record verschlüsselt ist.[46]
TLSA52RFC 6698[47]TLSA certificate associationEintrag nötig für das Protokoll DNS-based Authentication of Named Entities (DANE), das dazu dient, den Datenverkehr abzusichern. RFC 6698 definiert die Nutzung des TLSA Resource Records (RR) als Verbindung eines TLS Serverzertifikates oder eines öffentlichen Schlüssels mit dem Domainnamen, wo der Eintrag gefunden wird. Die Verbindung erstellt deshalb eine „TLSA Zertifikatsverbindung“.[48]
TSIG250RFC 2845[49]Transaction SignatureKann, in ähnlicher Weise zu DNSSEC, für die Authentifikation von dynamischen Aktualisierungen in der Art verwendet werden, als ob diese von einem freigegebenen Client kommt, oder Antworten zu authentifizieren als ob diese von einem freigegebenen rekursiven Nameserver kommen.
TXT16RFC 1035[50]Text recordUrsprünglich erdacht für frei definierbaren und von Menschen lesbaren Text in DNS Einträgen. Seit den frühen 1990ern enthält dieser Eintrag häufig jedoch u. a. auch maschinenlesbare Daten wie in RFC 1464[51] spezifiziert, SPF, DKIM, DMARC, DNS-SD und Google-Site Verification.
URI256RFC 7553[52]Uniform Resource IdentifierWird benutzt, um Abbildungen von Hostnamen auf URIs zu veröffentlichen.
WKS11RFC 974[53]Well Known ServiceWird in der Mailweiterleitung benutzt und speichert Informationen über die Netzwerkdienste (wie z. B. SMTP), die ein vorgegebener Domainname unterstützt.[53]
X2519RFC 1356[54]X.25-AdresseSpezifiziert die Einkapselung von IP und anderen Netzwerkschichtprotokollen über X.25-Netzwerke. Wird nur selten verwendet.
ZONEMD63RFC 8976[55]Message Digest Over Zone DataKryptographischer Hashwert einer Zone

Einzelnachweise

  1. ↑ RFC4592 – The Role of Wildcards in the Domain Name System. Juli 2006 (englisch).
  2. ↑ a b c d e RFC4034 – Resource Records for the DNS Security Extensions. März 2005 (englisch).
  3. ↑ Domain Name System (DNS) Parameters. IANA, abgerufen am 22. März 2023.
  4. ↑ a b c d e f Paul Mockapetris: RFC1035 – Domain Names – Implementation and Specification. November 1987, Abschnitt 3.4.1 (englisch).
  5. ↑ RFC3596 – DNS Extensions to Support IP Version 6. Oktober 2003, Abschnitt 2 (englisch).
  6. ↑ a b c RFC1183 – New DNS RR Definitions. Oktober 1990 (englisch).
  7. ↑ RFC3123 – A DNS RR Type for Lists of Address Prefixes (APL RR). Juni 2001 (englisch).
  8. ↑ RFC6844 – DNS Certification Authority Authorization (CAA) Resource Record. Januar 2013 (englisch).
  9. ↑ a b RFC7344 – Automating DNSSEC Delegation Trust Maintenance. September 2014 (englisch).
  10. ↑ RFC4398 – Storing Certificates in the Domain Name System (DNS). März 2006 (englisch).
  11. ↑ Paul Mockapetris: RFC1035 – Domain Names – Implementation and Specification. November 1987, Abschnitt 3.3.1 (englisch).
  12. ↑ RFC7477 – Child-to-Parent Synchronization in DNS. März 2015 (englisch).
  13. ↑ RFC4701 – A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR). Oktober 2006 (englisch).
  14. ↑ RFC4431 – The DNSSEC Lookaside Validation (DLV) DNS Resource Record. Februar 2006 (englisch).
  15. ↑ RFC5074 – DNSSEC Lookaside Validation (DLV). November 2007 (englisch).
  16. ↑ RFC2672 – Non-Terminal DNS Name Redirection. August 1999 (englisch).
  17. ↑ RFC5205 – Host Identity Protocol (HIP) Domain Name System (DNS) Extension. April 2008 (englisch).
  18. ↑ RFC9460 – Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records). November 2023 (englisch).
  19. ↑ RFC4025 – A Method for Storing IPsec Keying Material in DNS. Februar 2005 (englisch).
  20. ↑ RFC2535 – Domain Name System Security Extensions. März 1999, Abschnitt 3 (englisch).
  21. ↑ a b c d RFC2930 – Secret Key Establishment for DNS (TKEY RR). September 2000 (englisch).
  22. ↑ RFC3445 – Limiting the Scope of the KEY Resource Record (RR). Dezember 2002, Abschnitt 1 (englisch). “The KEY RR was defined in [RFC 2930] …”
  23. ↑ RFC2931 – DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. August 2016, Abschnitt 2.4 (englisch). “SIG(0) on the other hand, uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer.”
  24. ↑ RFC3445 – Limiting the Scope of the KEY Resource Record (RR). Dezember 2002, Abschnitt 1 (englisch). “DNSSEC will be the only allowable sub-type for the KEY RR …”
  25. ↑ a b c RFC3755 – Legacy Resolver Compatibility for Delegation Signer (DS). Mai 2004, Abschnitt 3 (englisch). “DNSKEY will be the replacement for KEY, with the mnemonic indicating that these keys are not for application use, per [RFC3445]. RRSIG (Resource Record SIGnature) will replace SIG, and NSEC (Next SECure) will replace NXT. These new types completely replace the old types, except that SIG(0) [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.”
  26. ↑ RFC4025 – A Method for Storing IPsec Keying Material in DNS. Februar 2005 (englisch). “This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445.”
  27. ↑ RFC2230 – Key Exchange Delegation Record for the DNS. November 1997 (englisch).
  28. ↑ RFC1876 – A Means for Expressing Location Information in the Domain Name System. Januar 1996 (englisch).
  29. ↑ RFC7505 – A “Null MX” No Service Resource Record for Domains That Accept No Mail. Juni 2015 (englisch).
  30. ↑ RFC3403 – Dynamic Delegation Discovery System (DDDS) – Part Three: The Domain Name System (DNS) Database. Oktober 2002 (englisch).
  31. ↑ a b RFC1706 – DNS NSAP Resource Records. Oktober 1994 (englisch).
  32. ↑ a b RFC5155 – DNS Security (DNSSEC) Hashed Authenticated Denial of Existence. März 2008 (englisch).
  33. ↑ RFC7929 – DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP. August 2016 (englisch).
  34. ↑ RFC2671 – Extension Mechanisms for DNS (EDNS0). August 1999 (englisch).
  35. ↑ RFC2671 – Extension Mechanisms for DNS (EDNS0). August 1999, Abschnitt 4 (englisch). “An OPT is called a pseudo-RR because it pertains to a particular transport level message and not to any actual DNS data.”
  36. ↑ RFC2535 – Domain Name System Security Extensions. März 1999 (englisch).
  37. ↑ RFC2931 – DNS Request and Transaction Signatures ( SIG(0)s ). September 2000 (englisch).
  38. ↑ RFC8162 – Using Secure DNS to Associate Certificates with Domain Names for S/MIME. Mai 2017 (englisch).
  39. ↑ RFC2308 – Extension Mechanisms for DNS (EDNS0). August 1999 (englisch). The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.
  40. ↑ RFC2782 – A DNS RR for specifying the location of services (DNS SRV). Februar 2000 (englisch).
  41. ↑ RFC4255 – Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints. Januar 2006 (englisch).
  42. ↑ RFC6594 – Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records. April 2012 (englisch).
  43. ↑ SSHFP RR parameters registry. iana.org
  44. ↑ iana.org
  45. ↑ Weiler Spezifikationen. (PDF; 0,3 MB) watson.org
  46. ↑ RFC2930 – Secret Key Establishment for DNS (TKEY RR). September 2000, Abschnitt 6 (englisch). “… the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC2535].”
  47. ↑ P. Hoffman, J. Schlyter: RFC6698 – The DNS-Based Authentication of Named Entities (DANE), Transport Layer Security (TLS) Protocol: TLSA. August 2012 (englisch).
  48. ↑ P. Hoffman, J. Schlyter: RFC6698 – The DNS-Based Authentication of Named Entities (DANE), Transport Layer Security (TLS) Protocol: TLSA. August 2012, Abschnitt 2 (englisch). “The TLSA DNS resource record is used to associate a TLS server certificate or public key with the domain name where the record is found, thus forming a ‘TLSA certificate association’”
  49. ↑ RFC2845 – Secret Key Transaction Authentication for DNS (TSIG). Mai 2000 (englisch).
  50. ↑ Paul Mockapetris: RFC1035 – Domain Names – Implementation and Specification. November 1987, Abschnitt 3.3.14 (englisch).
  51. ↑ RFC1464 – Using the Domain Name System To Store Arbitrary String Attributes. Mai 1993 (englisch).
  52. ↑ RFC7553 – The Uniform Resource Identifier (URI) DNS Resource Record. Juni 2015 (englisch).
  53. ↑ a b Craig Partridge: RFC974 – Mail Routing And The Domain System. Januar 1986 (englisch). “[…] the Well Known Service (WKS) RR, which stores information about network services (such as SMTP) a given domain name supports.”
  54. ↑ RFC1356 – Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode. August 1992 (englisch).
  55. ↑ RFC8976 – Message Digest for DNS Zones. Februar 2021 (englisch).