# 7.11 DNS-Leistung und fehlerhafte Reverse-Lookups

> **Kurz erklärt**
>
> Eine DNS-Abfrage kann grundsätzlich funktionieren und trotzdem langsam sein. Ebenso beweist ein fehlender Reverse-Lookup nicht automatisch, dass die normale Namensauflösung gestört ist.
>
> Für eine saubere Diagnose müssen Abfragerichtung, verwendeter DNS-Server, Antwortcode, Antwortzeit, Cachezustand, Rekursion, Weiterleitung, Transportweg und Zonenverantwortung getrennt untersucht werden.

---

**7.11.1 Ziel der Diagnose**

Bei DNS-Leistungsproblemen müssen folgende Fragen beantwortet werden:

- Ist nur eine Anwendung oder das gesamte System betroffen?
- Betrifft der Fehler Vorwärts- oder Rückwärtsauflösungen?
- Wird tatsächlich der vorgesehene DNS-Server verwendet?
- Antwortet der DNS-Server gar nicht, langsam oder mit einem Fehlercode?
- Ist der DNS-Server für die abgefragte Zone autoritativ?
- Stammt die Antwort aus einem Client-, Anwendungs- oder Servercache?
- Entsteht die Verzögerung lokal, im Netzwerk oder bei einem nachgelagerten DNS-Server?
- Existiert die benötigte Reverse-Lookup-Zone?
- Ist der PTR-Eintrag vorhanden und korrekt?
- Stimmen Vorwärts- und Rückwärtsauflösung überein?
- Betrifft der Fehler nur einen DNS-Server oder alle vorgesehenen DNS-Server?
- Liegt eine fehlerhafte Delegation, Weiterleitung oder dynamische Aktualisierung vor?
- Verwendet die Anwendung klassisches DNS, DoH, DoT oder einen eigenen Resolver?

Ziel ist nicht nur eine erfolgreiche Einzelabfrage, sondern eine reproduzierbare und ausreichend schnelle Namensauflösung über den vorgesehenen DNS-Pfad.

---

**7.11.2 Typische Störungsbilder**

