Domain Name System/Resource Record: Unterschied zwischen den Versionen

Aktuelle Version vom 24. Februar 2024, 15:53 Uhr

Resource Record - Eintrag in der DNS-Datenbank

Beschreibung

Grundlegende Informationseinheit im Domain Name System (DNS)

In ASCII-Darstellung in Zonendateien
In komprimierter Form in DNS-Transport-Paketen oder DNS-Caches

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-Pages

Info-Pages

Links

Projekt

Weblinks

https://de.wikipedia.org/wiki/Kategorie:Resource_Record

↑ ^1,0 ^1,1 ^1,2 ^1,3 ^1,4 ^1,5 ^1,6 ^1,7
↑
↑ RFC 2535, §3
↑ RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."
↑ 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."
↑ RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR…”
↑ ^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.”
↑ 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.”
↑ 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."
↑ The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.
↑ 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]."
↑ “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’”
↑ ^13,0 ^13,1 “[…] the Well Known Service (WKS) RR, which stores information about network services (such as SMTP) a given domain name supports.”

[RFC1035_page-12-1] 1,0 ^1,1 ^1,2 ^1,3 ^1,4 ^1,5 ^1,6 ^1,7

[2] ↑

[3] RFC 2535, §3

[rfc3445_sec1_def-4] RFC 3445, §1. "The KEY RR was defined in [RFC 2930]..."

[5] 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."

[rfc3445_sec1_subtype-6] RFC 3445, §1. "DNSSEC will be the only allowable sub-type for the KEY RR…”

[rfc3755_sec3-7] 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.”

[8] 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.”

[9] 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."

[10] The minimum field of SOA record is redefined to be the TTL of NXDOMAIN reply in RFC 2308.

[11] 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]."

[RFC6698_page-6-12] “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’”

[RFC0974_page-1-13] 13,0 ^13,1 “[…] the Well Known Service (WKS) RR, which stores information about network services (such as SMTP) a given domain name supports.”

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]