Domain Name System/Resource Record: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(37 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' kurze Beschreibung
'''Resource Record''' - Eintrag in der [[DNS]]-Datenbank
 
== Beschreibung ==
== Beschreibung ==
Ein '''Resource Record''' ('''RR''') ist die grundlegende Informationseinheit im [[Domain Name System]] (DNS).
; Grundlegende Informationseinheit im [[Domain Name System]] (DNS)
* In [[American Standard Code for Information Interchange|ASCII]]-Darstellung in [[Zonendatei]]en
* In komprimierter Form in DNS-Transport-Paketen oder DNS-[[Cache]]s


Er tritt in [[American Standard Code for Information Interchange|ASCII]]-Darstellung in [[Zonendatei]]en oder in komprimierter Form in DNS-Transport-Paketen oder DNS-[[Cache]]s auf.
; Pseudo-Resource-Records
Werden nur in DNS-Transport-Paketen verwendet


Einige RR-Typen – sogenannte '''Pseudo-Resource-Records''' – werden nur in DNS-Transport-Paketen verwendet.
== 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 eine inhaltsgleiche, aber komprimierte Form verwendet
* RR-Typen werden dort durch Zahlen zwischen 1 und 255 ausgedrückt
* Ähnliches gilt für Class und [[Time-to-live|TTL]].


== Installation ==
; ASCII-Format
== Anwendungen ==
<name> [<ttl>] [<class>] <type> [<rdlength>] <rdata>
=== Fehlerbehebung ===
== Syntax ==
=== Optionen ===
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
== Konfiguration ==
=== Dateien ===
== Sicherheit ==


== Siehe auch ==
{| class="wikitable sortable options"
=== Dokumentation ===
|-
==== RFC ====
! Option !! Beschreibung
==== Man-Pages ====
|-
==== Info-Pages ====
| <name> || Der Domänenname des Objekts, zu dem der Resource Record gehört
=== Links ===
|-
==== Einzelnachweise ====
| <ttl> || [[time to live]] (in Sekunden). Gültigkeit des Resource Records (optional)
<references />
|-
==== Projekt ====
| <class> || Protokollgruppe, zu der der Resource Record gehört (optional)
==== Weblinks ====
|-
| <type> || beschreibt den Typ des Resource Records
|-
| <rdlength> || Länge der Daten, welche den Resource Record näher beschreiben (optional)
|-
| <rdata> || (resource data) Daten, welche den Resource Record näher beschreiben (etwa eine IP-Adresse für einen A-RR, oder einen Hostnamen für einen NS-RR)
|}


== Testfragen ==
; Bei einigen Typen existieren weitere Felder
<div class="toccolours mw-collapsible mw-collapsed">
* die unmittelbar vor <rdata> eingeordnet werden (siehe Beispiel unter MX)
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>


[[Kategorie:Entwurf]]
; Optionale Komponenten können in bestimmten Fällen weggelassen werden
* Es wird dann vom Nameserver automatisch der zuletzt aufgetretene Wert dieser Komponente eingesetzt


= Wikipedia =
== Klassen ==
; In der Praxis wird nahezu ausnahmslos IN verwendet
Andere Klassen haben nur historische Bedeutung
* Von [[BIND]]-Servern wird gelegentlich CH gebraucht, um die Versionsnummer eines Nameservers zu publizieren


== RR-Format in Zonendateien ==
{| class="wikitable sortable options"
Das hier dargestellte Format bezieht sich auf die ASCII-Darstellung, die in Zonendateien verwendet wird. In Caches oder auf dem Transportweg wird eine inhaltsgleiche, aber komprimierte Form verwendet. RR-Typen werden dort durch Zahlen zwischen 1 und 255 ausgedrückt. Ähnliches gilt für Class und [[Time-to-live|TTL]].
|-
 
! Klasse !! Beschreibung
'''ASCII-Format:''' <code> <name> [<ttl>] [<class>] <type> [<rdlength>] <rdata></code>
|-
 
| IN || '''Internet'''
* '''<name>''' Der Domänenname des Objekts, zu dem der Resource Record gehört
|-
* '''<ttl>''' ''[[time to live]]'' (in Sekunden). Gültigkeit des Resource Records (optional)
| CH || [[Chaosnet]] (selten verwendet)
* '''<class>''' Protokollgruppe, zu der der Resource Record gehört (optional)
|-
* '''<type>''' beschreibt den Typ des Resource Records
| HS || [[Hesiod (Netzwerk)|Hesiod]] (selten verwendet)
* '''<rdlength>''' Länge der Daten, welche den Resource Record näher beschreiben (optional)
|-
* '''<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)
| CS || [[CSNET]] (nicht mehr verwendet)
 
|}
Bei einigen Typen existieren weitere Felder, die unmittelbar vor <rdata> eingeordnet werden (siehe Beispiel unten: MX). Die optionalen Komponenten können in bestimmten Fällen weggelassen werden. Es wird dann vom Nameserver automatisch der zuletzt aufgetretene Wert dieser Komponente eingesetzt.
 
== 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
== Typen ==
* '''CH''' [[Chaosnet]] (selten verwendet)
{| class="wikitable sortable options"
* '''HS''' [[Hesiod (Netzwerk)|Hesiod]] (selten verwendet)
* '''CS''' [[CSNET]] (wird nicht mehr verwendet)
 
== Die wichtigsten RR-Typen ==
{| class="wikitable sortable"
|-
|-
! Typ
! Typ
Zeile 87: Zeile 68:
! Funktion
! Funktion
|-
|-
|{{Anker|A}}[[A Resource Record|A]]
|[[A Resource Record|A]]
|1
|1
|[https://datatracker.ietf.org/doc/html/rfc1035#section-3.4.1 RFC 1035]<ref name="RFC1035_page-12">{{Internetquelle |autor=[[Paul Mockapetris]] |url=http://tools.ietf.org/html/rfc1035#page-12 |titel=&#82;&#70;&#67; 1035: Domain Names – Implementation and Specification |hrsg=Network Working Group of the IETF ([[Internet Engineering Task Force]]) |datum=1987-11 |seiten=12 |abruf=2015-02-20 |sprache=en}}</ref>
|[https://datatracker.ietf.org/doc/html/rfc1035#section-3.4.1 RFC 1035]<ref name="RFC1035_page-12">{{Internetquelle |autor=[[Paul Mockapetris]] |url=http://tools.ietf.org/html/rfc1035#page-12 |titel=&#82;&#70;&#67; 1035: Domain Names – Implementation and Specification |hrsg=Network Working Group of the IETF ([[Internet Engineering Task Force]]) |datum=1987-11 |seiten=12 |abruf=2015-02-20 |sprache=en}}</ref>
Zeile 93: Zeile 74:
|Gibt die 32 Bit lange [[IPv4]]-Adresse eines Hosts zurück. Am häufigsten für die Zuordnung eines [[Hostname]]ns zu einer IP-Adresse des Hosts gebräuchlich, wird aber auch für [[DNSBL]]s, speichern von [[Netzmaske|Subnetzmasken]] und dgl. verwendet.
|Gibt die 32 Bit lange [[IPv4]]-Adresse eines Hosts zurück. Am häufigsten für die Zuordnung eines [[Hostname]]ns zu einer IP-Adresse des Hosts gebräuchlich, wird aber auch für [[DNSBL]]s, speichern von [[Netzmaske|Subnetzmasken]] und dgl. verwendet.
|-
|-
|{{Anker|AAAA}}[[AAAA Resource Record|AAAA]]
|[[AAAA Resource Record|AAAA]]
|28
|28
|RFC 3596<ref>{{Internetquelle |url=http://tools.ietf.org/html/rfc3596#section-2 |titel=&#82;&#70;&#67; 3596: DNS Extensions to Support IP Version 6 |hrsg=[[The Internet Society]] |datum=2003-10 |abruf=2015-02-20 |sprache=en}}</ref>
|RFC 3596<ref>{{Internetquelle |url=http://tools.ietf.org/html/rfc3596#section-2 |titel=&#82;&#70;&#67; 3596: DNS Extensions to Support IP Version 6 |hrsg=[[The Internet Society]] |datum=2003-10 |abruf=2015-02-20 |sprache=en}}</ref>
|[[IPv6]] Address record|| Gibt die 128 Bit lange [[IPv6]]-Adresse eines Hosts zurück. Am häufigsten für die Zuordnung eines [[Hostname]]ns zu einer IP-Adresse des Hosts gebräuchlich.
|[[IPv6]] Address record|| Gibt die 128 Bit lange [[IPv6]]-Adresse eines Hosts zurück. Am häufigsten für die Zuordnung eines [[Hostname]]ns zu einer IP-Adresse des Hosts gebräuchlich.
|-
|-
|{{Anker|AFSDB}}[[AFSDB Resource Record|AFSDB]]
|[[AFSDB Resource Record|AFSDB]]
|18
|18
|RFC 1183
|RFC 1183
Zeile 104: Zeile 85:
|Resource Record für den Ort von Cell Database Server des [[Andrew File System]]s. 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 Distributed File System|DCE/DFS]]-Dateisystems verwendet.
|Resource Record für den Ort von Cell Database Server des [[Andrew File System]]s. 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 Distributed File System|DCE/DFS]]-Dateisystems verwendet.
|-
|-
|{{Anker|APL}}[[APL Resource Record|APL]]
|[[APL Resource Record|APL]]
|42
|42
|RFC 3123
|RFC 3123
|Address Prefix List
|Address Prefix List
|Auflisten von Adressbereichen, z.&nbsp;B. im [[CIDR]]-Format, für verschiedene Adressfamilien. Versuchsweise eingeführt.
|Auflisten von Adressbereichen, z.&nbsp;B.&nbsp;im [[CIDR]]-Format, für verschiedene Adressfamilien. Versuchsweise eingeführt.
|-
|-
|{{Anker|A6}}[[A6 Resource Record|A6]]
|[[A6 Resource Record|A6]]
|
|
|
|
Zeile 116: Zeile 97:
|Resource Record des Verfahrens A6 zur teilweisen Adressauflösung unter IPv6. Inzwischen veraltet.
|Resource Record des Verfahrens A6 zur teilweisen Adressauflösung unter IPv6. Inzwischen veraltet.
|-
|-
|{{Anker|CAA}}[[CAA Resource Record|CAA]]
|[[CAA Resource Record|CAA]]
|257
|257
|RFC 6844
|RFC 6844
|Certification Authority Authorization
|Certification Authority Authorization
|Certification Authority (CA) Blockierung, die zulässige CAs für einen Host bzw. eine Domain beschränken
|Certification Authority (CA) Blockierung, die zulässige CAs für einen Host bzw.&nbsp;eine Domain beschränken
|-
|-
|{{Anker|CDNSKEY}}[[CDNSKEY Resource Record|CDNSKEY]]
|[[CDNSKEY Resource Record|CDNSKEY]]
|60
|60
|RFC 7344
|RFC 7344
Zeile 128: Zeile 109:
|Kindkopie eines DNSKEY-Records, um sie an sein Eltern-Record zu übertragen
|Kindkopie eines DNSKEY-Records, um sie an sein Eltern-Record zu übertragen
|-
|-
|{{Anker|CDS}}[[CDS Resource Record|CDS]]
|[[CDS Resource Record|CDS]]
|59
|59
|RFC 7344
|RFC 7344
Zeile 134: Zeile 115:
|Kindkopie eines DS-Records, um sie an sein Eltern-Record zu übertragen
|Kindkopie eines DS-Records, um sie an sein Eltern-Record zu übertragen
|-
|-
|{{Anker|CERT}}[[CERT Resource Record|CERT]]
|[[CERT Resource Record|CERT]]
|37
|37
|RFC 4398
|RFC 4398
Zeile 140: Zeile 121:
|Resource Record für das Speichern von Zertifikaten wie [[PKIX]], [[SPKI]] und [[Pretty Good Privacy|PGP]]
|Resource Record für das Speichern von Zertifikaten wie [[PKIX]], [[SPKI]] und [[Pretty Good Privacy|PGP]]
|-
|-
|{{Anker|CNAME}}[[CNAME Resource Record|CNAME]]
|[[CNAME Resource Record|CNAME]]
|5
|5
|[https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.1 RFC 1035]<ref name="RFC1035_page-12" />
|[https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.1 RFC 1035]<ref name="RFC1035_page-12" />
Zeile 146: Zeile 127:
|Kanonischer Name für einen Host (die Domain mit diesem RR ist ein Alias)
|Kanonischer Name für einen Host (die Domain mit diesem RR ist ein Alias)
|-
|-
|{{Anker|DHCID}}[[DHCID Resource Record|DHCID]]
|[[DHCID Resource Record|DHCID]]
|49
|49
|RFC 4701
|RFC 4701
Zeile 152: Zeile 133:
|In Verbindung mit der FQDN-Option für [[DHCP]] benutzt.
|In Verbindung mit der FQDN-Option für [[DHCP]] benutzt.
|-
|-
|{{Anker|DLV}}[[DLV Resource Record|DLV]]
|[[DLV Resource Record|DLV]]
|32769
|32769
|RFC 4431
|RFC 4431
Zeile 158: Zeile 139:
|Benutzt zur Veröffentlichung von [[DNSSEC]] ''Trust Anchors'' außerhalb der DNS Delegationskette (''delegation chain''). Benutzt dasselbe Format wie der DS-Record. RFC 5074 beschreibt die Art der Benutzung dieser Records.
|Benutzt zur Veröffentlichung von [[DNSSEC]] ''Trust Anchors'' außerhalb der DNS Delegationskette (''delegation chain''). Benutzt dasselbe Format wie der DS-Record. RFC 5074 beschreibt die Art der Benutzung dieser Records.
|-
|-
|{{Anker|DNAME}}[[DNAME Resource Record|DNAME]]
|[[DNAME Resource Record|DNAME]]
|39
|39
|RFC 2672
|RFC 2672
Zeile 164: Zeile 145:
|Alias 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. <!-- lässt sich sicherlich besser formulieren... --->
|Alias 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. <!-- lässt sich sicherlich besser formulieren... --->
|-
|-
|{{Anker|DNSKEY}}[[DNSKEY Resource Record|DNSKEY]]
|[[DNSKEY Resource Record|DNSKEY]]
|48
|48
|RFC 4034
|RFC 4034
Zeile 170: Zeile 151:
|Enthält einen dem Namen zugeordneten [[Öffentlicher Schlüssel|Public-Key]] und löste ab 2004 bei [[DNSSEC]] den Typ KEY ab.
|Enthält einen dem Namen zugeordneten [[Öffentlicher Schlüssel|Public-Key]] und löste ab 2004 bei [[DNSSEC]] den Typ KEY ab.
|-
|-
|{{Anker|DS}}[[DS Resource Record|DS]]
|[[DS Resource Record|DS]]
|43
|43
|RFC 4034
|RFC 4034
Zeile 176: Zeile 157:
|Dient der Identifizierung und Verkettung DNSSEC-signierter Zonen
|Dient der Identifizierung und Verkettung DNSSEC-signierter Zonen
|-
|-
|{{Anker|GPOS}}[[GPOS Resource Record|GPOS]]
|[[GPOS Resource Record|GPOS]]
|
|
|
|
Zeile 182: Zeile 163:
|Geographische Position, veraltet.
|Geographische Position, veraltet.
|-
|-
|{{Anker|HIP}}[[Host Identity Protocol Resource Record|HIP]]
|[[Host Identity Protocol Resource Record|HIP]]
|55
|55
|RFC 5205
|RFC 5205
Zeile 188: Zeile 169:
|Methode zur Trennung der Endpunktkennzeichnung und Ortungsfunktionen von [[IP-Adresse]]n.
|Methode zur Trennung der Endpunktkennzeichnung und Ortungsfunktionen von [[IP-Adresse]]n.
|-
|-
|{{Anker|HINFO}}[[HINFO Resource Record|HINFO]]
|[[HINFO Resource Record|HINFO]]
|13
|13
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" />
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" />
Zeile 194: Zeile 175:
|Informationen des Hosts wie [[Hauptprozessor|Prozessortyp]] und [[Betriebssystem]]
|Informationen des Hosts wie [[Hauptprozessor|Prozessortyp]] und [[Betriebssystem]]
|-
|-
|{{Anker|HTTPS}}[[Hypertext Transfer Protocol Secure|HTTPS]]
|[[Hypertext Transfer Protocol Secure|HTTPS]]
|65
|65
|[https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/00/?include_text=1 RFC Draft]
|[https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/00/?include_text=1 RFC Draft]
Zeile 200: Zeile 181:
|Verbesserte Performance für den direkten Zugriff auf HTTPS-Ressourcen
|Verbesserte Performance für den direkten Zugriff auf HTTPS-Ressourcen
|-
|-
|{{Anker|IPSECKEY}}[[IPSECKEY Resource Record|IPSECKEY]]
|[[IPSECKEY Resource Record|IPSECKEY]]
|45
|45
|RFC 4025
|RFC 4025
Zeile 206: Zeile 187:
|Schlüsseleintrag, der mit [[IPsec]] verwendet werden kann
|Schlüsseleintrag, der mit [[IPsec]] verwendet werden kann
|-
|-
|{{Anker|ISDN}}[[ISDN Resource Record|ISDN]]
|[[ISDN Resource Record|ISDN]]
|
|
|
|
Zeile 212: Zeile 193:
|[[Integrated Services Digital Network|ISDN]]-Nummer, wird nur selten verwendet.
|[[Integrated Services Digital Network|ISDN]]-Nummer, wird nur selten verwendet.
|-
|-
|{{Anker|KEY}}[[KEY Resource Record|KEY]]
|[[KEY Resource Record|KEY]]
|25
|25
|RFC 2535<ref>RFC 2535, §3</ref> und RFC 2930<ref name="rfc3445_sec1_def">RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."</ref>
|RFC 2535<ref>RFC 2535, §3</ref> und RFC 2930<ref name="rfc3445_sec1_def">RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."</ref>
Zeile 219: Zeile 200:
Wurde nur für SIG(0) (RFC 2931) und TKEY (RFC 2930) verwendet.<ref>RFC 2931, §2.4. “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."</ref> RFC 3445 schloss die Nutzung für Anwendungsschlüssel aus und beschränkte ihre Nutzung auf DNSSEC.<ref name="rfc3445_sec1_subtype">RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR…”</ref> RFC 3755 kennzeichnet DNSKEY als den Ersatz innerhalb von DNSSEC.<ref name="rfc3755_sec3">RFC 3755, §3. “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.”</ref> RFC 4025 benennt IPSECKEY als Ersatz bei der Nutzung von IPsec.<ref>RFC 4025, Abstract. “This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445.”</ref>
Wurde nur für SIG(0) (RFC 2931) und TKEY (RFC 2930) verwendet.<ref>RFC 2931, §2.4. “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."</ref> RFC 3445 schloss die Nutzung für Anwendungsschlüssel aus und beschränkte ihre Nutzung auf DNSSEC.<ref name="rfc3445_sec1_subtype">RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR…”</ref> RFC 3755 kennzeichnet DNSKEY als den Ersatz innerhalb von DNSSEC.<ref name="rfc3755_sec3">RFC 3755, §3. “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.”</ref> RFC 4025 benennt IPSECKEY als Ersatz bei der Nutzung von IPsec.<ref>RFC 4025, Abstract. “This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445.”</ref>
|-
|-
|{{Anker|KX}}[[KX Resource Record|KX]]
|[[KX Resource Record|KX]]
|36
|36
|RFC 2230
|RFC 2230
Zeile 225: Zeile 206:
|Wird 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.
|Wird 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.
|-
|-
|{{Anker|LOC}}[[LOC Resource Record|LOC]]
|[[LOC Resource Record|LOC]]
|29
|29
|RFC 1876
|RFC 1876
Zeile 231: Zeile 212:
|Führt einen geografischen Ort (Lokation) auf, der mit einem Domainnamen in Verbindung gebracht werden kann.
|Führt einen geografischen Ort (Lokation) auf, der mit einem Domainnamen in Verbindung gebracht werden kann.
|-
|-
|{{Anker|MB}}[[MB Resource Record|MB]]
|[[MB Resource Record|MB]]
|
|
|
|
Zeile 237: Zeile 218:
|Spezifiziert einen Domainnamen in Verbindung mit einer Mailbox. ''Experimentell''
|Spezifiziert einen Domainnamen in Verbindung mit einer Mailbox. ''Experimentell''
|-
|-
|{{Anker|MD}}[[MD Resource Record|MD]]
|[[MD Resource Record|MD]]
|
|
|
|
Zeile 243: Zeile 224:
|Nicht mehr in Gebrauch. Heutzutage wird MX verwendet.
|Nicht mehr in Gebrauch. Heutzutage wird MX verwendet.
|-
|-
|{{Anker|MF}}[[MF Resource Record|MF]]
|[[MF Resource Record|MF]]
|
|
|
|
Zeile 249: Zeile 230:
|Nicht mehr in Gebrauch. Heutzutage wird MX verwendet.
|Nicht mehr in Gebrauch. Heutzutage wird MX verwendet.
|-
|-
|{{Anker|MG}}[[MG Resource Record|MG]]
|[[MG Resource Record|MG]]
|
|
|
|
Zeile 255: Zeile 236:
|''Experimentell''
|''Experimentell''
|-
|-
|{{Anker|MINFO}}[[MINFO Resource Record|MINFO]]
|[[MINFO Resource Record|MINFO]]
|
|
|
|
Zeile 261: Zeile 242:
|
|
|-
|-
|{{Anker|MR}}[[MR Resource Record|MR]]
|[[MR Resource Record|MR]]
|
|
|
|
Zeile 267: Zeile 248:
|''Experimentell''
|''Experimentell''
|-
|-
|{{Anker|MX}}[[MX Resource Record|MX]]
|[[MX Resource Record|MX]]
|15
|15
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" /> und RFC 7505
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" /> und RFC 7505
Zeile 273: Zeile 254:
|Ordnet den für diese Domain zuständigen [[Mailserver]] einer Liste von [[Mail Transfer Agent]]s zu.
|Ordnet den für diese Domain zuständigen [[Mailserver]] einer Liste von [[Mail Transfer Agent]]s zu.
|-
|-
|{{Anker|NAPTR}}[[NAPTR Resource Record|NAPTR]]
|[[NAPTR Resource Record|NAPTR]]
|35
|35
|RFC 3403
|RFC 3403
Zeile 279: Zeile 260:
|Eine Erweiterung des [[A Resource Record]], die die Schreibung von Domainnamen mit [[Regulärer Ausdruck|regulären Ausdrücken]]  erlaubt. Diese kann dann in [[Uniform Resource Identifier|URIs]], weiteren Domainnamen zum Nachschlagen etc. benutzt werden.
|Eine Erweiterung des [[A Resource Record]], die die Schreibung von Domainnamen mit [[Regulärer Ausdruck|regulären Ausdrücken]]  erlaubt. Diese kann dann in [[Uniform Resource Identifier|URIs]], weiteren Domainnamen zum Nachschlagen etc. benutzt werden.
|-
|-
|{{Anker|NS}}[[NS Resource Record|NS]]
|[[NS Resource Record|NS]]
|2
|2
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" />
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" />
Zeile 285: Zeile 266:
|Hostname eines autoritativen Nameservers. Überträgt eine [[Zone (DNS)|DNS Zone]], um die vorgegebenen [[Domain Name System#Nameserver|Nameserver]] zu nutzen.
|Hostname eines autoritativen Nameservers. Überträgt eine [[Zone (DNS)|DNS Zone]], um die vorgegebenen [[Domain Name System#Nameserver|Nameserver]] zu nutzen.
|-
|-
|{{Anker|NSAP}}[[NSAP Resource Record|NSAP]]
|[[NSAP Resource Record|NSAP]]
|2
|2
|
|
Zeile 291: Zeile 272:
|
|
|-
|-
|{{Anker|NSEC}}[[NSEC Resource Record|NSEC]]
|[[NSEC Resource Record|NSEC]]
|47
|47
|RFC 4034
|RFC 4034
Zeile 297: Zeile 278:
|Verkettet 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 [[Reource Record#NXT|NXT]].
|Verkettet 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 [[Reource Record#NXT|NXT]].
|-
|-
|{{Anker|NSEC3}}[[NSEC3 Resource Record|NSEC3]]
|[[NSEC3 Resource Record|NSEC3]]
|50
|50
|RFC 5155
|RFC 5155
Zeile 303: Zeile 284:
|Alternative zum NSEC RR ohne Zone Enumeration Problem (seit 2008). Ermöglicht den Nachweis, dass ein Name fehlt, ohne die Überschreitung einer Zone zuzulassen.
|Alternative zum NSEC RR ohne Zone Enumeration Problem (seit 2008). Ermöglicht den Nachweis, dass ein Name fehlt, ohne die Überschreitung einer Zone zuzulassen.
|-
|-
|{{Anker|NSEC3PARAM}}[[NSEC3PARAM Resource Record|NSEC3PARAM]]
|[[NSEC3PARAM Resource Record|NSEC3PARAM]]
|51
|51
|RFC 5155
|RFC 5155
Zeile 309: Zeile 290:
|Parameter Eintrag für NSEC3.
|Parameter Eintrag für NSEC3.
|-
|-
|{{Anker|NULL}}[[NULL Resource Record|NULL]]
|[[NULL Resource Record|NULL]]
|
|
|
|
Zeile 315: Zeile 296:
|''Experimentell''
|''Experimentell''
|-
|-
|{{Anker|NXT}}[[NXT Resource Record|NXT]]
|[[NXT Resource Record|NXT]]
|
|
|
|
Zeile 321: Zeile 302:
|Veraltet. Wurde durch den praktisch identischen NSEC Resource Record abgelöst.
|Veraltet. Wurde durch den praktisch identischen NSEC Resource Record abgelöst.
|-
|-
|{{Anker|OPT}}[[OPT Resource Record|OPT]]
|[[OPT Resource Record|OPT]]
|
|
|[https://tools.ietf.org/html/rfc2671#page-1 RFC 2671]
|[https://tools.ietf.org/html/rfc2671#page-1 RFC 2671]
Zeile 327: Zeile 308:
|Pseudo RR<ref>RFC 2671, §4. "An OPT is called a pseudo-RR because it pertains to a particular transport level message and not to any actual DNS data."</ref>, markiert ein Paket als [[Extended DNS|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).
|Pseudo RR<ref>RFC 2671, §4. "An OPT is called a pseudo-RR because it pertains to a particular transport level message and not to any actual DNS data."</ref>, markiert ein Paket als [[Extended DNS|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).
|-
|-
|{{Anker|PTR}}[[PTR Resource Record|PTR]]
|[[PTR Resource Record|PTR]]
|12
|12
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" />
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" />
Zeile 333: Zeile 314:
|Domain Name Pointer zu einem kanonischen Namen für das [[Reverse DNS|Reverse Mapping]], um IP-Adressen Namen zuzuweisen. Im Gegensatz zu [[#CNAME|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 [[Zero-configuration networking#Apple's multicast DNS/DNS-SD|DNS-SD]] eingesetzt.
|Domain Name Pointer zu einem kanonischen Namen für das [[Reverse DNS|Reverse Mapping]], um IP-Adressen Namen zuzuweisen. Im Gegensatz zu [[#CNAME|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 [[Zero-configuration networking#Apple's multicast DNS/DNS-SD|DNS-SD]] eingesetzt.
|-
|-
|{{Anker|RP}}[[RP Resource Record|RP]]
|[[RP Resource Record|RP]]
|17
|17
|RFC 1183
|RFC 1183
Zeile 339: Zeile 320:
|Information über die verantwortliche(n) Person(en) für die Domain. Üblicherweise eine E-Mail-Adresse, wobei das '@' durch ein '.' ersetzt wurde.
|Information über die verantwortliche(n) Person(en) für die Domain. Üblicherweise eine E-Mail-Adresse, wobei das '@' durch ein '.' ersetzt wurde.
|-
|-
|{{Anker|RRSIG}}[[RRSIG Resource Record|RRSIG]]
|[[RRSIG Resource Record|RRSIG]]
|46
|46
|RFC 4034
|RFC 4034
Zeile 345: Zeile 326:
|Enthält eine [[digitale Unterschrift]] für den Eintrag. Wird seit 2004 von [[DNSSEC]] (=''DNS Security'') verwendet und ersetzt das gleichformatige SIG.
|Enthält eine [[digitale Unterschrift]] für den Eintrag. Wird seit 2004 von [[DNSSEC]] (=''DNS Security'') verwendet und ersetzt das gleichformatige SIG.
|-
|-
|{{Anker|SIG}}[[SIG Resource Record|SIG]]
|[[SIG Resource Record|SIG]]
|24
|24
|RFC 2535
|RFC 2535
Zeile 351: Zeile 332:
|Enthält eine [[digitale Unterschrift]], die in SIG(0) (RFC 2931) und TKEY (RFC 2930) benutzt wird.<ref name="rfc3755_sec3" /> SIG ist veraltet und wurde bis 2004 von [[DNSSEC]] (=''DNS Security'') verwendet. RFC 3755 nennt RRSIG als Ersatz für SIG zur Benutzung in DNSSEC.<ref name="rfc3755_sec3" />
|Enthält eine [[digitale Unterschrift]], die in SIG(0) (RFC 2931) und TKEY (RFC 2930) benutzt wird.<ref name="rfc3755_sec3" /> SIG ist veraltet und wurde bis 2004 von [[DNSSEC]] (=''DNS Security'') verwendet. RFC 3755 nennt RRSIG als Ersatz für SIG zur Benutzung in DNSSEC.<ref name="rfc3755_sec3" />
|-
|-
|{{Anker|SOA}}[[SOA Resource Record|SOA]]
|[[SOA Resource Record|SOA]]
|6
|6
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" /> und RFC 2308<ref>The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.</ref>
|[http://tools.ietf.org/html/rfc1035#page-12 RFC 1035]<ref name="RFC1035_page-12" /> und RFC 2308<ref>The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.</ref>
Zeile 357: Zeile 338:
|Führt ''verbindliche'' Informationen über eine [[Zone (DNS)|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.
|Führt ''verbindliche'' Informationen über eine [[Zone (DNS)|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.
|-
|-
|{{Anker|SPF}}[[SPF Resource Record|SPF]]
|[[SPF Resource Record|SPF]]
|
|
|
|
Zeile 363: Zeile 344:
|Der Eintrag [[Sender Policy Framework|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.
|Der Eintrag [[Sender Policy Framework|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.
|-
|-
|{{Anker|SRV}}[[SRV Resource Record|SRV]]
|[[SRV Resource Record|SRV]]
|33
|33
|RFC 2782
|RFC 2782
Zeile 369: Zeile 350:
|Verallgemeinernder Eintrag zu angebotenen Diensten (Services). Wird von neueren Protokollen benutzt anstatt protokollspezifische Einträge zu erstellen, wie dies bei MX der Fall ist.
|Verallgemeinernder Eintrag zu angebotenen Diensten (Services). Wird von neueren Protokollen benutzt anstatt protokollspezifische Einträge zu erstellen, wie dies bei MX der Fall ist.
|-
|-
|{{Anker|SSHFP}}[[SSHFP Resource Record|SSHFP]]
|[[SSHFP Resource Record|SSHFP]]
|44
|44
|RFC 4255
|RFC 4255
Zeile 375: Zeile 356:
|Veröffentlichung der Fingerprints von [[Secure Shell|SSH]]-Schlüsseln in das DNS, um die Überprüfung der Echtheit eines Hosts zu unterstützen. RFC 6594 definiert die ECC SSH-Schlüssel und die SHA-256 Hashes. Details sind bei der [http://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.xml IANA SSHFP RR parameters registry] zu finden.
|Veröffentlichung der Fingerprints von [[Secure Shell|SSH]]-Schlüsseln in das DNS, um die Überprüfung der Echtheit eines Hosts zu unterstützen. RFC 6594 definiert die ECC SSH-Schlüssel und die SHA-256 Hashes. Details sind bei der [http://www.iana.org/assignments/dns-sshfp-rr-parameters/dns-sshfp-rr-parameters.xml IANA SSHFP RR parameters registry] zu finden.
|-
|-
|{{Anker|TA}}[[TA Resource Record|TA]]
|[[TA Resource Record|TA]]
|32768
|32768
|{{N/A-Feld}}
|{{N/A-Feld}}
Zeile 381: Zeile 362:
|Teil eines Entwicklungsvorschlages für DNSSEC ohne signierten DNS Root. Für Details siehe die [http://www.iana.org/assignments/dns-parameters IANA Datenbank] und die [http://www.watson.org/~weiler/INI1999-19.pdf Weiler Spezifikationen]. TA benutzt dasselbe Format wie der [[#DS|DS Resource Record]].
|Teil eines Entwicklungsvorschlages für DNSSEC ohne signierten DNS Root. Für Details siehe die [http://www.iana.org/assignments/dns-parameters IANA Datenbank] und die [http://www.watson.org/~weiler/INI1999-19.pdf Weiler Spezifikationen]. TA benutzt dasselbe Format wie der [[#DS|DS Resource Record]].
|-
|-
|{{Anker|TKEY}}[[TKEY Resource Record|TKEY]]
|[[TKEY Resource Record|TKEY]]
|249
|249
|RFC 2930
|RFC 2930
Zeile 387: Zeile 368:
|Eine 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.<ref>RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC 2535]."</ref>
|Eine 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.<ref>RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC 2535]."</ref>
|-
|-
|{{Anker|TLSA}}[[TLSA Resource Record|TLSA]]
|[[TLSA Resource Record|TLSA]]
|52
|52
|RFC 6698
|RFC 6698
Zeile 394: Zeile 375:
“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’”</ref>
“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’”</ref>
|-
|-
|{{Anker|TSIG}}[[TSIG Resource Record|TSIG]]
|[[TSIG Resource Record|TSIG]]
|250
|250
|RFC 2845
|RFC 2845
Zeile 400: Zeile 381:
|Kann, in ähnlicher Weise zu DNSSEC, für die Authentifikation von [[Dynamisches DNS|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.
|Kann, in ähnlicher Weise zu DNSSEC, für die Authentifikation von [[Dynamisches DNS|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.
|-
|-
|{{Anker|TXT}}[[TXT Resource Record|TXT]]
|[[TXT Resource Record|TXT]]
|16
|16
|[https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.14 RFC 1035]<ref name="RFC1035_page-12" />
|[https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.14 RFC 1035]<ref name="RFC1035_page-12" />
Zeile 406: Zeile 387:
|Ursprü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.&nbsp;a. auch [[Maschinenlesbarkeit|maschinenlesbare]] Daten wie in RFC 1464 spezifiziert, [[Sender Policy Framework|Sender Policy Framework (SPF)]], [[DomainKeys]], [[DMARC]] (Domain-based Message Authentication, Reporting and Conformance), [[Zeroconf|DNS-SD]] und Google-Site Verification.
|Ursprü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.&nbsp;a. auch [[Maschinenlesbarkeit|maschinenlesbare]] Daten wie in RFC 1464 spezifiziert, [[Sender Policy Framework|Sender Policy Framework (SPF)]], [[DomainKeys]], [[DMARC]] (Domain-based Message Authentication, Reporting and Conformance), [[Zeroconf|DNS-SD]] und Google-Site Verification.
|-
|-
|{{Anker|URI}}[[URI Resource Record|URI]]
|[[URI Resource Record|URI]]
|256
|256
|[https://tools.ietf.org/html/rfc7553 RFC 7553]
|[https://tools.ietf.org/html/rfc7553 RFC 7553]
Zeile 412: Zeile 393:
| Wird benutzt, um Abbildungen von Hostnamen auf URIs zu veröffentlichen.
| Wird benutzt, um Abbildungen von Hostnamen auf URIs zu veröffentlichen.
|-
|-
|{{Anker|WKS}}[[WKS Resource Record|WKS]]
|[[WKS Resource Record|WKS]]
|
|
|[http://tools.ietf.org/html/rfc0974#page-1 RFC 0974]<ref name="RFC0974_page-1" />
|[http://tools.ietf.org/html/rfc0974#page-1 RFC 0974]<ref name="RFC0974_page-1" />
|Well Known Service
|Well Known Service
|Wird in der Mailweiterleitung benutzt und speichert Informationen über die Netzwerkdienste (wie z.&nbsp;B. [[SMTP]]), die ein vorgegebener Domainname unterstützt.<ref name="RFC0974_page-1">{{Internetquelle |autor=Craig Partridge, CSNET CIC BBN Laboratories Inc |url=https://www.ietf.org/rfc/rfc0974.txt |titel=&#82;&#70;&#67; 0974: MAIL ROUTING AND THE DOMAIN SYSTEM |datum=1986-01 |abruf=2015-02-20 |sprache=en}}
|Wird in der Mailweiterleitung benutzt und speichert Informationen über die Netzwerkdienste (wie z.&nbsp;B.&nbsp;[[SMTP]]), die ein vorgegebener Domainname unterstützt.<ref name="RFC0974_page-1">{{Internetquelle |autor=Craig Partridge, CSNET CIC BBN Laboratories Inc |url=https://www.ietf.org/rfc/rfc0974.txt |titel=&#82;&#70;&#67; 0974: MAIL ROUTING AND THE DOMAIN SYSTEM |datum=1986-01 |abruf=2015-02-20 |sprache=en}}
“[…] the Well Known Service (WKS) RR, which stores information about network services (such as SMTP) a given domain name supports.”</ref>
“[…] the Well Known Service (WKS) RR, which stores information about network services (such as SMTP) a given domain name supports.”</ref>
|-
|-
|{{Anker|X25}}[[X25 Resource Record|X25]]
|[[X25 Resource Record|X25]]
|
|
|RFC 1356
|RFC 1356
Zeile 426: Zeile 407:
|}
|}


== Beispiele ==
== Konfiguration ==
=== Dateien ===
== Sicherheit ==
 
== Siehe auch ==
=== Dokumentation ===
==== RFC ====
==== Man-Page ====
==== Info-Pages ====
=== Links ===
==== Projekt ====
==== Weblinks ====
# https://de.wikipedia.org/wiki/Kategorie:Resource_Record
 


  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.


== Einzelnachweise ==
<references />


[[Kategorie:Resource Record| ]]
[[Kategorie:Resource Record| ]]
[[Kategorie:DNS]]
[[Kategorie:DNS]]
# https://de.wikipedia.org/wiki/Kategorie:Resource_Record

Aktuelle Version vom 6. November 2024, 12:31 Uhr

Resource Record - Eintrag in der DNS-Datenbank

Beschreibung

Grundlegende Informationseinheit im Domain Name System (DNS)
Pseudo-Resource-Records

Werden nur in DNS-Transport-Paketen verwendet

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 eine inhaltsgleiche, aber komprimierte Form verwendet
  • RR-Typen werden dort durch Zahlen zwischen 1 und 255 ausgedrückt
  • Ähnliches gilt für Class und TTL.
ASCII-Format
<name> [<ttl>] [<class>] <type> [<rdlength>] <rdata>
Option Beschreibung
<name> Der Domänenname des Objekts, zu dem der Resource Record gehört
<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
<rdlength> Länge der Daten, welche den Resource Record näher beschreiben (optional)
<rdata> (resource data) Daten, welche den Resource Record näher beschreiben (etwa eine IP-Adresse für einen A-RR, oder einen Hostnamen für einen NS-RR)
Bei einigen Typen existieren weitere Felder
  • die unmittelbar vor <rdata> eingeordnet werden (siehe Beispiel unter MX)
Optionale Komponenten können in bestimmten Fällen weggelassen werden
  • Es wird dann vom Nameserver automatisch der zuletzt aufgetretene Wert dieser Komponente eingesetzt

Klassen

In der Praxis wird nahezu ausnahmslos IN verwendet

Andere Klassen haben nur historische Bedeutung

  • Von BIND-Servern wird gelegentlich CH gebraucht, um die Versionsnummer eines Nameservers zu publizieren
Klasse Beschreibung
IN Internet
CH Chaosnet (selten verwendet)
HS Hesiod (selten verwendet)
CS CSNET (nicht mehr verwendet)

Typen

Typ Wert (dezimal) Definierendes RFC Beschreibung Funktion
A 1 RFC 1035[1] Address record Gibt 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 dgl. verwendet.
AAAA 28 RFC 3596[2] IPv6 Address record Gibt 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.
AFSDB 18 RFC 1183 AFS Database Record Resource 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.
APL 42 RFC 3123 Address Prefix List Auflisten von Adressbereichen, z. B. im CIDR-Format, für verschiedene Adressfamilien. Versuchsweise eingeführt.
A6 Resource Record des Verfahrens A6 zur teilweisen Adressauflösung unter IPv6. Inzwischen veraltet.
CAA 257 RFC 6844 Certification Authority Authorization Certification Authority (CA) Blockierung, die zulässige CAs für einen Host bzw. eine Domain beschränken
CDNSKEY 60 RFC 7344 Child DNSKEY Kindkopie eines DNSKEY-Records, um sie an sein Eltern-Record zu übertragen
CDS 59 RFC 7344 Child DS Kindkopie eines DS-Records, um sie an sein Eltern-Record zu übertragen
CERT 37 RFC 4398 Certificate record Resource Record für das Speichern von Zertifikaten wie PKIX, SPKI und PGP
CNAME 5 RFC 1035[1] Canonical Name record Kanonischer Name für einen Host (die Domain mit diesem RR ist ein Alias)
DHCID 49 RFC 4701 DHCP Identifier In Verbindung mit der FQDN-Option für DHCP benutzt.
DLV 32769 RFC 4431 DNSSEC Lookaside Validation record Benutzt zur Veröffentlichung von DNSSEC Trust Anchors außerhalb der DNS Delegationskette (delegation chain). Benutzt dasselbe Format wie der DS-Record. RFC 5074 beschreibt die Art der Benutzung dieser Records.
DNAME 39 RFC 2672 Delegation Name Alias 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.
DNSKEY 48 RFC 4034 DNS Key record Enthält einen dem Namen zugeordneten Public-Key und löste ab 2004 bei DNSSEC den Typ KEY ab.
DS 43 RFC 4034 Delegation Signer Dient der Identifizierung und Verkettung DNSSEC-signierter Zonen
GPOS Geographical Position Geographische Position, veraltet.
HIP 55 RFC 5205 Host Identity Protocol Methode zur Trennung der Endpunktkennzeichnung und Ortungsfunktionen von IP-Adressen.
HINFO 13 RFC 1035[1] Host Information Informationen des Hosts wie Prozessortyp und Betriebssystem
HTTPS 65 RFC Draft HTTPS Binding Verbesserte Performance für den direkten Zugriff auf HTTPS-Ressourcen
IPSECKEY 45 RFC 4025 IPsec Key Schlüsseleintrag, der mit IPsec verwendet werden kann
ISDN ISDN ISDN-Nummer, wird nur selten verwendet.
KEY 25 RFC 2535[3] und RFC 2930[4] Key record Enthä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) verwendet.[5] RFC 3445 schloss die Nutzung für Anwendungsschlüssel aus und beschränkte ihre Nutzung auf DNSSEC.[6] RFC 3755 kennzeichnet DNSKEY als den Ersatz innerhalb von DNSSEC.[7] RFC 4025 benennt IPSECKEY als Ersatz bei der Nutzung von IPsec.[8]

KX 36 RFC 2230 Key eXchanger record Wird 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.
LOC 29 RFC 1876 Location record Führt einen geografischen Ort (Lokation) auf, der mit einem Domainnamen in Verbindung gebracht werden kann.
MB Mailbox domain name Spezifiziert einen Domainnamen in Verbindung mit einer Mailbox. Experimentell
MD Mail Destination Nicht mehr in Gebrauch. Heutzutage wird MX verwendet.
MF Mail Forwarder Nicht mehr in Gebrauch. Heutzutage wird MX verwendet.
MG Mail Group member Experimentell
MINFO Mailbox oder mail list information
MR Mail Rename domain name Experimentell
MX 15 RFC 1035[1] und RFC 7505 Mail eXchange record Ordnet den für diese Domain zuständigen Mailserver einer Liste von Mail Transfer Agents zu.
NAPTR 35 RFC 3403 Naming Authority Pointer Eine 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.
NS 2 RFC 1035[1] Name Server record Hostname eines autoritativen Nameservers. Überträgt eine DNS Zone, um die vorgegebenen Nameserver zu nutzen.
NSAP 2 Network Service Access Point
NSEC 47 RFC 4034 Next-Secure record Verkettet 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.
NSEC3 50 RFC 5155 NSEC record version 3 or NSEC hashed Alternative zum NSEC RR ohne Zone Enumeration Problem (seit 2008). Ermöglicht den Nachweis, dass ein Name fehlt, ohne die Überschreitung einer Zone zuzulassen.
NSEC3PARAM 51 RFC 5155 NSEC3 Parameters Parameter Eintrag für NSEC3.
NULL Null Resource Record Experimentell
NXT Next Resource Record Veraltet. Wurde durch den praktisch identischen NSEC Resource Record abgelöst.
OPT RFC 2671 Option Resource Record Pseudo RR[9], 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).
PTR 12 RFC 1035[1] Pointer record Domain 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.
RP 17 RFC 1183 Responsible Person Information über die verantwortliche(n) Person(en) für die Domain. Üblicherweise eine E-Mail-Adresse, wobei das '@' durch ein '.' ersetzt wurde.
RRSIG 46 RFC 4034 DNSSEC Signature Enthält eine digitale Unterschrift für den Eintrag. Wird seit 2004 von DNSSEC (=DNS Security) verwendet und ersetzt das gleichformatige SIG.
SIG 24 RFC 2535 Signature Enthält eine digitale Unterschrift, die in SIG(0) (RFC 2931) und TKEY (RFC 2930) benutzt wird.[7] SIG ist veraltet und wurde bis 2004 von DNSSEC (=DNS Security) verwendet. RFC 3755 nennt RRSIG als Ersatz für SIG zur Benutzung in DNSSEC.[7]
SOA 6 RFC 1035[1] und RFC 2308[10] Start Of [a zone of] Authority Fü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.
SPF Sender 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.
SRV 33 RFC 2782 Service locator Verallgemeinernder Eintrag zu angebotenen Diensten (Services). Wird von neueren Protokollen benutzt anstatt protokollspezifische Einträge zu erstellen, wie dies bei MX der Fall ist.
SSHFP 44 RFC 4255 SSH public key Fingerprint Veröffentlichung der Fingerprints von SSH-Schlüsseln in das DNS, um die Überprüfung der Echtheit eines Hosts zu unterstützen. RFC 6594 definiert die ECC SSH-Schlüssel und die SHA-256 Hashes. Details sind bei der IANA SSHFP RR parameters registry zu finden.
TA 32768 Vorlage:N/A-Feld DNSSEC Trust Authorities Teil eines Entwicklungsvorschlages für DNSSEC ohne signierten DNS Root. Für Details siehe die IANA Datenbank und die Weiler Spezifikationen. TA benutzt dasselbe Format wie der DS Resource Record.
TKEY 249 RFC 2930 Secret Key Eine 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.[11]
TLSA 52 RFC 6698 TLSA certificate association Eintrag 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'.[12]
TSIG 250 RFC 2845 Transaction Signature Kann, 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.
TXT 16 RFC 1035[1] Text record Ursprü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 spezifiziert, Sender Policy Framework (SPF), DomainKeys, DMARC (Domain-based Message Authentication, Reporting and Conformance), DNS-SD und Google-Site Verification.
URI 256 RFC 7553 Uniform Resource Identifier Wird benutzt, um Abbildungen von Hostnamen auf URIs zu veröffentlichen.
WKS RFC 0974[13] Well Known Service Wird in der Mailweiterleitung benutzt und speichert Informationen über die Netzwerkdienste (wie z. B. SMTP), die ein vorgegebener Domainname unterstützt.[13]
X25 RFC 1356 X.25-Adresse Spezifiziert die Einkapselung von IP und anderen Netzwerkschichtprotokollen über X.25-Netzwerke. Wird nur selten verwendet.

Konfiguration

Dateien

Sicherheit

Siehe auch

Dokumentation

RFC

Man-Page

Info-Pages

Links

Projekt

Weblinks

  1. https://de.wikipedia.org/wiki/Kategorie:Resource_Record
  1. 1,0 1,1 1,2 1,3 1,4 1,5 1,6 1,7
  2. RFC 2535, §3
  3. RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."
  4. RFC 2931, §2.4. “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."
  5. RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR…”
  6. 7,0 7,1 7,2 RFC 3755, §3. “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.”
  7. RFC 4025, Abstract. “This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445.”
  8. RFC 2671, §4. "An OPT is called a pseudo-RR because it pertains to a particular transport level message and not to any actual DNS data."
  9. The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.
  10. RFC 2930, §6. "... the keying material is sent within the key data field of a TKEY RR encrypted under the public key in an accompanying KEY RR [RFC 2535]."
  11. “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’”
  12. 13,0 13,1 “[…] the Well Known Service (WKS) RR, which stores information about network services (such as SMTP) a given domain name supports.”