- Anwendungen starten oder verbinden sich mit deutlicher Verzögerung.
- Verbindungen über IP-Adresse funktionieren schneller als über den Hostnamen.
- Eine Anwendung wartet vor der eigentlichen Anmeldung mehrere Sekunden.
- Protokolle zeigen nur IP-Adressen statt Hostnamen.
- `nslookup` zeigt als DNS-Server `Unknown` oder `UnKnown`.
- Vorwärtsauflösung funktioniert, Rückwärtsauflösung jedoch nicht.
- Eine IP-Adresse liefert einen falschen oder veralteten Hostnamen.
- Derselbe Name liefert abhängig vom DNS-Server unterschiedliche Antworten.
- Die erste Abfrage ist langsam, weitere Abfragen sind schnell.
- Abfragen interner Namen funktionieren nur im Firmennetz oder VPN.
- Externe Namen sind langsam, interne Namen dagegen schnell.
- Nur Abfragen bestimmter Zonen sind betroffen.
- Kleine DNS-Antworten funktionieren, größere Antworten schlagen fehl.
- Abfragen über UDP schlagen fehl, über TCP funktionieren sie.
- Abfragen enden mit `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder einem Timeout.
- Mailserver lehnen Verbindungen wegen fehlendem oder unpassendem Reverse-DNS ab.
- Überwachungssysteme erzeugen falsche Zuordnungen zwischen IP-Adresse und Hostname.
- Nach einer IP-Adressänderung bleibt der alte PTR-Eintrag bestehen.
- Neue Geräte erhalten einen A-Eintrag, aber keinen PTR-Eintrag.
- Browser und Betriebssystem liefern für denselben Namen unterschiedliche Ergebnisse.
- DNS funktioniert ohne VPN, aber nicht über den VPN-Tunnel.
- `nslookup` funktioniert, eine Anwendung mit NRPT-Auswertung jedoch nicht – oder umgekehrt.

---

**7.11.3 Vorwärts- und Rückwärtsauflösung unterscheiden**

| Abfragerichtung | Eingabe | Gesuchter Datensatz | Ergebnis |
|---|---|---|---|
| Vorwärtsauflösung IPv4 | Hostname | `A` | IPv4-Adresse |
| Vorwärtsauflösung IPv6 | Hostname | `AAAA` | IPv6-Adresse |
| Rückwärtsauflösung IPv4 | IPv4-Adresse | `PTR` unter `in-addr.arpa` | Hostname |
| Rückwärtsauflösung IPv6 | IPv6-Adresse | `PTR` unter `ip6.arpa` | Hostname |

Beispiel:

```text
host25.example.test → 192.0.2.25
```

Dies ist eine Vorwärtsauflösung über einen A-Eintrag.

```text
192.0.2.25 → host25.example.test
```

Dies ist eine Rückwärtsauflösung über einen PTR-Eintrag.

A-, AAAA- und PTR-Einträge sind getrennte DNS-Datensätze in unterschiedlichen Zonen. Ein vorhandener A- oder AAAA-Eintrag erzeugt deshalb nicht automatisch einen PTR-Eintrag, sofern kein entsprechend konfigurierter Aktualisierungsprozess vorhanden ist.

---

**7.11.4 Aufbau einer IPv4-Rückwärtsauflösung**

Für IPv4 werden die Oktette der Adresse umgekehrt und mit `in-addr.arpa` ergänzt.

Beispiel:

```text
192.0.2.25
```

Daraus entsteht der Abfragename:

```text
25.2.0.192.in-addr.arpa.
```

Der zugehörige PTR-Eintrag kann auf folgenden Namen zeigen:

```text
host25.example.test.
```

Für das Netz `192.0.2.0/24` lautet die typische Reverse-Lookup-Zone:

```text
2.0.192.in-addr.arpa
```

Der Knoten für die Adresse `192.0.2.25` lautet innerhalb dieser Zone:

```text
25
```

Bei Adressbereichen, die nicht an einer Oktettgrenze delegiert werden, kann eine klassenlose Delegation nach RFC 2317 erforderlich sein. Der Zonenaufbau darf dann nicht allein aus der Subnetzmaske abgeleitet werden, sondern muss mit der tatsächlichen Delegation des Adressbereichs übereinstimmen.

---

**7.11.5 Aufbau einer IPv6-Rückwärtsauflösung**

IPv6-Rückwärtsauflösungen verwenden die Zone `ip6.arpa`.

Dabei wird:

1. die IPv6-Adresse vollständig ausgeschrieben;
2. jede Hexadezimalstelle einzeln betrachtet;
3. die Reihenfolge aller Hexadezimalstellen umgekehrt;
4. zwischen jeder Stelle ein Punkt eingefügt;
5. `ip6.arpa` angehängt.

Die Delegation erfolgt auf Basis einzelner Hexadezimalstellen, sogenannter Nibbles. Eine IPv6-Reverse-Zone muss deshalb anhand des tatsächlich delegierten IPv6-Präfixes erstellt werden.

IPv6-Reverse-Namen dürfen nicht durch einfaches Umkehren der durch Doppelpunkte getrennten Adressblöcke gebildet werden.

---

**7.11.6 Bedeutung eines fehlenden Reverse-Lookups**

Ein fehlender PTR-Eintrag bedeutet zunächst nur, dass für die IP-Adresse kein entsprechender Name über Reverse-DNS ermittelt werden konnte.

Das beweist nicht automatisch:

- dass die Vorwärtsauflösung fehlerhaft ist;
- dass der Host nicht erreichbar ist;
- dass der Hostname nicht existiert;
- dass der DNS-Server vollständig ausgefallen ist;
- dass Active Directory nicht funktioniert;
- dass die IP-Adresse ungültig ist.

Reverse-Lookups werden unter anderem verwendet von:

- Diagnosewerkzeugen;
- Protokollierungs- und Überwachungssystemen;
- Mailservern;
- Sicherheitsprodukten;
- Inventarisierungsprogrammen;
- Netzwerkdiensten mit Hostnamenprüfung;
- Anwendungen, die eingehende IP-Adressen in Namen auflösen;
- Administratoren bei der Auswertung von Verbindungen.

Eine Anwendung kann bei einem fehlenden PTR-Eintrag ohne Verzögerung weiterarbeiten. Eine deutliche Verzögerung entsteht eher dann, wenn die Reverse-Abfrage nicht eindeutig negativ beantwortet wird, sondern in Timeouts, fehlerhaften Delegationen oder nicht erreichbaren DNS-Servern endet.

---

**7.11.7 `nslookup` zeigt den DNS-Server als „Unknown“**

Eine typische Ausgabe kann folgendermaßen aussehen:

```text
Server:  UnKnown
Address: 192.0.2.53
```

Das bedeutet häufig, dass für die IP-Adresse des verwendeten DNS-Servers kein auflösbarer PTR-Eintrag vorhanden ist.

Diese Meldung beweist nicht, dass der DNS-Server keine anderen Anfragen beantworten kann.

Zur Abgrenzung müssen kontrollierte Abfragen durchgeführt werden:

```cmd
nslookup host25.example.test 192.0.2.53
```

```cmd
nslookup 192.0.2.25 192.0.2.53
```

PTR des DNS-Servers selbst prüfen:

```cmd
nslookup 192.0.2.53 192.0.2.53
```

Wenn die erste Abfrage erfolgreich ist, funktioniert die getestete Vorwärtsauflösung trotz der Anzeige `Unknown`. Der fehlende PTR-Eintrag des DNS-Servers bleibt dennoch ein zu prüfender Konfigurationsbefund.

---

**7.11.8 DNS-Antworten richtig einordnen**

| Ergebnis | Bedeutung | Einordnung |
|---|---|---|
| `NOERROR` mit Antwort | Abfrage wurde erfolgreich beantwortet | Datensatz und Inhalt prüfen |
| `NOERROR` ohne gesuchten Datensatz | Name kann existieren, der angefragte Datensatztyp fehlt | häufig als `NODATA` bezeichnet |
| `NXDOMAIN` | abgefragter DNS-Name existiert laut DNS-Antwort nicht | Zone, Name und negative Zwischenspeicherung prüfen |
| `SERVFAIL` | Server konnte keine verwertbare Antwort erzeugen | Weiterleitung, Delegation, DNSSEC und Serverprotokolle prüfen |
| `REFUSED` | Server lehnt die Abfrage aufgrund seiner Konfiguration oder Richtlinie ab | Rekursion, ACL, Richtlinie und Abfragequelle prüfen |
| `FORMERR` | DNS-Nachricht konnte nicht korrekt verarbeitet werden | Client, Server, Netzwerkgerät und Paketformat prüfen |
| Timeout | innerhalb der Wartezeit kam keine verwertbare Antwort | Netzwerk, Transport, Serverlast und nachgelagerte Server prüfen |
| Antwort mit `TC` | UDP-Antwort wurde abgeschnitten | erneuter Versuch über TCP erforderlich |
| falsche Adresse oder falscher PTR | DNS antwortet, aber mit unerwarteten Daten | Zone, Replikation, Cache und Datensatz prüfen |

Ein Timeout ist kein DNS-Antwortcode. Er bedeutet, dass der Client innerhalb seiner Wartezeit keine verwendbare DNS-Antwort erhalten hat.

---

**7.11.9 Ausgangszustand dokumentieren**

Vor Änderungen sind mindestens folgende Informationen zu erfassen:

- betroffener Client;
- betroffene Anwendung;
- Datum und genaue Uhrzeit;
- Quell-IP-Adresse;
- verwendete Netzwerkschnittstelle;
- VPN-Zustand;
- konfigurierte DNS-Server;
- DNS-Suffixe und Suchliste;
- abgefragter Name beziehungsweise abgefragte IP-Adresse;
- Abfragetyp;
- verwendeter DNS-Server;
- vollständige Antwort;
- Antwortcode;
- Antwortzeit;
- autoritative oder rekursive Antwort;
- Verhalten bei Wiederholung;
- Verhalten über einen alternativen DNS-Server;
- Verhalten bei direkter IP-Verbindung;
- vorhandene Client- und Servercaches;
- vorhandene PTR-, A-, AAAA-, CNAME- oder SRV-Einträge;
- letzte DNS-, DHCP- oder IP-Adressänderung;
- verwendeter DNS-Transport.

DNS-Caches dürfen nicht gelöscht werden, bevor der ursprüngliche Cachezustand und die fehlerhafte Antwort dokumentiert wurden.

---

**7.11.10 Verwendete DNS-Konfiguration prüfen**

**Windows**

```cmd
ipconfig /all
```

```powershell
Get-DnsClientServerAddress
```

```powershell
Get-DnsClient
```

**Linux**

```bash
cat /etc/resolv.conf
```

Bei Systemen mit `systemd-resolved` zusätzlich:

```bash
resolvectl status
```

**macOS**

```bash
scutil --dns
```

Zu prüfen sind:

- welche DNS-Server tatsächlich eingetragen sind;
- welche Schnittstelle die DNS-Server bereitstellt;
- ob VPN oder Sicherheitssoftware eigene Resolver einbindet;
- ob interne DNS-Suffixe vorhanden sind;
- ob eine Suchliste zusätzliche Abfragen erzeugt;
- ob IPv4- und IPv6-Resolver unterschiedlich konfiguriert sind;
- ob Split-DNS oder eine namensbasierte Weiterleitung aktiv ist;
- ob öffentliche DNS-Server für interne Unternehmensnamen verwendet werden;
- ob die Reihenfolge der DNS-Server dem vorgesehenen Design entspricht.

Die Datei `/etc/resolv.conf` kann bei dynamisch verwalteten Linux-Systemen nur auf einen lokalen Stub-Resolver verweisen. Bei `systemd-resolved` muss deshalb zusätzlich dessen tatsächliche Schnittstellenkonfiguration geprüft werden.

---

**7.11.11 Lokale Namensquellen und Resolverpfad berücksichtigen**

Eine Anwendung muss nicht zwingend direkt den konfigurierten DNS-Server abfragen. Je nach Betriebssystem und Anwendung können vorher oder zusätzlich verwendet werden:

- lokale Hosts-Datei;
- DNS-Clientcache;
- anwendungseigener DNS-Cache;
- Browsercache;
- lokaler Stub-Resolver;
- VPN-Resolver;
- Name Resolution Policy Table unter Windows;
- mDNS;
- LLMNR;
- NetBIOS-Namensauflösung;
- Proxy;
- DNS over HTTPS;
- DNS over TLS;
- Container- oder Cluster-DNS;
- Sicherheits- beziehungsweise Filtersoftware.

Hosts-Dateien:

| Betriebssystem | Pfad |
|---|---|
| Windows | `C:\Windows\System32\drivers\etc\hosts` |
| Linux | `/etc/hosts` |
| macOS | `/etc/hosts` |

Eine erfolgreiche Anwendungssuche beweist nicht, dass DNS verwendet wurde. Umgekehrt beweist eine erfolgreiche direkte DNS-Abfrage nicht, dass die Anwendung denselben Resolverpfad benutzt.

---

**7.11.12 Split-DNS, VPN und NRPT prüfen**

Bei Split-DNS kann derselbe Name abhängig vom verwendeten Netzwerk oder DNS-Server unterschiedliche Antworten liefern.

Beispiel:

```text
app.example.test → interne IP über Unternehmens-DNS
app.example.test → öffentliche IP über öffentlichen DNS
```

Unter Windows können VPN-Profile über die Name Resolution Policy Table festlegen, welche Namensräume an bestimmte DNS-Server gesendet werden.

Wirksame NRPT-Richtlinien anzeigen:

```powershell
Get-DnsClientNrptPolicy
```

Konfigurierte NRPT-Regeln anzeigen:

```powershell
Get-DnsClientNrptRule
```

Zu prüfen sind:

- welcher Namensraum von einer Regel erfasst wird;
- welcher DNS-Server für diesen Namensraum vorgesehen ist;
- ob die Regel nur bei aktivem VPN gilt;
- ob eine allgemeinere Regel eine spezifische Regel beeinflusst;
- ob interne und öffentliche Zone denselben Namen unterschiedlich beantworten;
- ob der VPN-Tunnel die benötigten DNS-Server erreicht;
- ob eine Anwendung die Windows-DNS-API verwendet.

`nslookup` verwendet für solche Tests nicht zwingend denselben Windows-Resolverpfad wie Anwendungen, die die Windows-DNS-API und NRPT nutzen. Für die Prüfung von NRPT sollte deshalb zusätzlich `Resolve-DnsName` verwendet werden.

---

**7.11.13 Verschlüsseltes DNS mit DoH und DoT abgrenzen**

DNS over HTTPS und DNS over TLS verändern den Transportweg der DNS-Abfrage.

Dadurch können klassische Tests über UDP- oder TCP-Port `53` erfolgreich sein, obwohl der verschlüsselte DNS-Pfad fehlschlägt – oder umgekehrt.

Windows-DNS-Clientzustand anzeigen:

```cmd
netsh dnsclient show state
```

Globale Einstellungen anzeigen:

```cmd
netsh dnsclient show global
```

Konfigurierte verschlüsselte DNS-Server anzeigen:

```cmd
netsh dnsclient show encryption
```

Zu prüfen sind:

- verwendet das Betriebssystem DoH oder DoT?
- verwendet nur der Browser einen eigenen DoH-Resolver?
- stimmt die URI beziehungsweise der TLS-Hostname?
- ist das Zertifikat gültig und vertrauenswürdig?
- stimmt der Zertifikatsname mit dem DNS-Endpunkt überein?
- ist der verschlüsselte Port erreichbar?
- ist ein Fallback auf unverschlüsseltes DNS erlaubt?
- umgeht die Anwendung den Unternehmens-DNS-Server?
- kann der verschlüsselte Resolver interne Zonen auflösen?
- unterscheiden sich Antworten zwischen klassischem und verschlüsseltem DNS?

Für die DNS-Serverrolle unterstützt Microsoft DoH ab Windows Server 2025 mit dem in der Microsoft-Bereitstellungsdokumentation genannten Sicherheitsupdate KB5094125 vom Juni 2026 oder einem späteren Update.

Serverkonfiguration auf einem unterstützten System anzeigen:

```powershell
Get-DnsServerEncryptionProtocol
```

DoH schützt den Transport zwischen DoH-Client und DNS-Server. Nachgelagerte Abfragen an Forwarder oder autoritative DNS-Server, Zonentransfers und dynamische Updates werden dadurch nicht automatisch verschlüsselt.

DoH und DNSSEC erfüllen unterschiedliche Aufgaben:

- DoH verschlüsselt den Transportweg.
- DNSSEC schützt die Authentizität und Integrität signierter DNS-Daten.

---

**7.11.14 Vorwärtsauflösung gezielt testen**

**Windows PowerShell**

```powershell
Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly
```

AAAA-Eintrag:

```powershell
Resolve-DnsName `
  -Name "host25.example.test" `
  -Type AAAA `
  -Server "192.0.2.53" `
  -DnsOnly
```

**Windows Eingabeaufforderung**

```cmd
nslookup host25.example.test 192.0.2.53
```

**Linux und macOS**

```bash
dig @192.0.2.53 host25.example.test A
```

```bash
dig @192.0.2.53 host25.example.test AAAA
```

Entscheidend ist, den DNS-Server ausdrücklich anzugeben. Andernfalls können unterschiedliche Resolver, VPN-Regeln oder Cachezustände zu nicht vergleichbaren Ergebnissen führen.

---

**7.11.15 Rückwärtsauflösung gezielt testen**

**Windows PowerShell**

```powershell
Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly
```

**Windows Eingabeaufforderung**

```cmd
nslookup 192.0.2.25 192.0.2.53
```

**Linux und macOS**

```bash
dig @192.0.2.53 -x 192.0.2.25
```

Kompakte Ausgabe mit Antwort und Statistik:

```bash
dig @192.0.2.53 -x 192.0.2.25 +noall +answer +comments +stats
```

Direkte Abfrage des vollständigen Reverse-Namens:

```bash
dig @192.0.2.53 25.2.0.192.in-addr.arpa PTR
```

Zu dokumentieren sind:

- Status beziehungsweise Antwortcode;
- PTR-Zielname;
- TTL;
- autoritative Kennzeichnung;
- antwortender DNS-Server;
- Antwortzeit;
- Verhalten bei wiederholter Abfrage.

---

**7.11.16 A-, AAAA-, CNAME-, PTR- und SRV-Probleme abgrenzen**

| Datensatz | Aufgabe | Typischer Fehler |
|---|---|---|
| `A` | Name zu IPv4-Adresse | falsche oder veraltete IPv4-Adresse |
| `AAAA` | Name zu IPv6-Adresse | falsche oder nicht erreichbare IPv6-Adresse |
| `CNAME` | Alias zu anderem DNS-Namen | fehlerhaftes Ziel oder lange Alias-Kette |
| `PTR` | IP-Adresse zu Name | fehlender, falscher oder veralteter Reverse-Eintrag |
| `SRV` | Dienst zu Zielhost und Port | falsches Ziel, falscher Port oder fehlender Zielhost |

CNAME prüfen:

```powershell
Resolve-DnsName `
  -Name "alias.example.test" `
  -Type CNAME `
  -Server "192.0.2.53" `
  -DnsOnly
