Skip to main content

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:

host25.example.test → 192.0.2.25

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

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:

192.0.2.25

Daraus entsteht der Abfragename:

25.2.0.192.in-addr.arpa.

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

host25.example.test.

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

2.0.192.in-addr.arpa

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

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:

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:

nslookup host25.example.test 192.0.2.53

nslookup 192.0.2.25 192.0.2.53

PTR des DNS-Servers selbst prüfen:

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

ipconfig /all

Get-DnsClientServerAddress

Get-DnsClient

Linux

cat /etc/resolv.conf

Bei Systemen mit systemd-resolved zusätzlich:

resolvectl status

macOS

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:

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:

Get-DnsClientNrptPolicy

Konfigurierte NRPT-Regeln anzeigen:

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:

netsh dnsclient show state

Globale Einstellungen anzeigen:

netsh dnsclient show global

Konfigurierte verschlüsselte DNS-Server anzeigen:

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:

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

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

AAAA-Eintrag:

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

Windows Eingabeaufforderung

nslookup host25.example.test 192.0.2.53

Linux und macOS

dig @192.0.2.53 host25.example.test A

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

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

Windows Eingabeaufforderung

nslookup 192.0.2.25 192.0.2.53

Linux und macOS

dig @192.0.2.53 -x 192.0.2.25

Kompakte Ausgabe mit Antwort und Statistik:

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

Direkte Abfrage des vollständigen Reverse-Namens:

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:

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

SRV prüfen:

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

Mit dig:

dig @192.0.2.53 alias.example.test CNAME

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:

dig @192.0.2.53 host25.example.test A +stats

TCP erzwingen:

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

Windows PowerShell

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

TCP erzwingen:

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:

ipconfig /displaydns

Alternativ:

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:

Clear-DnsClientCache

Alternativ:

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:

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:

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

Vergleich über TCP:

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:

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

Mit dig:

dig @192.0.2.53 example.com A +dnssec

Vergleich über TCP:

dig @192.0.2.53 example.com A +dnssec +tcp

EDNS testweise unterdrücken:

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

dig -x 192.0.2.25 +trace

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

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:

host25.example.test. A 192.0.2.25

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

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

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:

Get-Service -Name DNS

Zonen anzeigen:

Get-DnsServerZone

Nur Reverse-Lookup-Zonen:

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

Zustand einer bestimmten Zone:

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:

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

Bestimmten Eintrag prüfen:

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

Von einem bestimmten DNS-Server lesen:

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:

Get-DnsServerForwarder

Rekursionseinstellungen:

Get-DnsServerRecursion

Root Hints:

Get-DnsServerRootHint

Cacheeinstellungen:

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:

Get-DnsServerStatistics

Statistiken einer bestimmten Zone:

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:

Get-Counter -ListSet DNS

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

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

DNS-Prozess überwachen:

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:

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:

Register-DnsClient

Alternativ:

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:

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

Replikationsübersicht:

repadmin /replsummary

Replikationsdetails:

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:

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

PTR-Eintrag für 192.0.2.25:

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

Danach kontrollieren:

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

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:

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:

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

Standards

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

Back to top