Jede Empfehlung auf dieser Seite beruht auf Aussagen der Betreiber und auf Messungen. Aussagen kann man zitieren, Messungen kann man wiederholen. Dieser Abschnitt zeigt, wie.
Alle Befehle wurden am 7. September 2026 auf einem gewöhnlichen Linux-Rechner ausgeführt, und die beschriebenen Ausgaben sind das, was dabei tatsächlich herauskam. Wo eine Ausgabe abweichen kann, steht es dabei. Sie brauchen nichts als dig, curl und openssl; alle drei sind auf den meisten Systemen vorhanden. Unter Windows liefert das Windows-Subsystem für Linux dieselben Werkzeuge.
Ein Hinweis vorweg, der die häufigste Fehlerquelle betrifft: Fragen Sie immer den Resolver direkt, mit @ und seiner Adresse. Ohne @ antwortet der lokale Dienst Ihres Betriebssystems, und dessen Antwort sagt über den eigentlichen Resolver wenig aus.
Validiert mein Resolver DNSSEC?
Die Frage lässt sich in drei Befehlen beantworten, und zwar zweifelsfrei. Wichtig ist, den Resolver direkt zu
befragen, also mit @ und seiner Adresse. Fragt man ohne @, antwortet der lokale Stub des
Betriebssystems, und der verschluckt das entscheidende Merkmal oft.
Die Positivkontrolle
Markiert der Resolver eine korrekt signierte Antwort als geprüft?
dig +dnssec @9.9.9.9 sigok.ippacket.stream A
In der Zeile ;; flags: muss neben qr rd ra auch ad stehen, der Status
muss NOERROR sein. Gemessen am 7. September 2026: status: NOERROR und
flags: qr rd ra ad. Das ad steht für „authentic data“. RFC 4035 erlaubt einem Server, dieses
Bit nur zu setzen, wenn er alle Datensätze der Antwort selbst geprüft hat.
Ersetzen Sie 9.9.9.9 durch die Adresse, die Sie prüfen wollen.
Die Negativkontrolle
Weist der Resolver eine absichtlich falsch signierte Antwort zurück?
dig @9.9.9.9 sigfail.ippacket.stream A
dig @9.9.9.9 dnssec-failed.org A
Beide müssen status: SERVFAIL und eine leere Antwortsektion liefern. Gemessen am
7. September 2026: beide SERVFAIL. Kommt stattdessen NOERROR mit einer IP-Adresse zurück,
validiert dieser Resolver nicht. Zwei unabhängige Testdomains deshalb, weil eine davon jederzeit ausfallen kann.
Der Beweis, dass es wirklich an DNSSEC lag
Ein SERVFAIL kann viele Ursachen haben. Wie schließe ich die anderen aus?
dig +cd @9.9.9.9 sigfail.ippacket.stream A
Mit gesetztem CD-Bit, also „checking disabled“, muss dieselbe Abfrage jetzt NOERROR und eine
Adresse liefern. Gemessen am 7. September 2026: ohne +cd SERVFAIL, mit +cd NOERROR. Genau
dieser Umschlag ist der Beweis: Der Resolver hat vorher geprüft und deshalb abgelehnt, und nicht etwa, weil die Domain
kaputt oder der Server überlastet wäre.
Den Grund im Klartext lesen
Sagt der Resolver auch, warum er abgelehnt hat?
dig @9.9.9.9 sigfail.ippacket.stream A | grep EDE
Eine Zeile der Form ; EDE: 6 (DNSSEC Bogus). Genau das wurde am 7. September 2026 gemessen.
Extended DNS Errors nach RFC 8914 liefern einen maschinenlesbaren Grund statt eines nackten SERVFAIL. Erscheint keine
EDE-Zeile, unterstützt der Resolver diese Erweiterung nicht; das ist für sich genommen kein Mangel an der Validierung.
Der Fallstrick, an dem die meisten Tests scheitern
Warum fehlt das ad-Flag, obwohl der Resolver validiert?
dig +dnssec sigok.ippacket.stream A
dig +dnssec @9.9.9.9 sigok.ippacket.stream A
Der Unterschied ist das @. Ohne Adresse fragen Sie den lokalen Dienst des Betriebssystems.
Auf dem Testrechner lieferte der erste Befehl am 7. September 2026 flags: qr rd ra ohne
ad, der zweite flags: qr rd ra ad. Der Upstream validiert also, der lokale Stub reicht die
Markierung nur nicht durch. Wer das nicht weiß, hält einen validierenden Resolver für kaputt.
Unter Linux zeigt resolvectl status, was der Systemdienst tut.
Welchen Resolver benutze ich wirklich?
Eingetragen ist eine Sache, benutzt eine andere. Router, VPN-Software, Browser mit eigenem DoH und der
Systemdienst greifen alle ein. Diese Befehle zeigen, wer am Ende wirklich antwortet und welchen Teil Ihrer Adresse er
dabei weitergibt.
Wer antwortet, und was gibt er von mir weiter?
Sieht der autoritative Server meine Adresse, oder nur die des Resolvers?
dig +short TXT whoami.ds.akahelp.net
Der Dienst von Akamai antwortet mit bis zu drei Paaren. ns ist die Adresse des Resolvers, der
tatsächlich angefragt hat. Erscheint zusätzlich ecs, wurde ein Teil Ihrer eigenen Adresse mitgeschickt.
Gemessen am 7. September 2026 über den Systemresolver: nur "ns", kein ecs. Es wurde also
nichts von der Client-Adresse weitergereicht.
Derselbe Anbieter, zwei Adressen, zwei Ergebnisse
Wie sieht der Unterschied zwischen mit und ohne EDNS Client Subnet konkret aus?
dig +short TXT whoami.ds.akahelp.net @9.9.9.9
dig +short TXT whoami.ds.akahelp.net @9.9.9.11
Gemessen am 7. September 2026. Über 9.9.9.9 kam ausschließlich "ns" mit der
Resolveradresse zurück. Über 9.9.9.11 kamen zusätzlich "ip" und
"ecs" "203.0.113.0/24/24", also das eigene Netz mit gekürzter Adresse. Derselbe Betreiber, dieselbe
Datenschutzerklärung, ein Zeichen Unterschied in der Adresse. Das ist der sauberste Nachweis für ECS, weil alle
anderen Bedingungen gleich bleiben.
Die gezeigte Netzangabe ist ein Beispiel. In Ihrer Ausgabe steht Ihr eigenes Netz.
Welcher Knoten eines Anycast-Netzes antwortet
Anycast heißt: viele Server, eine Adresse. Welcher ist es gerade?
dig +nsid @9.9.9.9 example.com A
Im Abschnitt OPT PSEUDOSECTION erscheint eine Zeile
; NSID: ... ("res701.qfra3"). Genau das wurde am 7. September 2026 gemessen; die Kennung deutet auf einen
Standort in Frankfurt. Fehlt die Zeile, sendet der Server keine Kennung. Der Vorteil gegenüber der älteren Abfrage
dig @server CH TXT id.server: Die Kennung reist in der normalen Antwort mit.
Kommt die Antwort wirklich verschlüsselt?
Eine verschlüsselte Verbindung allein sagt nichts, solange niemand prüft, wer am anderen Ende sitzt. Genau das
ist der häufigste Fehler in Anleitungen: Sie zeigen einen erfolgreichen Handschlag und nennen ihn Sicherheit.
DNS over TLS in einem Befehl
Kommt die Antwort tatsächlich durch den TLS-Kanal?
dig +tls @dns.quad9.net example.com A
Entscheidend ist die vorletzte Zeile. Gemessen am 7. September 2026:
;; SERVER: 149.112.112.112#853(dns.quad9.net) (TLS). Das (TLS) und der Port
853 sind der Beleg. Steht dort kein (TLS), lief die Abfrage im Klartext.
Der häufigste Fehler: verschlüsselt, aber ungeprüft
Verschlüsselung ohne Zertifikatsprüfung schützt gegen wen genau?
echo QUIT | openssl s_client -connect dns.quad9.net:853 \
-servername dns.quad9.net -alpn dot 2>&1 \
| grep -E 'subject=|Verification|ALPN protocol'
Drei Zeilen müssen zusammenkommen. Gemessen am 7. September 2026:
subject=C=CH, ST=Zurich, L=Zürich, O=Quad9, CN=dns.quad9.net, dann Verification: OK, dann
ALPN protocol: dot. Erst alle drei zusammen belegen: verschlüsselt, richtiger Gegenüber, richtiges
Protokoll. Ein Handschlag allein belegt nur, dass irgendjemand geantwortet hat.
Mit kdig aus dem Paket knot-dnsutils (Debian, Ubuntu) beziehungsweise
knot-utils (Fedora, RHEL) geht dasselbe kürzer:
kdig -d @dns.quad9.net +tls-ca +tls-host=dns.quad9.net example.com A. Achtung: +tls allein
prüft das Zertifikat nicht, dafür braucht es +tls-ca.
Die Gegenprobe, die scheitern muss
Prüft mein Werkzeug wirklich, oder nickt es alles ab?
echo QUIT | openssl s_client -connect 9.9.9.9:853 \
-servername dns.quad9.net -alpn dot -verify_return_error \
-verify_hostname wrong.example.com 2>&1 | grep -iE 'verif|error' | head -3
Dieser Befehl muss fehlschlagen. Erwartet wird eine Zeile mit einem Prüffehler zum Hostnamen. Kommt hier
eine erfolgreiche Prüfung zurück, ist Ihre gesamte übrige Prüfung wertlos. Eine Negativkontrolle, die nicht scheitert,
misst nichts.
DNS over QUIC prüfen
Spricht der Endpunkt wirklich DoQ, oder nur beinahe?
openssl s_client -quic -alpn doq -connect dns.quad9.net:853 \
-servername dns.quad9.net < /dev/null 2>&1 \
| grep -E 'ALPN protocol|Verification'
Gemessen am 7. September 2026: Verification: OK und ALPN protocol: doq. Achtung
bei der Auslegung: Ein ausgehandeltes doq beweist nur, dass der Server das Protokoll annimmt. Ob danach
auch eine Antwort kommt, ist eine zweite Frage. Genau dieser Unterschied trat bei UncensoredDNS auf, wo der Handschlag
gelang, eine echte Abfrage aber unbeantwortet blieb.
Braucht OpenSSL 3.5 oder neuer. Version prüfen mit openssl version.
DNS over HTTPS, der bequeme und der genaue Weg
Antwortet der DoH-Endpunkt so, wie RFC 8484 es vorschreibt?
dig +https @dns.quad9.net example.com A
curl -sS -o antwort.bin -w '%{http_code} %{content_type} %{size_download}\n' \
-H 'accept: application/dns-message' \
'https://dns.quad9.net/dns-query?dns=AAABAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB'
Der erste Befehl ist der bequeme: dig spricht DoH selbst und zeigt eine lesbare Antwort.
Der zweite zeigt, was wirklich über die Leitung geht. Gemessen am 7. September 2026:
200 application/dns-message 65. Die Datei enthält eine binäre DNS-Nachricht, kein JSON. Die ersten Bytes
lauten 00 00 81 80 00 01 00 02: Kennung null, wie RFC 8484 es verlangt, Antwortbit gesetzt, eine Frage,
zwei Antworten.
Die Base64-Zeichenkette im Beispiel steht so im RFC 8484 selbst und fragt nach
www.example.com. Manche Anbieter bieten zusätzlich eine JSON-Schnittstelle an; die ist bequem, aber kein
Standard und funktioniert nicht überall gleich.
Warum die Testdomains keine Webseite haben
Ein Hinweis zu den Testdomains: sigok.ippacket.stream, sigfail.ippacket.stream, dnssec-failed.org und qnamemintest.internet.nl haben keine Webseite, die man aufrufen könnte. Sie existieren nur im DNS. Bei dnssec-failed.org ist das sogar zwingend: Wenn Ihr Resolver richtig arbeitet, kann er den Namen gar nicht auflösen, und dann lässt sich auch keine Seite öffnen. Das Ausbleiben der Seite ist hier der Beweis, nicht der Fehler.