```

SRV prüfen:

```powershell
Resolve-DnsName `
  -Name "_service._tcp.example.test" `
  -Type SRV `
  -Server "192.0.2.53" `
  -DnsOnly
```

Mit `dig`:

```bash
dig @192.0.2.53 alias.example.test CNAME
```

```bash
dig @192.0.2.53 _service._tcp.example.test SRV
```

Bei CNAME- und SRV-Datensätzen muss zusätzlich geprüft werden, ob der zurückgegebene Zielname über A oder AAAA auflösbar und anschließend über den angegebenen Dienstport erreichbar ist.

Ein erfolgreicher SRV-Lookup beweist nicht, dass der veröffentlichte Dienst erreichbar ist.

---

**7.11.17 Antwortzeit reproduzierbar messen**

Ein einzelner Messwert reicht nicht aus. Mindestens folgende Fälle müssen getrennt betrachtet werden:

- erste Abfrage;
- unmittelbar wiederholte Abfrage;
- Abfrage eines sicher vorhandenen Namens;
- Abfrage eines nicht vorhandenen Namens;
- Vorwärtsauflösung;
- Rückwärtsauflösung;
- interner Name;
- externer Name;
- primärer DNS-Server;
- alternativer DNS-Server;
- UDP;
- TCP;
- mit und ohne VPN.

**Linux und macOS**

`dig` zeigt die DNS-Abfragezeit als `Query time` an:

```bash
dig @192.0.2.53 host25.example.test A +stats
```

TCP erzwingen:

```bash
dig @192.0.2.53 host25.example.test A +tcp +stats
```

**Windows PowerShell**

```powershell
Measure-Command {
    Resolve-DnsName `
      -Name "host25.example.test" `
      -Type A `
      -Server "192.0.2.53" `
      -DnsOnly
}
```

TCP erzwingen:

```powershell
Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly
```

`Measure-Command` misst den gesamten PowerShell-Befehlsablauf und nicht ausschließlich die reine DNS-Übertragungszeit. Die Werte eignen sich deshalb vor allem zum kontrollierten Vergleich unter denselben Bedingungen.

---

**7.11.18 Kalte und zwischengespeicherte Abfragen unterscheiden**

Eine erste rekursive Abfrage kann langsamer sein, weil der DNS-Server weitere Server kontaktieren muss. Eine Wiederholung kann aus einem Cache beantwortet werden.

| Beobachtung | Mögliche Einordnung |
|---|---|
| erste Abfrage langsam, Wiederholung schnell | Server-, Client- oder Anwendungscache wirkt |
| jede Abfrage langsam | Netzwerk, Serverlast, Weiterleitung oder autoritativen Pfad prüfen |
| nur nicht vorhandene Namen langsam | negative Antworten, fehlerhafte Delegation oder Timeoutpfad prüfen |
| nur externe Namen langsam | Rekursion, Forwarder oder Internetpfad prüfen |
| nur interne Namen langsam | interne Zone, Delegation, AD-Replikation oder Standort prüfen |
| nur Reverse-Lookups langsam | Reverse-Zone, Delegation und PTR-Pfad prüfen |
| autoritativer Server schnell, rekursiver Server langsam | Rekursion, Cache oder Forwarder prüfen |
| UDP langsam oder fehlerhaft, TCP erfolgreich | Firewall, Fragmentierung, EDNS oder Netzwerkpfad prüfen |

Ein schneller Cachetreffer beweist nicht, dass der vollständige rekursive beziehungsweise autoritative Pfad funktioniert.

---

**7.11.19 Windows-DNS-Clientcache prüfen**

Cacheinhalt anzeigen:

```cmd
ipconfig /displaydns
```

Alternativ:

```powershell
Get-DnsClientCache
```

Zu prüfen sind:

- wurde der betroffene Name bereits zwischengespeichert?
- ist die Antwort positiv oder negativ?
- ist ein veralteter Wert vorhanden?
- stimmt der Datensatztyp?
- ist die verbleibende TTL plausibel?
- wurde die Antwort durch einen früheren VPN- oder Netzwerkzustand erzeugt?

Cache löschen:

```powershell
Clear-DnsClientCache
```

Alternativ:

```cmd
ipconfig /flushdns
```

Das Löschen des Clientcaches verändert den Ausgangszustand. Es darf erst nach Dokumentation und nur als kontrollierter Vergleich erfolgen.

---

**7.11.20 TTL und negative Zwischenspeicherung berücksichtigen**

Die TTL bestimmt, wie lange ein Datensatz zwischengespeichert werden darf.

Eine sehr niedrige TTL kann:

- die Anzahl der DNS-Abfragen erhöhen;
- rekursive DNS-Server stärker belasten;
- die Abhängigkeit von Netzwerk und autoritativen Servern erhöhen.

Eine sehr hohe TTL kann:

- veraltete Antworten länger wirksam halten;
- geplante Änderungen verzögern;
- eine Fehlerkorrektur erst nach Ablauf des Caches sichtbar machen.

Auch negative Antworten werden zwischengespeichert. Deshalb kann ein Name nach dem nachträglichen Anlegen des Datensatzes zunächst weiterhin als nicht vorhanden erscheinen.

Zu prüfen sind:

- TTL des A-, AAAA-, CNAME-, SRV- oder PTR-Eintrags;
- SOA-Daten der betroffenen Zone;
- negative Cachezeit;
- Clientcache;
- rekursiver Servercache;
- anwendungseigener Cache.

Caches dürfen nicht routinemäßig geleert werden, um eine falsche TTL- oder Zonenplanung dauerhaft zu umgehen.

---

**7.11.21 DNS über UDP und TCP abgrenzen**

Klassische DNS-Abfragen verwenden häufig UDP-Port `53`. TCP-Port `53` wird unter anderem benötigt:

- wenn eine UDP-Antwort abgeschnitten wurde;
- bei größeren DNS-Antworten;
- bei bestimmten DNSSEC-Antworten;
- für Zonentransfers;
- wenn der Client TCP ausdrücklich verwendet.

Windows-TCP-Test:

```powershell
Test-NetConnection "192.0.2.53" -Port 53
```

Dieser Befehl prüft ausschließlich TCP. Er beweist nicht, dass UDP-Port `53` funktioniert.

Ein echter UDP-DNS-Test erfolgt durch eine normale DNS-Abfrage:

```powershell
Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly
```

Vergleich über TCP:

```powershell
Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -TcpOnly
```

Wenn UDP-Abfragen scheitern und TCP-Abfragen funktionieren, sind unter anderem Firewallregeln, Paketverlust, Fragmentierung, EDNS-Verarbeitung, MTU und zwischengeschaltete Netzwerkgeräte zu prüfen.

---

**7.11.22 EDNS, MTU, Fragmentierung und DNSSEC prüfen**

EDNS ermöglicht unter anderem größere DNS-Antworten über UDP. Auf Netzwerkpfaden mit ungeeigneter MTU oder fehlerhafter Fragmentbehandlung können deshalb kleine Abfragen funktionieren, während größere Antworten ausfallen.

Typische Hinweise:

- einfache A-Abfrage funktioniert;
- DNSKEY-, TXT- oder umfangreiche AAAA-Antwort schlägt fehl;
- UDP-Abfrage endet im Timeout;
- dieselbe Abfrage funktioniert über TCP;
- Problem tritt nur über VPN, Tunnel oder bestimmte Firewalls auf;
- `SERVFAIL` tritt nur bei DNSSEC-signierten Zonen auf.

DNSSEC-Daten anfordern:

```powershell
Resolve-DnsName `
  -Name "example.com" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly `
  -DnssecOk
