Für eine manuelle und detailierte Untersuchung bieten sich Command-Line Tools an. Dig und drill verfügen über Debug-Level-Einstellungen mit denen die DNSSEC-Auflösung und -Validierung schrittweise nachvollzogen werden kann:

• Dig:
  • http://www.isc.org
  • http://www.nlnetlabs.nl/publications/dnssec_howto/index.html#x1-560007

• Drill:
  • http://www.nlnetlabs.nl/ldns/
  • http://www.nlnetlabs.nl/publications/dnssec_howto/index.html#x1-550006

Beispiele (Dig):

Hinweis: Einige Beispiele verwenden die DNSSEC signierte Zone dnssec-faq.de unter der diese FAQ zu erreichen ist.

• Abfrage von Zoneneinträgen inkl. DNSSEC Signierung. Falls die Domain DNSSEC signiert ist, werden auch RRSIG, NSEC und DNSKEY Records ausgegeben: 'dig dnssec-faq.de. any'
• Abfrage von DS-Einträgen in der übergeordneten Zone: 'dig @a.nic.de -t DS dnssec-faq.de'
  Während des .de DNSSEC Testbeds muss an dieser Stelle ein .de Nameserver des Testbeds befragt werden:
  'dig @auth-fra.dnssec.denic.de -t DS dnssec-faq.de.'

Beispiele (Drill):

• Verfolgen der Signaturkette einer Domain bis zu einem ggf. vertrauenswürdigen Schlüssel: 'drill -DS dnssey-faq.de'
  Während des .de DNSSEC Testbeds enthalten die per DNS veröffentlichten .de Nameserver keine DS Records. Dementsprechend findet Drill bei Frage nach den DS Records für dnssec-faq.de keinen Einträge und bricht die Verfolgung ab. Drill verwendet zur Abfrage der Daten die für das Betriebssystem eingetragenen DNS Resolver. Falls diese Resolver zur Verwendung des .de DNSSEC Testbeds konfiguriert sind, ist eine Verfolgung der Signierung bis zu .de möglich.
• Verfolgen der Signaturkette in voll funktionalen DNSSEC Deployments: 'drill -DS dnssec.se'
  Drill kann in diesem Fall die Signaturen bis zu .se verfolgen. Die public keys für .se müssten für eine vollständige Validierung explizit als vertraute Schlüssel hinterlegt werden.
• Erstellen eines trusted-Key files für drill:
  Achtung: Das format der Datei unterscheidet sich z.B. vom Format der für Bind verwendeten trusted keys. Auf exakte Einhaltung des Formats ist zu achten, da drill ansonsten angibt, keine trusted-keys in der Datei zu finden.
  Format: 'zone. IN DNSKEY 257 3 5 key', wobei keine Zeilenumbrüche erlaubt sind.
  Beispiel für .se:
  se. IN DNSKEY 257 3 5 AwEAAbaxTum9L7z1DmPiXPk0QZ2/qUM3to210Caey/ycZuvQ8Mh/dgGpwBmyZB9xZSkaCLa2Mw6pmDLrjK9hWOffq5PXRVm9RrcA/eIEBEvbQzkY5sFkWAczNAs58Oscxi+/Gd5KfuVi3lJpYgJwwa2JB4doZ00IXywcCn0VTz0Hsl/lqpA2Bqj+e+ATzA5hWyiNyHPjiYvyMCkSXTiGgFVVuG8H3N6Us8uSABuO2UoFQeQi6YikIiCbf1FfCzr4vBIRXW6MaDs8kqAAadKjLk3i39dviL/YeyGUvq9Dan9PsvkwQejKN/7J0yCr2nYXfwGGCHkcBKkagv79EaRlZigUCp8=

Grundsätzlich kann der Fehler mit Hilfe von DNSSEC-Debugging-Tools (dig, drill, o.ae.) genauer eingegrenzt und behoben werden.

Ob eine DNSSEC-Signierung wichtig oder notwendig ist, lässt sich zum aktuellen Zeitpunkt daran entscheiden, wie hoch das Risiko eines gezielten Angriffs auf die DNS-Daten dieser Domain ist. Bietet die Domain ein Ziel für Phishing-Aktivitäten, werden dort Login-Daten von Benutzeraccounts abgefragt oder sonstige Daten eingegeben, die für Dritte von Interesse sein könnten, so ist eine DNSSEC-Signierung sicherlich sinnvoll.

Das Betriebssystem des Rechners kann bei der Anfrage angeben, ob es die DNSSEC-Erweiterungen des DNS-Protokolls versteht und auswerten kann (zu diesem Zweck wird in der Anfrage das DNSSEC OK = DO-Bit gesetzt). Dieses DO-Bit sollte idealerweise durchgängig beginnend mit der ersten Anfrage gesetzt sein. Diese Verhalten lässt sich bei Windows 7 für einzelne Zonen separat einschalten. Das Betriebssystem erkennt danach für diese Zone sowie alle hierarchisch untergeordneten Zonen nur noch Antworten als korrekt an, bei denen das AD-Flag gesetzt ist.

Dies mag für einzelne Zonen (z.B. in einem Intranet) möglich sein, nicht allerdings für übergeordnete Zonen. Würde beispielsweise DNSSEC für .de aktiviert, so würden nicht signierte .de-Domains nicht mehr korrekt aufgelöst. Somit ist DNSSEC in Windows 7 zwar vorhanden, die Verwendung ist aber wohl als nicht praktikabel zu bezeichnen.

DNSSEC-Unterstützung für Linux ist distributionsabhängig und bisher nicht per Default aktiviert. Für eine genauere Übersicht der unterstützten Betriebssysteme siehe:

Weitere Informationen:

• http://www.DENIC.de/fileadmin/Domains/DNSSEC/22090702/DNSSEC_20090702_Dietrich.pdf

ccTLDs

• .bg: produktiv (https://www.register.bg/)
• .br: produktiv (http://registro.br/info/dnssec-policy-en.html)
• .ch/.li: produktiv (http://www.nic.ch/)
• .cz: produktiv (http://www.nic.cz/dnssec/)
• .de: Testbed von 03/2010 bis 12/2010. Danach wird anhand der Ergebnisse über eine Einführung entschieden. (http://www.denic.de/domains/dnssec.html)
• .pr: produktiv (http://dnssec.nic.pr/)
• .se: produktiv (http://www.iis.se/en/domaner/dnssec/)
• .eu: Testbed (http://www.eurid.eu/en/content/eu-plans-support-dnssec)

gTLDs

• .com: In Planung (http://www.verisign.com/domain-name-services/domain-information-center/dnssec-resource-center/)
• .org: Produktiv (http://www.pir.org/dnssec)
• .gov: Produktiv (http://www.dotgov.gov/dnssecinfo.aspx)
• .museum: Produktiv (http://www.nic.museum/) (http://www.icann.org/en/registries/rsep/musedoma-request-2008009-17oct08.pdf)
• . (Root): In Planung (http://www.root-dnssec.org/)
• in-addr.arpa: Das RIPE sowie die ARIN signieren die an sie delegierten Reverse Zonen (http://www.ripe.net/rs/reverse/dnssec/) (http://www.arin.net/resources/dnssec/)

Weitere Informationen / Links zu einzelnen Projekten: http://www.dnssec.net/projects