Ob beim Surfen, im Web, beim Versenden einer E-Mail oder beim Streamen eines Films – jedes dieser digitalen Erlebnisse wäre ohne dass Domain Name System (DNS) kaum möglich. DNS ist ein fester Bestandteil moderner Netzwerke, doch oft bleibt seine Rolle im Hintergrund verborgen. Es sorgt dafür, dass menschenlesbare Adressen wie technik-kiste.de blitzschnell in die passenden IP-Adressen umgewandelt werden, sodass die Kommunikation zwischen Geräten reibungslos funktioniert.
In diesem Artikel werfen wir einen Blick hinter die Kulissen: Was genau ist DNS, wie funktioniert es, und warum ist es so essenziell für unsere vernetzte Welt? Außerdem schauen wir uns an, wie DNS in lokalen Netzwerken eingesetzt wird und wie man durch gezielte Einstellungen mehr Sicherheit und Geschwindigkeit erreicht.
Inhalt:
- Aufbau einer Domain
- Registrierung einer Domain und deren Lifecycle
- Nameserver
- RFC
Aufbau einer Domain
Domains sind weit mehr als einfache Adressen im Web – sie sind systematisch aufgebaute Elemente, die bestimmte Informationen enthalten und weltweit eindeutig sind. Der Aufbau folgt einem hierarchischen Prinzip, das von rechts nach links gelesen wird.
Eine typische Domain besteht aus mehreren Bestandteilen, die durch Punkte getrennt sind:
Aufbau von Domainnamen. Quelle: Technik-Kiste.de
Sicherlich wird die root – also der Punkt ganz rechts – im Namen aufgefallen sein. Dieser stellt den Start einer Domain dar und wird durch uns im Normalfall nicht eingegeben, sondern durch Software ergänzt. Von der root an beginnt die Auflösung des Namens innerhalb des DNS:
Top-Level-Domain (TLD):
TLDs werden von der Internet Assigned Numbers Authority (IANA) verwaltet und lassen sich grob in folgende Kategorien einteilen:
|
Typ |
Beispiel |
Beschreibung |
|
Länderspezifisch (Country Code) |
.de, .fr |
Für einzelne Länder, oft mit Regeln zur Registrierung |
|
Generisch (Generic) |
.com, .net, .shop, .tech, .blog |
Ursprünglich für bestimmte Zwecke, heute meist frei wählbar und Firmen oder themenspezifisch für mehr Individualität. |
Hinweis: Wenn du wissen möchtest, welche TLD durch die IANA vergeben wurden, kannst du jederzeit unter: https://www.iana.org/domains/root/db (externer Link) nachsehen.
Second-Level-Domain (SLD):
Hierbei handelt es sich um den individuell gewählten Namen deiner Website, oft der Marken- oder Firmenname. Beachte, dass dieser zwar frei gewählt werden kann, dennoch gewissen Konventionen unterliegt:
- Keine Namen, welche eine rechtliche Verletzung von z. B. Verboten oder Markenrecht darstellen.
- Nichts, das gegen „die guten Sitten“ verstößt.
Eine SLD wird beim zuständigen Registrar – der meist der Internetdienstanbieter ist - beantragt.
Third-Level-Domain:
Die Third-Level-Domain nimmt unterschiedliche Stellungen ein. Es gibt einige Länder – z. B. Großbritannien – in denen ausschließlich Third-Level-Domains vergeben werden. In Europa und dem Großteil der Welt obliegt die Third-Level-Domain der eigenen Zuständigkeit und ist als Subdomain bekannt. Statt der Subdomain ist auch ein direkter Hostname für einen Server möglich.
Unterhalb der Third-Level-Domain werden in der Praxis meist noch weitere Ebenen in Form von Subdomains verwendet. Diese können sich auf Städte, Gebäude, Netzwerke etc. beziehen. Im Folgenden findest du ein Beispiel für solch einen Aufbau:
Beispiel einer Domain mit mehreren Ebenen. Quelle: Technik-Kiste.de
Registrierung einer Domain und deren Lifecycle
Die Verwaltung einer Domain umfasst weit mehr als nur das Hosting eines Dienstes. Sie ist Grundlage für Zugriffskontrolle, Authentifizierung, Netzwerkstrukturierung und Sicherheitsmanagement.
Die Registrierung erfolgt über akkreditierte Domain-Registrare mit Zugriff auf die jeweiligen Registry-Zonen (z. B. .de, .com, .org). Diese sind die Internetdienstanbieter wie z. B. Strato, IONOS etc.
Der Lebenszyklus einer Domain wird in unterschiedliche Phasen unterteilt:
- Registrierung:
- Initiale Reservierung der Domain
- Aktive Nutzung:
- Durch einen DNS-Eintrag auf einem Nameserver wird die Domain aktiv bis zum Ende ihrer Laufzeit (1 bis 2 Jahre) verwendet.
- Grace Period:
- Verlängerungszeitraum nach Ablauf der Domainlaufzeit
- Redemtion Period:
- Wiederherstellung der Domain gegen Gebühr möglich
- Deletion:
- Die Domain ist wieder verfügbar für eine Neuregistrierung
Beachte das der Umzug einer Domain zwischen zwei Providern ausschließlich durch einen Transfer-Code möglich ist. Dieser kann beim abgebenden Provider eingesehen werden.
Nameserver
Ein Nameserver ist ein zentraler Bestandteil des Domain Name Systems (DNS). Er ist ein spezialisierter Dienst auf einem Server, der Anfragen zu Domainnamen beantwortet und entsprechende DNS-Einträge ausliefert. Kurz gesagt: Er übersetzt Domains in IP-Adressen oder liefert andere DNS-Daten, die für den Netzwerkbetrieb relevant sind.
Ein Nameserver hält autoritative Informationen über eine oder mehrere Zonen im DNS – also Daten, die er direkt und vertrauenswürdig ausliefert. Bei einer DNS-Zone handelt es sich um einen abgegrenzten Bereich innerhalb des Domain Name Systems (DNS), für den ein bestimmter Nameserver verantwortlich ist. Sie enthält alle DNS-Einträge (Resource Records - RR) für eine gesamte Domain oder einen Teil davon und definiert, wie Anfragen zu dieser Domain beantwortet werden sollen.
DNS-Records in Zonendateien
Das DNS (Domain Name System) ermöglicht die Zuordnung eines Domainnamens zu Netzwerkressourcen. Bei einem Provider werden nach dem Erwerb einer Domain wichtige DNS-Records – also DNS-Einträge – auf den Nameservern in Zonendateien durchgeführt. Durch sie wird eine Domain in eine IP-Adresse oder eine IP-Adresse in eine Domain übersetzt. Das gleiche wird ebenfalls durch Administratoren auf Nameservern in Unternehmen durchgeführt.
Eine Zonendatei umfasst alle relevanten Einträge einer Domain: z. B. A-, AAAA-, MX-, CNAME-, TXT-Records:
|
Typ |
Zweck |
Beispiel |
|
A |
IPv4-Adresse eines Hosts |
blog.domain.de à 192.0.2.123 |
|
AAAA |
IPv6-Adresse |
blog.domain.de à 2001:db8::1 |
|
MX |
Mailserver für Domain |
@ à mail.domain.de |
|
CNAME |
Alias für andere Subdomain/Domain |
www à domain.de |
|
TXT |
Freitext, z. b. SPF, DKIM, DMARC |
@ à v=spf1 include:mailserver.de -all |
|
SRV |
Service Records für spezielle Dienste |
_sip._tcp.domain.de à 5060 |
|
NS |
Angabe der autoritativen Nameserver einer Zone |
ns1.technik-kiste.de. |
In den Records befindet sich eine Time-to-Live (TTL) welche angibt, wie viele Sekunden ein Eintrag nach einer Abfrage im DNS-Cache zwischengespeichert werden darf. Die TTL kann für jeden Eintrag einzeln oder gesamthaft für alle Einträge angegeben werden.
Hinweis: Beachte das Änderungen an DNS-Records oft erst nach Minuten oder sogar Stunden wirksam werden, da diese zyklisch aktualisiert werden.
SOA-Records
Vor den RR (Resource Records) muss zwingend der SOA-Record stehen. Der „Start of Authority“-Record definiert grundlegende Verwaltungsinformationen für die Zone. Er enthält fest verbindliche Angaben:
@ IN SOA ns1.technik-kiste.de. hostmaster.technik-kiste.de. (
2025081301 ; Serial
3600 ; Refresh
900 ; Retry
1209600 ; Expire
86400 ; Minimum TTL
)
Felder im Detail:
- Zonenname (@): dabei handelt es sich um den Namen der Zone. Welcher aus einer Direktive ($ORIGIN) hergeleitet wird.
- Zonenklasse (IN): muss beim IP grundsätzlich auf IN für „Internet“ stehen.
- Record-Type (SOA): hiermit wird bekanntgegeben das es sich um den SOA-Record handelt.
- Primary Nameserver (ns1.technik-kiste.de.): Hauptverantwortlicher autoritativer Nameserver für die Zone.
- Responsible Person (hostmaster.technik-kiste.de.): Kontaktadresse des Administrators. Punkt statt @, da dieses in Zonendateien eine andere Bedeutung hat!
- Serial (2025081301): Versionsnummer der Zonendatei, oft YYYYMMDDlfd → wichtig für Secondary-Server-Sync.
- Refresh (3600): Intervall in Sekunden, nach dem Secondary-Nameserver die Zone neu abfragen.
- Retry (900): Wartezeit in Sekunden bis zum erneuten Versuch nach fehlgeschlagener Abfrage.
- Expire (1209600): Wie lange ein Secondary die Zone ohne Updates in Sekunden als gültig betrachtet.
- Minimum TTL (86400): Standard-Zeit in Sekunden für Caching von Einträgen, wenn nicht anders angegeben.
Hinweis: Es gibt für die einzelnen Angaben im SOA eine RIPE-Recommendation 203, welche unter https://www.ripe.net/media/documents/ripe-203.pdf (externer Link) bezogen werden kann.
Direktiven (Directives)
Am Anfang der Zonendatei, also vor dem SOA befinden sich Direktiven, um allgemeine Werte zu definieren. Zu ihnen zählen als wichtigste:
- $ORIGIN: ein Platzhalter für den Zonen-Ursprung (engl. origin). Das bedeutet: Wo immer du in der Datei ein @ siehst, wird es durch den in der Zonendatei gesetzten $ORIGIN-Wert ersetzt.
- $TTL: legt fest, wie lange DNS-Resolver die Einträge aus einer Zonendatei im Cache behalten, bevor sie erneut den autoritativen Nameserver befragen. Es müssen durch diese Direktive in den Host-Zeilen nicht einzelne TTL-Werte angegeben werden.
Beispiel einer Forward-Zonendatei
Im Folgenden werden die einzelnen zuvor besprochenen Inhalte von Zonendateien zu einer beispielhaften Forward-Zonendatei zusammengefügt:
$ORIGIN technik-kiste.de.
$TTL 3600 ; Standard-TTL für alle folgenden Records (1h)
@ IN SOA ns1.technik-kiste.de. hostmaster.technik-kiste.de. (
2025081301 ; Serial: YYYYMMDDNN
3600 ; Refresh: 1h
900 ; Retry: 15m
1209600 ; Expire: 14d
300 ; Minimum/Negative TTL: 5m (RFC 2308)
)
; ---- Autoritative Nameserver ----
IN NS ns1.technik-kiste.de.
IN NS ns2.technik-kiste.de.
; ---- Nameserver-Hosts ----
ns1 IN A 192.0.2.53
ns1 IN AAAA 2001:db8::53
ns2 IN A 192.0.2.54
ns2 IN AAAA 2001:db8::54
; ---- A/AAAA-Records (Hosts) ----
@ IN A 192.0.2.10
@ IN AAAA 2001:db8::10
www IN CNAME @
api IN A 192.0.2.20
api IN AAAA 2001:db8::20
mail IN A 192.0.2.25
mail IN AAAA 2001:db8::25
; ---- Mail-Routing ----
@ IN MX 10 mail.technik-kiste.de.
@ IN TXT "v=spf1 a mx -all"
; ---- DNSSEC-/Mail-/Verifizierungs-TXT-Beispiele ----
_dmarc IN TXT "v=DMARC1; p=quarantine; rua=mailto:
default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..." ; gekürzt
; ---- Dienste (SRV) ----
_sip._tcp IN SRV 10 60 5060 sip.technik-kiste.de.
sip IN A 192.0.2.30
; ---- CAA (Zertifikatsaussteller-Policy) ----
@ IN CAA 0 issue "letsencrypt.org"
@ IN CAA 0 iodef "mailto:
; ---- Wildcard-Beispiel ----
*.dev IN A 192.0.2.200
*.dev IN AAAA 2001:db8::200
Forward vs. Reverse Lookup im DNS
Das Domain Name System kann Anfragen in zwei Richtungen auflösen: vom Hostnamen zur IP-Adresse (Forward Lookup) und von der IP-Adresse zum Hostnamen (Reverse Lookup). Beide Verfahren nutzen DNS, erfüllen aber unterschiedliche Zwecke und verwenden unterschiedliche Zonendateien.
📤 Forward Lookup (Namensauflösung)
- Zweck: Wandelt einen vollqualifizierten Domainnamen (FQDN) wie www.technik-kiste.de in eine IP-Adresse um.
- Verwendung: Basis für das Surfen im Internet, API‑Zugriffe, E‑Mail‑Routing – fast jede netzwerkbasierte Kommunikation beginnt mit einem Forward Lookup.
- Umsetzung:
- Anfragen landen im Normalfall beim zuständigen autoritativen Nameserver für die Domain.
- Typische Resource Records: A (IPv4), AAAA (IPv6), ggf. CNAME.
Beispiel:
www.technik-kiste.de. IN A 192.0.2.10
📥 Reverse Lookup (Rückwärtsauflösung)
- Zweck: Ermittelt zu einer IP-Adresse den zugehörigen Hostnamen.
- Verwendung: Wichtige Rolle bei Sicherheitsprüfungen, Spam‑Filterung (Mailserver verlangen oft eine gültige Reverse-Auflösung), Logging, Fehlersuche.
- Besonderheit: Nutzt spezielle Reverse‑Zonen:
- IPv4: unterhalb von in-addr.arpa
- IPv6: unterhalb von ip6.arpa (nibble‑weise, hexadezimal – weiter unten mehr dazu)
- Schreibweise: Es werden alle Adressen rückwärts geschrieben
- Typischer Resource Record: PTR (Pointer Record)
Beispiel IPv4:
10.2.0.192.in-addr.arpa. IN PTR www.technik-kiste.de.
Diese PTR‑Antwort verweist auf denselben Host, zu dem auch ein Forward Lookup existiert. Daher muss dieser konsistent - also fehlerfrei - sein!
Gegenüberstellung
|
Kriterium |
Forward Lookup |
Reverse Lookup |
|
Ausgangsdaten |
Hostname (FQDN) |
IP-Adresse |
|
Zielinformation |
IP-Adresse |
Hostname |
|
Typische Records |
A, AAAA, CNAME |
PTR |
|
Zone |
reguläre Zone, z. B. technik-kiste.de. |
Reverse‑Zone, z. B. 2.0.192.in-addr.arpa. |
|
Hauptanwendungsfall |
Webzugriffe, E‑Mails, APIs |
Logging, Sicherheitsprüfungen, Mailserver |
Achtung: Das Reverse Lookup ist fest mit dem Forward Lookup verknüpft.
Beispiel Reverse-Zonendatei IPv4
In diesem Beispiel findest du eine vollständige Beispiel‑Reverse‑Lookup‑Zonendatei für IPv4, so wie sie auf einem autoritativen Nameserver (z. B. mit BIND) angelegt wird. Ich nehme hier konkret als Beispiel das Netz 192.0.2.0/24 (ein Testnetz aus RFC 5737), das auf beispielhafte Hosts zeigt.
$ORIGIN 2.0.192.in-addr.arpa. ; Basisdomain für Reverse-Lookups
$TTL 3600 ; Standard-TTL 1h
@ IN SOA ns1.technik-kiste.de. hostmaster.technik-kiste.de. (
2025081301 ; Serial: YYYYMMDDNN
3600 ; Refresh: 1h
900 ; Retry: 15m
1209600 ; Expire: 14d
300 ) ; Negative TTL: 5m
IN NS ns1.technik-kiste.de.
IN NS ns2.technik-kiste.de.
; ---- PTR-Einträge für wichtige Hosts ----
1 IN PTR router.technik-kiste.de.
10 IN PTR www.technik-kiste.de.
20 IN PTR api.technik-kiste.de.
25 IN PTR mail.technik-kiste.de.
30 IN PTR sip.technik-kiste.de.
; ---- Optional: zusätzliche Hosts ----
50 IN PTR backup1.technik-kiste.de.
51 IN PTR backup2.technik-kiste.de.
100 IN PTR testvm1.technik-kiste.de.
101 IN PTR testvm2.technik-kiste.de.
Beachte bei den Adressen, das bereits zu Beginn die Zone festgelegt wurde und sich alle Adressen auf die IPv4-Adresse 192.0.2.0 beziehen. Es muss dann lediglich das letzte Oktett innerhalb der Host-Zeilen (RR) angegeben werden. Ohne diesen „Trick“ würde die Datei wie folgt aussehen:
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 3600
@ IN SOA ns1.technik-kiste.de. hostmaster.technik-kiste.de. (
2025081301 ; Serial: YYYYMMDDNN
3600 ; Refresh: 1h
900 ; Retry: 15m
1209600 ; Expire: 14d
300 ) ; Negative TTL: 5m
IN NS ns1.technik-kiste.de.
IN NS ns2.technik-kiste.de.
; ---- PTR-Einträge mit vollständigem Namen ----
1.2.0.192.in-addr.arpa. IN PTR router.technik-kiste.de.
10.2.0.192.in-addr.arpa. IN PTR www.technik-kiste.de.
20.2.0.192.in-addr.arpa. IN PTR api.technik-kiste.de.
25.2.0.192.in-addr.arpa. IN PTR mail.technik-kiste.de.
30.2.0.192.in-addr.arpa. IN PTR sip.technik-kiste.de.
; ---- Weitere Hosts ----
50.2.0.192.in-addr.arpa. IN PTR backup1.technik-kiste.de.
51.2.0.192.in-addr.arpa. IN PTR backup2.technik-kiste.de.
100.2.0.192.in-addr.arpa. IN PTR testvm1.technik-kiste.de.
101.2.0.192.in-addr.arpa. IN PTR testvm2.technik-kiste.de.
Welche Variante der Adressnotation verwendet wird obliegt den Administratoren. Bei ersterer ist die Gefahr von Tippfehlern jedoch deutlich geringer.
Beispiel Reverse-Zonendatei IPv6
In diesem Beispiel findest du eine vollständige Beispiel‑Reverse‑Lookup‑Zonendatei für IPv6, wie sie in BIND oder einem ähnlichen Nameserver hinterlegt werden könnte. Ich nutze dafür ein fiktives /64‑Netz im Dokumentationsbereich 2001:db8:abcd:0012::/64 (vgl. RFC 3849), damit die Struktur klar wird.
Bei der Notation von IPv6-Adressen muss beachtet werden, dass jede einzelne Hexadezimalziffer der Adresse nibble-weise (4 Bit = 1 Nibble) und umgedreht dargestellt werden muss. Ebenfalls sind keine Doppelpunkt ( : ) erlaubt, wodurch jedes Nibble durch einen Punkt ( . ) vom nächsten getrennt werden muss.
Das „nibble‑weise“ Vorgehen ist notwendig, damit sich jede Adresse exakt und eindeutig in den hierarchischen Aufbau des DNS einfügt.
$ORIGIN 2.1.0.0.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa.
$TTL 3600
@ IN SOA ns1.technik-kiste.de. hostmaster.technik-kiste.de. (
2025081301 ; Serial: YYYYMMDDNN
3600 ; Refresh: 1h
900 ; Retry: 15m
1209600 ; Expire: 14d
300 ) ; Negative TTL: 5m
IN NS ns1.technik-kiste.de.
IN NS ns2.technik-kiste.de.
; ---- PTR-Einträge für ausgewählte IPv6-Adressen ----
; Adresse: 2001:db8:abcd:12::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR router.technik-kiste.de.
; Adresse: 2001:db8:abcd:12::10
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR www.technik-kiste.de.
; Adresse: 2001:db8:abcd:12::20
0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR api.technik-kiste.de.
; Adresse: 2001:db8:abcd:12::25
5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR mail.technik-kiste.de.
; Adresse: 2001:db8:abcd:12::30
0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR sip.technik-kiste.de.
Funktionsweise eines Nameservers
Bei einer DNS-Abfrage sendet der Client eine Anfrage, die über rekursive Resolver bis zum autoritativen Nameserver geleitet wird.
Ein Nameserver antwortet mit dem gewünschten Eintrag z. B. einem A-Record (domain.de → 192.0.2.1). Daraufhin kann der Client die gewünschte Ressource anfordern und darstellen.
Funktionsweise des DNS. Quelle: Technik-Kiste.de
Typen von Nameservern
Im DNS kommen unterschiedliche Typen von Nameservern zum Einsatz:
|
Typ |
Beschreibung |
|
Autoritativer Nameserver |
Er ist verantwortlich für eine Zone und verteilt daher seine Daten „gesichert“. Jede Zone muss diesen Nameserver besitzen, daher wird er als „primary Nameserver“ einer Zone bezeichnet. Er wird durch „secondary Nameserver“ innerhalb derselben Zone unterstützt. Dies verbessert die Lastverteilung und Redundanz im DNS. |
|
Nicht-autoritativer Nameserver |
Die beziehen ihre Informationen über andere Nameserver aus anderen Zonen. Daher gelten ihre Informationen als „nicht gesichert“. In seinem DNS-Cache speichert der nicht-autoritative Nameserver bereits aufgelöste Daten ab, bis ihre TTL abgelaufen ist. Solange die TTL nicht abgelaufen ist, besteht daher die Gefahr von veralteten Einträgen. |
|
Resolver |
Hierbei handelt es sich um eine Software-Komponente auf einem Computer, die bei Bedarf entweder rekursiv oder iterativ bei Nameservern die Auflösung anfragt. Iterativ: Der Resolver erhält entweder den gewünschten Record oder einen Verweis auf den nächsten Nameserver, bei dem der Resolver selbstständig anfragt. Dies führt er so lange durch, bis er eine positive oder negative Antwort erhält. Rekursiv: Im rekursiven Modus ist die Namensauflösung dem angefragten Nameserver überlassen. |
|
Caching-Nameserver |
Dieser Nameserver ist für keine Zone verantwortlich und leitet die Anfragen ausschließlich an weitere Nameserver weiter. Dieser Typ wird oft bei heutigen Router-Modellen in kleinen Netzwerken verwendet. |
RFC
Das DNS basiert auf den beiden RFC 1034 und 1035. Zusätzlich haben sich eine Vielzahl wichtiger oder interessanter RFC in diesem Bereich aufgetan. Im Folgenden erhältst du einen Überblick über diese:
|
RFC-Nummer |
Titel |
|
1034 |
Domain Names – Concepts and Facilities |
|
1035 |
Domain Names – Implementation and Specification |
|
1101 |
DNS Encoding of Network Names and Other Types |
|
1183 |
New DNS RR Definitions |
|
1348 |
DNS NSAP RRs |
|
1876 |
A Means for Expressing Location Information in the DNS |
|
1982 |
Serial Number Arithmetic |
|
1995 |
Incremental Zone Transfer in DNS |
|
1996 |
A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) |
|
2065 |
Domain Name System Security Extensions |
|
2136 |
Dynamic Updates in the Domain Name System (DNS UPDATE) |
|
2137 |
Secure Domain Name System Dynamic Update |
|
2181 |
Clarifications to the DNS Specification |
|
2308 |
Negative Caching of DNS Queries (DNS NCACHE) |
|
2535 |
Domain Name System Security Extensions |
|
2673 |
Binary Labels in the Domain Name System |
|
2845 |
Secret Key Transaction Authentication for DNS (TSIG) |
|
3425 |
Obsoleting IQUERY |
|
3658 |
Delegation Signer (DS) Resource Record |
|
4033 |
DNS Security Introduction and Requirements |
|
4034 |
Resource Records for the DNS Security Extensions |
|
4035 |
Protocol Modifications for the DNS Security Extensions |
|
4343 |
DNS Case Insensitivity Clarification |
|
4592 |
The Role of Wildcards in the Domain Name System |
|
5936 |
DNS Zone Transfer Protocol (AXFR) |
|
5966 |
DNS Transport over TCP – Implementation Requirements |
|
6604 |
xNAME RRs: Additional Alternative Naming Mechanism |
|
7766 |
DNS Transport over TCP – Implementation Requirements (Update) |
|
8020 |
NXDOMAIN: There Really Is Nothing Underneath |
|
8482 |
Minimal Responses to DNS Queries That Have QTYPE=ANY |
|
8490 |
DNS Root Name Service Protocol and Deployment Requirements |
|
8767 |
Serving Stale Data to Improve DNS Resilience |
|
9471 |
DNS Catalog Zones |
|
9619 |
DNS Resolver Information |