```

Mit `dig`:

```bash
dig @192.0.2.53 example.com A +dnssec
```

Vergleich über TCP:

```bash
dig @192.0.2.53 example.com A +dnssec +tcp
```

EDNS testweise unterdrücken:

```bash
dig @192.0.2.53 example.com A +noedns
```

Zu beachten ist:

- `+dnssec` beziehungsweise `-DnssecOk` fordert DNSSEC-bezogene Daten an;
- das Vorhandensein solcher Daten beweist nicht allein eine erfolgreiche Validierung;
- ein `SERVFAIL` kann durch eine fehlerhafte DNSSEC-Vertrauenskette entstehen;
- ein erfolgreicher TCP-Test bei fehlerhaftem UDP-Verhalten weist auf den Transportpfad, nicht automatisch auf falsche Zonendaten hin;
- EDNS darf nicht dauerhaft deaktiviert werden, nur um einen fehlerhaften Netzwerkpfad zu umgehen.

---

**7.11.23 Autoritative Antwort, Rekursion und Weiterleitung unterscheiden**

Ein DNS-Server kann eine Antwort liefern:

- aus einer lokal gehosteten autoritativen Zone;
- aus seinem Cache;
- über einen allgemeinen Forwarder;
- über einen bedingten Forwarder;
- über iterative Rekursion;
- über eine Stubzone;
- über eine richtliniengesteuerte Rekursionskonfiguration.

Für eine saubere Diagnose sind mindestens drei Ebenen zu vergleichen:

1. Abfrage über den vom Client verwendeten DNS-Server;
2. Abfrage über einen alternativen vorgesehenen DNS-Server;
3. Abfrage über den autoritativen DNS-Server der betroffenen Zone.

Wenn der autoritative Server schnell und korrekt antwortet, der rekursive Server jedoch langsam ist, liegt die Ursache wahrscheinlich bei Rekursion, Cache, Weiterleitung oder Delegationspfad.

---

**7.11.24 Delegation der Reverse-Zone prüfen**

Für eine Rückwärtsauflösung muss die DNS-Hierarchie auf den zuständigen autoritativen Server verweisen.

**Linux und macOS**

```bash
dig -x 192.0.2.25 +trace
```

Zuständige Nameserver der Reverse-Zone prüfen:

```bash
dig 2.0.192.in-addr.arpa NS
```

Zu prüfen sind:

- existiert die übergeordnete Reverse-Zone?
- wurde der richtige Adressbereich delegiert?
- stimmen die NS-Einträge?
- lassen sich die Nameservernamen auflösen?
- sind die autoritativen Server erreichbar?
- antworten alle autoritativen Server gleich?
- existiert bei klassenlosen IPv4-Netzen eine korrekte RFC-2317-Delegation?
- stimmt die IPv6-Nibble-Delegation mit dem zugeteilten Präfix überein?
- verweist eine alte Delegation noch auf außer Betrieb genommene Server?

Eine lokal erstellte Reverse-Zone ersetzt bei öffentlichen Adressen nicht die Delegation durch den Eigentümer beziehungsweise Provider des IP-Adressbereichs.

---

**7.11.25 Private und öffentliche Reverse-Zonen unterscheiden**

**Private IP-Adressen**

Für interne private Netze kann die Organisation die Reverse-Zonen auf ihren internen DNS-Servern verwalten.

Zu prüfen sind:

- internes Adresskonzept;
- zuständige DNS-Server;
- AD-Integrations- und Replikationsbereich;
- DHCP-Aktualisierung;
- sichere dynamische Updates;
- Aging und Scavenging.

**Öffentliche IP-Adressen**

Der PTR-Eintrag einer öffentlichen IP-Adresse wird normalerweise durch den Betreiber verwaltet, dem der entsprechende Adressbereich delegiert wurde.

Ein PTR-Eintrag für eine öffentliche IP-Adresse kann daher nicht allein dadurch veröffentlicht werden, dass in der normalen Forward-Zone der eigenen Domain ein Datensatz angelegt wird.

Zu klären sind:

- welcher Provider den IP-Adressbereich kontrolliert;
- ob der Provider eine Reverse-DNS-Verwaltung anbietet;
- welcher Ziel-FQDN eingetragen werden soll;
- ob der Zielname vorwärts wieder auf die öffentliche IP-Adresse zeigt;
- ob mehrere öffentliche IP-Adressen oder NAT berücksichtigt werden müssen.

---

**7.11.26 Vorwärts- und Rückwärtskonsistenz prüfen**

Beispiel für einen konsistenten Zustand:

```text
host25.example.test. A 192.0.2.25
```

```text
25.2.0.192.in-addr.arpa. PTR host25.example.test.
```

Anschließend wird der PTR-Zielname wieder vorwärts aufgelöst:

```text
host25.example.test. A 192.0.2.25
```

Prüfschritte:

1. IP-Adresse rückwärts auflösen.
2. PTR-Zielnamen dokumentieren.
3. PTR-Zielnamen über A und AAAA auflösen.
4. Prüfen, ob die ursprüngliche IP-Adresse in den Ergebnissen enthalten ist.
5. Alle beteiligten autoritativen DNS-Server vergleichen.

Mögliche Befunde:

| Befund | Einordnung |
|---|---|
| kein PTR vorhanden | Reverse-Eintrag fehlt oder Zone ist nicht erreichbar |
| PTR zeigt auf alten Hostnamen | veralteter Datensatz |
| PTR-Zielname existiert nicht | unvollständige DNS-Konfiguration |
| PTR-Zielname zeigt auf andere IP | Vorwärts- und Rückwärtsdaten stimmen nicht überein |
| mehrere PTR-Einträge | technisch möglich, kann Anwendungen jedoch unterschiedlich beeinflussen |
| mehrere A- oder AAAA-Adressen | kann bei Clustern, Load Balancing oder Mehrfachanbindung vorgesehen sein |
| verschiedene DNS-Server liefern verschiedene PTR-Werte | Replikation, Zonentransfer oder uneinheitliche Konfiguration prüfen |

Eine Vorwärts-Rückwärts-Konsistenz ist nicht für jede DNS-Anwendung zwingend vorgeschrieben. Bestimmte Mail-, Sicherheits- oder Identitätsprüfungen können sie jedoch voraussetzen.

---

**7.11.27 Windows-DNS-Serverdienst und Zonen prüfen**

Auf dem DNS-Server:

```powershell
Get-Service -Name DNS
```

Zonen anzeigen:

```powershell
Get-DnsServerZone
```

Nur Reverse-Lookup-Zonen:

```powershell
Get-DnsServerZone |
    Where-Object { $_.IsReverseLookupZone }
```

Zustand einer bestimmten Zone:

```powershell
Get-DnsServerZone `
  -Name "2.0.192.in-addr.arpa"
```

Zu prüfen sind:

- läuft der DNS-Serverdienst?
- ist die Zone geladen?
- ist die Zone primär, sekundär, Stub- oder AD-integriert?
- ist die Zone angehalten?
- ist sie für dynamische Updates vorgesehen?
- auf welche Server wird sie repliziert?
- existieren mehrere widersprüchliche Zonen für denselben Namensraum?
- liegt eine veraltete sekundäre Zone vor?
- ist die Zone nur auf einem Teil der DNS-Server vorhanden?

Ein laufender DNS-Dienst beweist nicht, dass eine bestimmte Zone korrekt geladen oder erreichbar ist.

---

**7.11.28 PTR-Datensätze auf dem Windows-DNS-Server prüfen**

Alle PTR-Einträge einer Zone:

```powershell
Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -RRType PTR
```

Bestimmten Eintrag prüfen:

```powershell
Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR
```

Von einem bestimmten DNS-Server lesen:

```powershell
Get-DnsServerResourceRecord `
  -ComputerName "dns01.example.test" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR
```

Zu vergleichen sind:

- Knotenname;
- PTR-Zielname;
- TTL;
- Zeitstempel;
- statischer oder dynamischer Datensatz;
- Ergebnis auf weiteren DNS-Servern;
- zugehöriger A- oder AAAA-Eintrag;
- aktuelle IP-Zuweisung.

Ein fehlender beziehungsweise als statisch dargestellter Zeitstempel kann auf einen statisch angelegten Datensatz hinweisen. Solche Datensätze werden nicht wie dynamisch gealterte Datensätze behandelt.

---

**7.11.29 Rekursion, Forwarder und Cache des Windows-DNS-Servers prüfen**

Allgemeine Forwarder:

```powershell
Get-DnsServerForwarder
```

Rekursionseinstellungen:

```powershell
Get-DnsServerRecursion
```

Root Hints:

```powershell
Get-DnsServerRootHint
```

Cacheeinstellungen:

```powershell
Get-DnsServerCache
```

Zu prüfen sind:

- sind die Forwarder erreichbar?
- antworten alle Forwarder zuverlässig?
- ist ihre Reihenfolge beziehungsweise Verfügbarkeit plausibel?
- ist Rekursion aktiviert, wenn sie benötigt wird?
- existiert ein bedingter Forwarder für die betroffene Zone?
- verweist der bedingte Forwarder auf aktuelle Server?
- sind Root Hints vorgesehen und verwendbar?
- sind Cachegrenzen und negative Cachezeit plausibel?
- bestehen DNS-Richtlinien oder Rekursionsbereiche?
- unterscheiden sich die Einstellungen zwischen DNS-Servern?

Nicht erreichbare Forwarder können Verzögerungen verursachen, bevor ein weiterer Forwarder oder ein alternativer Auflösungspfad verwendet wird.

---

**7.11.30 DNS-Serverstatistiken auswerten**

Aggregierte Statistiken:

```powershell
Get-DnsServerStatistics
```

Statistiken einer bestimmten Zone:

```powershell
Get-DnsServerStatistics `
  -ZoneName "2.0.192.in-addr.arpa"
```

Die genaue Struktur der Ausgabe hängt von der Windows-Server-Version ab. Zu untersuchen sind unter anderem:

- empfangene Abfragen;
- gesendete Antworten;
- Rekursionsvorgänge;
- Timeouts;
- Serverfehler;
- Formatfehler;
- abgelehnte Abfragen;
- Cacheverhalten;
- dynamische Updates;
- Paket- und Speicherstatistiken.

Statistiken dürfen nicht ohne vorherige Sicherung des Ausgangswerts zurückgesetzt werden.

Das Cmdlet kann bei zonenbezogener Verwendung mit `-Clear` Zähler verändern. Diese Option ist deshalb keine rein lesende Diagnosemaßnahme.

---

**7.11.31 Leistungsindikatoren überwachen**

Verfügbare DNS-Leistungsindikatoren anzeigen:

```powershell
Get-Counter -ListSet DNS
```

Beispiel für empfangene DNS-Abfragen und gesendete Antworten:

```powershell
Get-Counter `
  '\DNS\Total Query Received/sec',
  '\DNS\Total Response Sent/sec' `
  -SampleInterval 2 `
  -MaxSamples 10
```

DNS-Prozess überwachen:

```powershell
Get-Counter `
  '\Process(dns)\% Processor Time',
  '\Process(dns)\Working Set' `
  -SampleInterval 2 `
  -MaxSamples 10
```

Die Namen der Leistungsindikatoren können auf lokalisierten Windows-Systemen abweichen. Deshalb sollte zuerst `Get-Counter -ListSet DNS` verwendet werden.

Zu korrelieren sind:

- Abfragen pro Sekunde;
- Antworten pro Sekunde;
- CPU-Auslastung des DNS-Prozesses;
- Arbeitsspeicher;
- Netzwerkauslastung;
- Timeouts und Fehler;
- rekursive Abfragen;
- Antwortzeit aus Clientsicht;
- Zeitpunkt der Störung.

Eine hohe Anzahl von Abfragen ist allein kein Fehler. Entscheidend sind Baseline, Hardware, Abfrageart, Cachetreffer, Rekursion, Fehlerquote und Antwortzeit.

---

**7.11.32 Protokollierung kontrolliert einsetzen**

Windows DNS Server stellt unter anderem folgende Ereignisprotokolle bereit:

```text
Applications and Services Logs
└─ Microsoft
   └─ Windows
      └─ DNS-Server
         ├─ Audit
         └─ Analytical
```

Das Audit-Protokoll erfasst administrative und sicherheitsrelevante DNS-Vorgänge. Das analytische Protokoll kann detaillierte Abfrageinformationen liefern, ist jedoch standardmäßig nicht aktiviert.

Zu beachten ist:

- analytische Protokollierung nur gezielt aktivieren;
- Start- und Endzeit dokumentieren;
- ausreichenden Speicherplatz sicherstellen;
- Datenschutz und Schutz der DNS-Abfragedaten berücksichtigen;
- Protokollierung nach der Diagnose wieder zurücksetzen;
- Serverleistung während der Aufzeichnung überwachen;
- keine vollständigen internen DNS-Protokolle ungeschützt weitergeben.

Microsoft weist darauf hin, dass analytische DNS-Protokollierung bei sehr hohen Abfrageraten messbare Leistungseinflüsse verursachen kann. Deshalb muss sie mit den Leistungswerten des Servers korreliert werden.

---

**7.11.33 Netzwerkaufzeichnung gezielt verwenden**

Wenn DNS-Abfragen weiterhin unklar bleiben, kann eine zeitlich und inhaltlich begrenzte Netzwerkaufzeichnung erforderlich sein.

Zu prüfen sind:

- Quell- und Ziel-IP-Adresse;
- verwendeter Port;
- UDP oder TCP;
- DNS-Transaktions-ID;
- Abfragetyp;
- Antwortcode;
- Wiederholungen;
- abgeschnittene UDP-Antworten;
- anschließender TCP-Versuch;
- Paketverlust;
- ICMP-Fehlermeldungen;
- Verzögerung zwischen Abfrage und Antwort;
- Wechsel zu einem weiteren DNS-Server;
- EDNS- und DNSSEC-bezogene Größenprobleme;
- TLS-Verbindungsaufbau bei DoH oder DoT.

DNS-Pakete können interne Hostnamen, Dienstnamen und andere schützenswerte Informationen enthalten. Aufzeichnungen müssen deshalb nach Sicherheits- und Datenschutzvorgaben behandelt werden.

---

**7.11.34 Dynamische DNS-Aktualisierung prüfen**

Windows-Clients können ihre DNS-Namen dynamisch registrieren:

```powershell
Register-DnsClient
```

Alternativ:

```cmd
ipconfig /registerdns
```

Diese Befehle lösen eine dynamische Aktualisierung aus und verändern damit möglicherweise den DNS-Zustand. Vorher sind vorhandene Datensätze, Zeitstempel und Ereignisse zu dokumentieren.

Zu prüfen sind:

- existiert die Forward-Lookup-Zone?
- existiert die passende Reverse-Lookup-Zone?
- sind dynamische Updates für beide Zonen erlaubt?
- werden ausschließlich sichere dynamische Updates verwendet?
- soll der Client oder der DHCP-Server den PTR-Eintrag registrieren?
- besitzt das aktualisierende Konto die erforderlichen Rechte?
- gehört ein vorhandener Datensatz einem anderen Aktualisierungskonto?
- existiert ein veralteter statischer Eintrag?
- wird die Schnittstelle für DNS-Registrierung verwendet?
- stimmen Verbindungssuffix und Zonenname?
- sind mehrere aktive Schnittstellen beteiligt?
- erscheinen Aktualisierungsfehler in den DNS-, DHCP- oder Clientprotokollen?

Das wiederholte Ausführen von `Register-DnsClient` behebt keine fehlende Reverse-Zone, falsche Berechtigungen oder fehlerhafte DHCP-DNS-Einstellungen.

---

**7.11.35 DHCP und PTR-Registrierung prüfen**

Bei dynamisch vergebenen IP-Adressen kann der DHCP-Server DNS-Einträge im Auftrag des Clients aktualisieren.

Zu untersuchen sind:

- DHCP-Bereich und aktuelle Lease;
- zugeteilte IP-Adresse;
- Clientname und FQDN;
- DNS-Optionen des DHCP-Bereichs;
- Einstellung zur Aktualisierung von A- und PTR-Einträgen;
- Verhalten bei Lease-Ablauf und Adressfreigabe;
- verwendete DHCP-DNS-Anmeldeinformationen;
- Berechtigungen und Eigentümer vorhandener DNS-Datensätze;
- mehrere DHCP-Server;
- Failover-Konfiguration;
- AD-Replikation der DNS-Zone;
- DHCP-Serverereignisse zum Zeitpunkt der Aktualisierung.

Mögliche Fehlerbilder:

- A-Eintrag wird erstellt, PTR-Eintrag jedoch nicht;
- neuer PTR-Eintrag wird angelegt, alter PTR bleibt bestehen;
- PTR zeigt auf den Namen eines früheren Lease-Nehmers;
- ein DHCP-Server kann den Datensatz aktualisieren, ein anderer nicht;
- statischer Datensatz verhindert die erwartete Aktualisierung;
- die Reverse-Zone existiert nur auf einem Teil der DNS-Server.

---

**7.11.36 Aging und Scavenging berücksichtigen**

Aging und Scavenging können veraltete dynamische DNS-Datensätze entfernen. Die Funktion beinhaltet Löschvorgänge und muss deshalb kontrolliert geplant werden.

Zu prüfen sind:

- ist Aging für die Zone aktiviert?
- ist Scavenging auf einem geeigneten DNS-Server aktiviert?
- wie lang sind No-Refresh- und Refresh-Intervall?
- wie lang ist der Scavenging-Zyklus?
- besitzt der Datensatz einen dynamischen Zeitstempel?
- ist der Datensatz statisch?
- wurde die Zone neu erstellt oder die Funktion nachträglich aktiviert?
- stimmt die Konfiguration zwischen Forward- und Reverse-Zone?
- können aktive Geräte ihre Datensätze rechtzeitig aktualisieren?
- passen DHCP-Leasezeit und DNS-Alterungskonzept zusammen?
- wurde ein Datensatz bereits als veraltet eingestuft?

Scavenging sollte nicht spontan aktiviert oder manuell erzwungen werden, nur weil einzelne PTR-Einträge veraltet sind. Eine falsche Konfiguration kann gültige DNS-Datensätze löschen.

---

**7.11.37 Active-Directory-integrierte DNS-Zonen prüfen**

Bei AD-integrierten Zonen können unterschiedliche Antworten auf Replikationsprobleme hinweisen.

DNS-Test für einen Domänencontroller:

```cmd
dcdiag /test:DNS /v /s:<DC-Name>
```

Replikationsübersicht:

```cmd
repadmin /replsummary
```

Replikationsdetails:

```cmd
repadmin /showrepl
```

Zu prüfen sind:

- Replikationsbereich der Zone;
- vorhandene Verzeichnispartition;
- letzte erfolgreiche Replikation;
- betroffene Quell- und Ziel-Domänencontroller;
- DNS- und RPC-Fehler;
- unterschiedliche Datensatzstände;
- nur auf einzelnen DCs vorhandene PTR-Einträge;
- verzögerte Löschung veralteter Einträge;
- Zustand von AD DS und DNS-Serverdienst.

Eine erzwungene Replikation ist keine erste Diagnosemaßnahme. Zuerst müssen Richtung, Partner, Fehlercode und Ursache bestimmt werden.

---

**7.11.38 Systematischer Diagnoseablauf**

1. **Störungsbild dokumentieren**  
   Client, Anwendung, Name oder IP-Adresse, Uhrzeit und genaue Verzögerung erfassen.

2. **Abfragerichtung bestimmen**  
   Vorwärtsauflösung, Rückwärtsauflösung oder beide unterscheiden.

3. **Umfang bestimmen**  
   Einzelner Client, Anwendung, Standort, Zone oder alle Systeme unterscheiden.

4. **Resolverpfad erfassen**  
   DNS-Server, VPN, Suchsuffixe, Hosts-Datei, NRPT, DoH, DoT und lokale Resolver prüfen.

5. **Abfrage reproduzieren**  
   Den vorgesehenen DNS-Server ausdrücklich angeben.

6. **Antwortcode dokumentieren**  
   `NOERROR`, `NXDOMAIN`, `SERVFAIL`, `REFUSED` oder Timeout unterscheiden.

7. **Antwortzeit messen**  
   Erste und wiederholte Abfrage getrennt messen.

8. **Vorwärts- und Reverse-Abfrage vergleichen**  
   A beziehungsweise AAAA und PTR unabhängig testen.

9. **Alternativen DNS-Server testen**  
   Unterschiedliche Serverantworten dokumentieren.

10. **UDP und TCP vergleichen**  
    Transportabhängige Fehler abgrenzen.

11. **DoH oder DoT abgrenzen**  
    Verschlüsselten und klassischen DNS-Pfad getrennt prüfen.

12. **Autoritativen Server bestimmen**  
    Delegation und zuständige Zone prüfen.

13. **Direkte autoritative Abfrage durchführen**  
    Rekursion und Forwarder vom Zonenzustand trennen.

14. **PTR-Datensatz prüfen**  
    Zielname, TTL, Zeitstempel und Eigentümer auswerten.

15. **Vorwärts-Rückwärts-Konsistenz prüfen**  
    PTR-Zielnamen erneut über A und AAAA auflösen.

16. **Weitere Datensatztypen prüfen**  
    CNAME- oder SRV-Abhängigkeiten berücksichtigen.

17. **Cachezustand prüfen**  
    Client-, Server- und Anwendungscache unterscheiden.

18. **Forwarder und Rekursion prüfen**  
    Besonders bei langsamen externen oder bedingt weitergeleiteten Zonen.

19. **EDNS, MTU und DNSSEC prüfen**  
    Wenn kleine Antworten funktionieren und größere Antworten ausfallen.

20. **Serverleistung prüfen**  
    Abfragerate, CPU, Speicher, Fehler und Timeouts korrelieren.

21. **Dynamische Aktualisierung prüfen**  
    Client, DHCP, Berechtigungen und Zonenrichtlinie untersuchen.

22. **Aging und Scavenging prüfen**  
    Veraltete oder unerwartet gelöschte Datensätze abgrenzen.

23. **AD-Replikation prüfen**  
    Wenn DNS-Server unterschiedliche Antworten liefern.

24. **Hypothese formulieren**  
    Erwarteten Befund und möglichen Gegenbeweis festlegen.

25. **Eine kontrollierte Maßnahme durchführen**  
    Risiko, Rückweg und Erfolgskriterium dokumentieren.

26. **Erneut unter denselben Bedingungen messen**  
    Antwort, Code und Zeit mit dem Ausgangswert vergleichen.

27. **Gesamten DNS-Pfad verifizieren**  
    Client, rekursiven Server, autoritativen Server und Anwendung prüfen.

28. **Präventionsmaßnahme dokumentieren**  
    Ursache und dauerhafte Verbesserung festhalten.

---

**7.11.39 Befundmatrix**

| Befund | Mögliche Erklärung | Nächster Nachweis |
|---|---|---|
| `nslookup` zeigt `Unknown`, andere Abfragen funktionieren | PTR des DNS-Servers fehlt | DNS-Server-IP rückwärts abfragen |
| Vorwärtsauflösung funktioniert, Reverse nicht | PTR oder Reverse-Zone fehlt | PTR-Abfrage und Zonenprüfung |
| Reverse-Abfrage endet sofort mit `NXDOMAIN` | Name oder Zone meldet Nichtvorhandensein | Autorität und SOA der Antwort prüfen |
| Reverse-Abfrage läuft in Timeout | Server, Delegation oder Netzwerkpfad antwortet nicht | autoritative Server und Paketpfad prüfen |
| PTR zeigt auf alten Hostnamen | veralteter statischer oder dynamischer Eintrag | Lease, Zeitstempel und Datensatzeigentümer prüfen |
| PTR-Zielname besitzt keinen A-/AAAA-Eintrag | unvollständige DNS-Konfiguration | Zielnamen vorwärts auflösen |
| PTR-Zielname zeigt auf andere IP | Vorwärts-Rückwärts-Abweichung | vorgesehene Mehrfachadressierung prüfen |
| erste Abfrage langsam, zweite schnell | Cacheeffekt | kalte und warme Messung vergleichen |
| jede externe Abfrage langsam | Forwarder oder Rekursion | direkte Abfragen gegen Forwarder und Autorität |
| nur interne Zone langsam | interne Delegation oder AD-DNS | autoritative interne Server vergleichen |
| nur ein DNS-Server liefert falsche Antwort | lokaler Cache, Zone oder Replikation | Server direkt vergleichen |
| UDP fehlerhaft, TCP erfolgreich | Firewall, EDNS, Fragmentierung oder MTU | Transportvergleich und Netzwerkaufzeichnung |
| `SERVFAIL` nur bei signierter Zone | DNSSEC-Validierung oder Delegation | Validierungskette und Serverereignisse prüfen |
| `REFUSED` | Rekursion oder Richtlinie verweigert Abfrage | Serverrichtlinie und Quellnetz prüfen |
| A-Eintrag vorhanden, PTR fehlt | Reverse-Zone oder Updatepfad fehlt | DHCP-, Client- und Zonenupdate prüfen |
| PTR wird nach IP-Wechsel nicht entfernt | Aging, Scavenging oder DHCP-Bereinigung | Leaseablauf, Zeitstempel und Zonenalterung |
| unterschiedliche Antworten je DC | AD-Replikation oder uneinheitliche Zone | `repadmin`, `dcdiag` und direkte Abfragen |
| Auflösung über IP schnell, über Namen langsam | DNS oder nachgelagerte Namensprüfung | direkte DNS-Zeit und Anwendungspfad vergleichen |
| öffentliche IP besitzt keinen PTR | Provider hat keinen Reverse-Eintrag gesetzt | Betreiber des IP-Präfixes ermitteln |
| neuer Datensatz bleibt zunächst unsichtbar | positiver oder negativer Cache | TTL und Cacheebenen prüfen |
| `nslookup` und Anwendung liefern verschiedene Ergebnisse | NRPT, DoH oder anwendungseigener Resolver | tatsächlichen Resolverpfad bestimmen |
| nur große Antworten schlagen fehl | EDNS-, MTU- oder Fragmentierungsproblem | UDP/TCP und Antwortgrößen vergleichen |
| SRV wird gefunden, Dienst funktioniert nicht | Zielhost, Port oder Dienst fehlerhaft | SRV-Ziel und Dienstport prüfen |
| CNAME wird aufgelöst, Zielname jedoch nicht | fehlerhaftes Aliasziel | CNAME-Kette vollständig prüfen |
| klassisches DNS funktioniert, DoH nicht | Zertifikat, HTTPS-Port oder DoH-Endpunkt | DoH-Zustand und TLS-Verbindung prüfen |

---

**7.11.40 Ursachen und erforderliche Nachweise**

| Mögliche Ursache | Erforderlicher Nachweis |
|---|---|
| falscher DNS-Server | Clientkonfiguration und direkte Abfragen bestätigen abweichenden Resolver |
| falsches DNS-Suffix | Resolverkonfiguration zeigt unerwartete Suchdomäne |
| Hosts-Datei überschreibt DNS | lokaler Eintrag liefert abweichende Zuordnung |
| anwendungseigener DNS-Cache | Anwendung liefert trotz korrektem Systemtest alten Wert |
| NRPT-Fehler | wirksame Richtlinie leitet den Namensraum an falschen Resolver |
| fehlerhafter Split-DNS-Pfad | interne und externe Resolver liefern unbeabsichtigt verschiedene Antworten |
| DoH- oder DoT-Fehler | verschlüsselter Pfad scheitert bei funktionierendem klassischem DNS |
| fehlende Reverse-Zone | zuständiger DNS-Server besitzt oder erreicht die Zone nicht |
| fehlender PTR-Eintrag | autoritative PTR-Abfrage liefert keinen Datensatz |
| falscher PTR-Eintrag | autoritative Antwort enthält unerwarteten Zielnamen |
| fehlerhafte Delegation | übergeordnete Zone verweist auf falsche oder nicht erreichbare Server |
| fehlerhafte RFC-2317-Konfiguration | CNAME- und Zonendelegation des Teilnetzes sind unvollständig |
| fehlerhafte IPv6-Reverse-Zone | Nibble-Zone stimmt nicht mit dem delegierten Präfix überein |
| nicht erreichbarer Forwarder | direkte Abfrage zum Forwarder scheitert reproduzierbar |
| langsamer autoritativer Server | direkte autoritative Abfrage zeigt erhöhte Antwortzeit |
| UDP-Blockierung | UDP-DNS scheitert, TCP-DNS funktioniert |
| TCP-Blockierung | abgeschnittene UDP-Antwort kann nicht über TCP wiederholt werden |
| Paketverlust | Aufzeichnung zeigt Wiederholungen oder fehlende Antworten |
| MTU- oder Fragmentierungsproblem | große UDP-Antworten scheitern, TCP funktioniert |
| DNS-Serverüberlastung | erhöhte Antwortzeit korreliert mit Abfragerate und Ressourcenlast |
| ungeeignete TTL | Datensatz- und Cachewerte bestätigen zu kurze oder zu lange Speicherung |
| negativer Cache | zuvor negative Antwort bleibt bis zum Ablauf wirksam |
| falscher CNAME | Alias verweist auf fehlenden oder falschen Zielnamen |
| falscher SRV-Eintrag | Dienstziel, Port, Priorität oder Gewicht sind unzutreffend |
| DHCP aktualisiert PTR nicht | DHCP-Ereignis oder Konfiguration bestätigt fehlgeschlagene Aktualisierung |
| fehlende Updateberechtigung | DNS- oder DHCP-Protokoll zeigt Zugriffsfehler |
| veralteter statischer PTR | statischer Datensatz enthält alten Namen |
| fehlerhaftes Scavenging | Konfiguration oder Ereignisse bestätigen unerwartete Löschung |
| AD-Replikationsproblem | DNS-Server liefern unterschiedliche autoritative Daten und `repadmin` meldet Fehler |
| DNSSEC-Validierungsfehler | `SERVFAIL` und Validierungsdaten bestätigen fehlerhafte Vertrauenskette |
| öffentlicher PTR nicht delegiert | Provider beziehungsweise Präfixbetreiber bestätigt fehlende Reverse-Konfiguration |

---

**7.11.41 Kontrollierte Maßnahmen, Risiko und Rückweg**

| Maßnahme | Risiko | Rückweg beziehungsweise Kontrolle |
|---|---|---|
| vorgesehenen DNS-Server konfigurieren | andere Namensräume können beeinflusst werden | bisherige DNS-Werte dokumentieren |
| falsches DNS-Suffix korrigieren | Suchverhalten verändert sich | ursprüngliche Suffixliste sichern |
| fehlerhaften Hosts-Eintrag entfernen | Anwendung verliert lokale Sonderzuordnung | Datei und ursprünglichen Eintrag sichern |
| NRPT-Regel korrigieren | VPN-Namensauflösung kann ausfallen | bisherige Regel und Zielserver sichern |
| DoH- oder DoT-Konfiguration korrigieren | Transport und Fallbackverhalten ändern sich | bisherigen Verschlüsselungszustand dokumentieren |
| fehlende Reverse-Zone anlegen | falscher Adressbereich kann überschrieben werden | Netz-ID und Zuständigkeit vorher bestätigen |
| PTR-Eintrag anlegen | falscher Name wird veröffentlicht | IP, FQDN und Forward-Eintrag vorher prüfen |
| veralteten PTR korrigieren | bestehende Abhängigkeiten können betroffen sein | alten Wert und Eigentümer dokumentieren |
| Forwarder korrigieren | externe und interne Auflösung kann beeinflusst werden | bisherige Forwarderliste sichern |
| Delegation korrigieren | gesamter Reverse-Bereich kann betroffen sein | bisherige NS- und CNAME-Daten sichern |
| dynamische Updates korrigieren | viele Clients können Datensätze verändern | Zonenrichtlinie und Berechtigungen dokumentieren |
| Clientregistrierung auslösen | mehrere A- oder PTR-Einträge können entstehen | vorhandene Einträge vorher erfassen |
| Clientcache kontrolliert löschen | ursprünglicher Cachebefund geht verloren | Cacheinhalt vorher dokumentieren |
| DNS-Servercache löschen | viele Abfragen müssen erneut rekursiv aufgelöst werden | nur gezielt und mit Lastkontrolle |
| TTL ändern | Cacheverhalten vieler Resolver ändert sich | bisherigen Wert und Änderungszeit sichern |
| Aging oder Scavenging anpassen | gültige Datensätze können gelöscht werden | Zonenexport und Änderungsplan vorsehen |
| AD-Replikationsfehler beheben | mehrere DNS- und AD-Daten können betroffen sein | DC-spezifischen Wiederherstellungsplan verwenden |
| analytische Protokollierung aktivieren | Leistung und Datenschutz können betroffen sein | Zeitfenster, Speicherlimit und Abschaltung festlegen |

Pro Diagnoseversuch sollte möglichst nur eine relevante Variable verändert werden.

---

**7.11.42 Beispiel: Reverse-Zone und PTR-Eintrag anlegen**

Die folgenden Befehle sind verändernde Administrationsmaßnahmen und dürfen erst nach Prüfung von Netzbereich, Zonenverantwortung, Replikationsbereich und bestehender Konfiguration ausgeführt werden.

AD-integrierte IPv4-Reverse-Zone für das Dokumentationsnetz `192.0.2.0/24`:

```powershell
Add-DnsServerPrimaryZone `
  -NetworkID "192.0.2.0/24" `
  -ReplicationScope "Forest"
```

PTR-Eintrag für `192.0.2.25`:

```powershell
Add-DnsServerResourceRecordPtr `
  -Name "25" `
  -ZoneName "2.0.192.in-addr.arpa" `
  -PtrDomainName "host25.example.test."
```

Danach kontrollieren:

```powershell
Get-DnsServerResourceRecord `
  -ZoneName "2.0.192.in-addr.arpa" `
  -Name "25" `
  -RRType PTR
```

```powershell
Resolve-DnsName `
  -Name "192.0.2.25" `
  -Type PTR `
  -Server "192.0.2.53" `
  -DnsOnly
```

Zusätzlich muss der PTR-Zielname vorwärts geprüft werden:

```powershell
Resolve-DnsName `
  -Name "host25.example.test" `
  -Type A `
  -Server "192.0.2.53" `
  -DnsOnly
```

Die Beispieladressen und Namen dienen ausschließlich der Dokumentation und müssen durch die tatsächlich autorisierten Werte ersetzt werden.

---

**7.11.43 Verifikation**

Nach einer Maßnahme sind mindestens folgende Punkte zu prüfen:

- Client verwendet die vorgesehenen DNS-Server;
- richtige Netzwerkschnittstelle und VPN-Regel sind aktiv;
- DNS-Suffixe und Suchliste sind korrekt;
- NRPT-Regeln wirken wie vorgesehen;
- verwendeter DNS-Transport ist bestimmt;
- Vorwärtsauflösung liefert den erwarteten A- beziehungsweise AAAA-Eintrag;
- Rückwärtsauflösung liefert den erwarteten PTR-Eintrag;
- PTR-Zielname lässt sich vorwärts auflösen;
- ursprüngliche IP-Adresse ist in der Vorwärtsantwort enthalten, sofern vorgesehen;
- CNAME- und SRV-Ziele sind auflösbar;
- alle autoritativen DNS-Server liefern denselben Datensatz;
- rekursive DNS-Server liefern konsistente Antworten;
- erste und wiederholte Antwortzeit sind plausibel;
- UDP- und TCP-Auflösung funktionieren;
- DoH oder DoT funktioniert, sofern vorgesehen;
- negative Cacheeinträge sind abgelaufen oder kontrolliert entfernt;
- Forwarder und bedingte Forwarder antworten;
- Reverse-Zone ist korrekt delegiert;
- AD-integrierte Zone repliziert fehlerfrei;
- dynamische Aktualisierung funktioniert, sofern vorgesehen;
- DHCP erzeugt oder entfernt PTR-Einträge korrekt;
- Aging und Scavenging löschen keine aktiven Datensätze;
- DNSSEC-validierte Zonen verursachen keine neuen Fehler;
- keine neuen DNS-, DHCP- oder Replikationsfehler entstehen;
- betroffene Anwendung verwendet die korrigierte Auflösung;
- temporäre Diagnoseprotokollierung wurde zurückgenommen;
- Ursache, Maßnahme und Prävention wurden dokumentiert.

Eine einzelne erfolgreiche Cacheabfrage ist keine ausreichende Verifikation des vollständigen DNS-Pfads.

---

**7.11.44 Präventionsmaßnahmen**

- Forward- und Reverse-Zonen gemeinsam planen;
- Zuständigkeiten für private und öffentliche Reverse-Zonen dokumentieren;
- PTR-Einträge für wichtige Server und Infrastrukturkomponenten pflegen;
- DNS-Server selbst mit korrekten PTR-Einträgen versehen;
- Vorwärts- und Rückwärtskonsistenz regelmäßig prüfen;
- DNS-Server redundant bereitstellen;
- autoritative und rekursive Rollen dokumentieren;
- Forwarder und bedingte Forwarder überwachen;
- Reverse-Delegationen regelmäßig kontrollieren;
- klassenlose IPv4-Delegationen eindeutig dokumentieren;
- IPv6-Reverse-Zonen anhand der delegierten Präfixe planen;
- DNS-Antwortzeiten und Fehlerquoten als Baseline erfassen;
- Abfrageraten, CPU, Speicher und Netzwerk überwachen;
- UDP- und TCP-Port `53` in Firewallkonzepten berücksichtigen;
- DoH-, DoT-, DNSSEC- und EDNS-Verhalten bei Netzwerkänderungen testen;
- MTU und Fragmentierung auf VPN- und Tunnelpfaden berücksichtigen;
- TTL-Werte an Änderungs- und Lastanforderungen anpassen;
- negative Cachezeiten berücksichtigen;
- DHCP- und DNS-Aktualisierungsverantwortung eindeutig festlegen;
- abgesicherte Aktualisierungsverfahren verwenden;
- Aging und Scavenging zuerst in kontrolliertem Umfang testen;
- AD-Replikation überwachen;
- Zonenänderungen protokollieren;
- veraltete statische Einträge regelmäßig prüfen;
- VPN-, Split-DNS-, NRPT- und DoH-Konfigurationen dokumentieren;
- Anwendungen mit eigenem DNS-Verhalten erfassen;
- Runbooks für langsame DNS-Abfragen und fehlerhafte PTR-Einträge testen.

---

**7.11.45 Typische Fehler bei der Diagnose**

- `Unknown` in `nslookup` sofort als vollständigen DNS-Ausfall bewerten.
- Vorwärts- und Rückwärtsauflösung gleichsetzen.
- Einen vorhandenen A-Eintrag als Beweis für einen PTR-Eintrag betrachten.
- Einen fehlenden PTR-Eintrag automatisch als Verbindungsursache einstufen.
- Die Antwortzeit nicht messen.
- Nur eine einzelne Abfrage durchführen.
- Cachetreffer und vollständige Rekursion nicht unterscheiden.
- Den verwendeten DNS-Server nicht ausdrücklich angeben.
- Anwendungsergebnis und direkte DNS-Abfrage gleichsetzen.
- Hosts-Datei, VPN, NRPT, DoH oder Anwendungscache ignorieren.
- `nslookup` als vollständigen Test einer NRPT-Regel verwenden.
- `Test-NetConnection -Port 53` als UDP-DNS-Test verwenden.
- Nur UDP oder nur TCP prüfen.
- `NXDOMAIN`, `SERVFAIL` und Timeout gleich behandeln.
- Eine negative Antwort mit einer ausgebliebenen Antwort verwechseln.
- DNS-Caches vor der Dokumentation löschen.
- Den DNS-Servercache routinemäßig leeren.
- Forwarder ändern, ohne die ursprüngliche Konfiguration zu sichern.
- Nur einen autoritativen DNS-Server prüfen.
- Die Reverse-Delegation nicht untersuchen.
- Bei öffentlichen IP-Adressen selbst eine nicht delegierte Reverse-Zone veröffentlichen wollen.
- IPv4-Oktette falsch anordnen.
- IPv6-Blöcke statt einzelner Nibbles umkehren.
- RFC-2317-Delegationen bei kleineren IPv4-Netzen ignorieren.
- PTR-Zielnamen nicht wieder vorwärts auflösen.
- Mehrere PTR- oder A-Einträge ohne Kenntnis des Systemdesigns löschen.
- CNAME-Ziele nicht bis zum endgültigen A- oder AAAA-Eintrag verfolgen.
- Einen erfolgreichen SRV-Lookup mit einem erreichbaren Dienst gleichsetzen.
- Große DNS-Antworten und Fragmentierung nicht berücksichtigen.
- DNSSEC bei `SERVFAIL` nicht prüfen.
- DoH und DNSSEC gleichsetzen.
- Dynamische Registrierung wiederholt auslösen, ohne Berechtigungen zu prüfen.
- Scavenging spontan aktivieren.
- Veraltete statische Einträge mit dynamischen Einträgen gleichsetzen.
- AD-Replikationsprobleme durch manuelle Datensatzänderungen verdecken.
- Analytische DNS-Protokollierung unbegrenzt eingeschaltet lassen.
- DNS-Protokolle mit internen Namen ungeschützt weitergeben.
- Nach der Änderung nur den Cache und nicht den vollständigen DNS-Pfad testen.

---

**7.11.46 Checkliste**

- [ ] betroffenes System und Anwendung dokumentiert
- [ ] genauer Fehlerzeitpunkt erfasst
- [ ] Vorwärts- oder Rückwärtsauflösung bestimmt
- [ ] Umfang der Störung bestimmt
- [ ] verwendete Netzwerkschnittstelle geprüft
- [ ] VPN-Zustand dokumentiert
- [ ] konfigurierte DNS-Server erfasst
- [ ] DNS-Suffixe und Suchliste geprüft
- [ ] Hosts-Datei berücksichtigt
- [ ] NRPT geprüft
- [ ] Split-DNS berücksichtigt
- [ ] DoH, DoT und Anwendungscache berücksichtigt
- [ ] betroffener Name oder IP-Adresse dokumentiert
- [ ] Abfragetyp bestimmt
- [ ] DNS-Server bei Test ausdrücklich angegeben
- [ ] vollständige Antwort dokumentiert
- [ ] Antwortcode ausgewertet
- [ ] Timeout von DNS-Fehlercode unterschieden
- [ ] erste Antwortzeit gemessen
- [ ] wiederholte Antwortzeit gemessen
- [ ] positiver Cache geprüft
- [ ] negativer Cache geprüft
- [ ] TTL dokumentiert
- [ ] Vorwärtsauflösung getestet
- [ ] IPv4-Rückwärtsauflösung getestet
- [ ] IPv6-Rückwärtsauflösung bei Bedarf getestet
- [ ] PTR-Zielname dokumentiert
- [ ] PTR-Zielname vorwärts aufgelöst
- [ ] Vorwärts-Rückwärts-Konsistenz geprüft
- [ ] CNAME-Kette bei Bedarf geprüft
- [ ] SRV-Ziel und Dienstport bei Bedarf geprüft
- [ ] primärer DNS-Server getestet
- [ ] alternativer DNS-Server getestet
- [ ] autoritativer DNS-Server bestimmt
- [ ] direkte autoritative Abfrage durchgeführt
- [ ] Reverse-Delegation geprüft
- [ ] RFC-2317-Konfiguration bei Teilnetzen berücksichtigt
- [ ] öffentliche oder private IP-Adresse unterschieden
- [ ] UDP-DNS getestet
- [ ] TCP-DNS getestet
- [ ] größere DNS-Antwort getestet
- [ ] EDNS und MTU berücksichtigt
- [ ] DNSSEC bei `SERVFAIL` berücksichtigt
- [ ] verschlüsselter DNS-Pfad bei Bedarf getestet
- [ ] Forwarder geprüft
- [ ] bedingte Forwarder geprüft
- [ ] Rekursion geprüft
- [ ] DNS-Serverdienst geprüft
- [ ] Reverse-Zone auf dem Server geprüft
- [ ] PTR-Datensatz direkt geprüft
- [ ] Zeitstempel und statischer Zustand geprüft
- [ ] Serverstatistiken ausgewertet
- [ ] Abfragerate und Serverlast korreliert
- [ ] DNS-Ereignisse ausgewertet
- [ ] dynamische Aktualisierung geprüft
- [ ] DHCP-Aktualisierung geprüft
- [ ] Berechtigungen und Datensatzeigentümer geprüft
- [ ] Aging und Scavenging geprüft
- [ ] AD-Replikation bei unterschiedlichen Antworten geprüft
- [ ] Hypothese und Gegenbeweis formuliert
- [ ] Risiko und Rückweg dokumentiert
- [ ] nur eine kontrollierte Maßnahme durchgeführt
- [ ] Antwortcode nach der Maßnahme geprüft
- [ ] Antwortzeit nach der Maßnahme geprüft
- [ ] vollständiger DNS-Pfad verifiziert
- [ ] Anwendung erneut getestet
- [ ] temporäre Diagnoseänderungen zurückgenommen
- [ ] Ursache und Präventionsmaßnahme dokumentiert

---

**7.11.47 Schnellreferenz**

| Aufgabe | Befehl |
|---|---|
| Windows-Netzwerk- und DNS-Konfiguration | `ipconfig /all` |
| Windows-DNS-Serveradressen | `Get-DnsClientServerAddress` |
| Windows-DNS-Clientzustand | `Get-DnsClient` |
| Linux-Resolverzustand | `resolvectl status` |
| macOS-Resolverzustand | `scutil --dns` |
| wirksame NRPT-Richtlinie | `Get-DnsClientNrptPolicy` |
| konfigurierte NRPT-Regeln | `Get-DnsClientNrptRule` |
| DoH-/DoT-Clientzustand | `netsh dnsclient show state` |
| verschlüsselte DNS-Server | `netsh dnsclient show encryption` |
| Vorwärtsauflösung IPv4 | `Resolve-DnsName <Name> -Type A -Server <DNS-IP> -DnsOnly` |
| Vorwärtsauflösung IPv6 | `Resolve-DnsName <Name> -Type AAAA -Server <DNS-IP> -DnsOnly` |
| Rückwärtsauflösung | `Resolve-DnsName <IP> -Type PTR -Server <DNS-IP> -DnsOnly` |
| Rückwärtsauflösung mit `dig` | `dig @<DNS-IP> -x <IP>` |
| CNAME prüfen | `Resolve-DnsName <Name> -Type CNAME -Server <DNS-IP> -DnsOnly` |
| SRV prüfen | `Resolve-DnsName <SRV-Name> -Type SRV -Server <DNS-IP> -DnsOnly` |
| TCP-DNS-Abfrage | `Resolve-DnsName <Name> -Server <DNS-IP> -TcpOnly -DnsOnly` |
| TCP-Port 53 prüfen | `Test-NetConnection <DNS-IP> -Port 53` |
| DNSSEC-Daten anfordern | `Resolve-DnsName <Name> -Server <DNS-IP> -DnssecOk` |
| Clientcache anzeigen | `Get-DnsClientCache` |
| Clientcache löschen | `Clear-DnsClientCache` |
| DNS-Serverdienst | `Get-Service DNS` |
| DNS-Zonen | `Get-DnsServerZone` |
| PTR-Einträge | `Get-DnsServerResourceRecord -ZoneName <Zone> -RRType PTR` |
| Forwarder | `Get-DnsServerForwarder` |
| Rekursion | `Get-DnsServerRecursion` |
| Cacheeinstellungen | `Get-DnsServerCache` |
| Serverstatistiken | `Get-DnsServerStatistics` |
| Leistungsindikatoren | `Get-Counter -ListSet DNS` |
| DoH-Serverkonfiguration | `Get-DnsServerEncryptionProtocol` |
| Clientregistrierung | `Register-DnsClient` |
| AD-DNS-Test | `dcdiag /test:DNS /v` |
| AD-Replikation | `repadmin /replsummary` |

Ändernde Befehle, die nicht als erste Diagnose verwendet werden dürfen:

```text
Clear-DnsClientCache
Clear-DnsServerCache
Register-DnsClient
ipconfig /flushdns
ipconfig /registerdns
Add-DnsServerPrimaryZone
Add-DnsServerResourceRecordPtr
Set-DnsServerForwarder
Set-DnsServerRecursion
Set-DnsServerCache
Set-DnsServerZoneAging
Start-DnsServerScavenging
Set-DnsServerEncryptionProtocol
Remove-DnsServerResourceRecord
```

---

**7.11.48 Quellen**

**Offizielle Microsoft-Dokumentation**

- [Microsoft Learn – Guidance for troubleshooting DNS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-guidance)
- [Microsoft Learn – Troubleshoot DNS servers](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot/troubleshoot-dns-server)
- [Microsoft Learn – Troubleshoot DNS client name resolution issues](https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/troubleshoot-dns-client-resolution-issues)
- [Microsoft Learn – DNS queries and lookups](https://learn.microsoft.com/en-us/windows-server/networking/dns/queries-lookups)
- [Microsoft Learn – DNS architecture](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture)
- [Microsoft Learn – Manage DNS zones](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones)
- [Microsoft Learn – Manage DNS resource records](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-resource-records)
- [Microsoft Learn – Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update)
- [Microsoft Learn – DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup)
- [Microsoft Learn – Troubleshoot DNS scavenging issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-scavenging-issues)
- [Microsoft Learn – Forwarders and conditional forwarders resolution timeouts](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/forwarders-resolution-timeouts)
- [Microsoft Learn – Enable DNS logging and diagnostics](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics)
- [Microsoft Learn – DNS encryption using DNS over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-encryption-dns-over-https)
- [Microsoft Learn – Enable DNS over HTTPS in DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/enable-dns-over-https-server)
- [Microsoft Learn – Troubleshoot DNS over HTTPS in DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/troubleshoot-dns-over-https-server)
- [Microsoft Learn – Secure DNS Client over HTTPS](https://learn.microsoft.com/en-us/windows-server/networking/dns/doh-client-support)
- [Microsoft Learn – netsh dnsclient](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-dnsclient)
- [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname)
- [Microsoft Learn – DnsClient PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsclient/)
- [Microsoft Learn – Clear-DnsClientCache](https://learn.microsoft.com/en-us/powershell/module/dnsclient/clear-dnsclientcache)
- [Microsoft Learn – Register-DnsClient](https://learn.microsoft.com/en-us/powershell/module/dnsclient/register-dnsclient)
- [Microsoft Learn – Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone)
- [Microsoft Learn – Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord)
- [Microsoft Learn – Add-DnsServerPrimaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverprimaryzone)
- [Microsoft Learn – Add-DnsServerResourceRecordPtr](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecordptr)
- [Microsoft Learn – Get-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverstatistics)
- [Microsoft Learn – Get-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservercache)
- [Microsoft Learn – Clear-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsservercache)
- [Microsoft Learn – Set-DnsServerEncryptionProtocol](https://learn.microsoft.com/en-us/powershell/module/dnsserver/set-dnsserverencryptionprotocol)
- [Microsoft Learn – DnsServer PowerShell module](https://learn.microsoft.com/en-us/powershell/module/dnsserver/)
- [Microsoft Learn – Verify that SRV DNS records have been created](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/verify-srv-dns-records-have-been-created)
- [Microsoft Learn – Dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag)
- [Microsoft Learn – Diagnose Active Directory replication failures](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/diagnose-replication-failures)

**Standards**

- [RFC 1034 – Domain Names: Concepts and Facilities](https://datatracker.ietf.org/doc/html/rfc1034)
- [RFC 1035 – Domain Names: Implementation and Specification](https://datatracker.ietf.org/doc/html/rfc1035)
- [RFC 2308 – Negative Caching of DNS Queries](https://datatracker.ietf.org/doc/html/rfc2308)
- [RFC 2317 – Classless IN-ADDR.ARPA Delegation](https://datatracker.ietf.org/doc/html/rfc2317)
- [RFC 3596 – DNS Extensions to Support IPv6](https://datatracker.ietf.org/doc/html/rfc3596)
- [RFC 7858 – Specification for DNS over Transport Layer Security](https://datatracker.ietf.org/doc/html/rfc7858)
- [RFC 8484 – DNS Queries over HTTPS](https://datatracker.ietf.org/doc/html/rfc8484)
- [RFC 8499 – DNS Terminology](https://datatracker.ietf.org/doc/html/rfc8499)

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.