Wie debuggen Sie local mit defektem dnssec

Update: Ich hätte das BIND-Änderungsprotokoll zu Beginn überprüfen sollen. Ich sehe diesen Eintrag zwischen den beiden Versionen, die ich verwendete:

4957. The default setting for "dnssec-validation" is now "auto", which activates DNSSEC validation using the IANA root key. (The default can be changed back to "yes", which activates DNSSEC validation only when keys are explicitly configured in named.conf, by building BIND with "configure --disable-auto-validation".) [GL #30] 

Offenbar war DNSSEC bis vor kurzem standardmäßig deaktiviert, zumindest in meiner Konfiguration, die keine Schlüssel enthält, die "explizit in named.conf konfiguriert" sind.

Ich lasse die Frage offen, weil ich immer noch herausfinden möchte, warum DNSSEC funktioniert, wenn ich named.confauf Google (8.8.8.8) hingewiesen habe, aber nicht, wenn ich auf meinen lokalen Router (192.168.1.1) verwiesen habe.

Nach einem kürzlich durchgeführten Upgrade meiner Arch Linux-Pakete stellte ich fest, dass DNS-Anforderungen nicht mehr funktionieren. Ich habe das Problem auf meine lokale BIND- Konfiguration zurückgeführt. (Ich habe /etc/resolv.confauf localhost (127.0.0.1) hingewiesen, sodass ich DNSBL- Abfragen abfangen und direkt an die relevanten Server weiterleiten kann, wodurch URIBL_BLOCKED-Regeleinträge in Spamassassin vermieden werden. )

Die namedAusgabe erwähnte "gebrochene Vertrauenskette", die mich zu diesem Thread führte . Dann habe ich die Idee zu spielen, um mit dnssec aktivieren und dnssec-validate Optionen in named.conf. Wenn Sie beide Optionen auf "Ja" setzen, funktioniert es wieder, aber ironischerweise bewirkt diese Kombination, dass DNSSEC deaktiviert wird . Anscheinend dnssec-enableauf "Ja" und dnssec-validate"Auto" zu setzen, erzwingt DNSSEC und stellt das Problem für mich wieder her.

Das Problem wird behoben, wenn ich die "Forwarder" -Zeile von 192.168.1.1 (meinem Router) auf 8.8.8.8 (Googles öffentliches DNS) ändere.

Hier ist mein named.conf:

options { # 10 Aug 2018 setting dnssec-validation to "no" or "yes" # makes it work; "auto" breaks it dnssec-validation yes;  directory "/var/named"; pid-file "/run/named/named.pid";  allow-recursion { 127.0.0.1; }; allow-transfer { none; }; allow-update { none; };  version none; hostname none; server-id none;  forward only; forwarders { # problem goes away if I change this to 8.8.8.8 192.168.1.1; }; };  zone "localhost" IN { type master; file "localhost.zone"; };  zone "0.0.127.in-addr.arpa" IN { type master; file "127.0.0.zone"; };  zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" { type master; file "localhost.ip6.zone"; };  zone "255.in-addr.arpa" IN { type master; file "empty.zone"; };  zone "0.in-addr.arpa" IN { type master; file "empty.zone"; };  zone "." IN { type hint; file "root.hint"; }; 

Dies ist die Ausgabe, namedwenn ich eine fehlgeschlagene Suche durchführe. Ich füge die Ausgabe für zwei separate Suchvorgänge hinzu, da sie etwas unterschiedlich zu sein scheinen, nur der zweite erwähnt "gebrochene Vertrauenskette":

$ ping google.com ping: google.com: Name or service not known  $ sudo named -d 2 -f -g -u named ... 14-Aug-2018 23:24:55.701 fetch: google.com/A 14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150b010 google.com (bucket 3) 14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150b010 google.com (bucket 3) 14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns1.google.com (bucket 0) 14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns2.google.com (bucket 11) 14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns3.google.com (bucket 2) 14-Aug-2018 23:24:55.744 delete_node(): 0x7f82b150d010 ns4.google.com (bucket 5) 14-Aug-2018 23:24:55.744 fetch: com/DS 14-Aug-2018 23:24:55.746 no valid RRSIG resolving 'com/DS/IN': 192.168.1.1#53 14-Aug-2018 23:24:55.746 delete_node(): 0x7f82b150b010 google.com (bucket 3) 14-Aug-2018 23:24:55.746 no valid DS resolving 'google.com/A/IN': 192.168.1.1#53 14-Aug-2018 23:24:55.746 client @0x7f82ac0aa5e0 127.0.0.1#54841 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:10721 14-Aug-2018 23:24:55.746 fetch completed at resolver.c:4017 for google.com/A in 0.045257: SERVFAIL/no valid DS [domain:.,referral:1,restart:2,qrysent:1,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1,qminsteps:1] 14-Aug-2018 23:24:55.747 client @0x7f82a402d9d0 127.0.0.1#54841 (google.com): servfail cache hit google.com/A (CD=0) 14-Aug-2018 23:24:55.747 client @0x7f82a402d9d0 127.0.0.1#54841 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:6112 ... 15-Aug-2018 00:20:10.998 fetch: google.com/A 15-Aug-2018 00:20:11.040 delete_node(): 0x7f267b6e7160 ns2.google.com (bucket 0) 15-Aug-2018 00:20:11.040 delete_node(): 0x7f267b6e70f0 ns1.google.com (bucket 11) 15-Aug-2018 00:20:11.041 delete_node(): 0x7f267b6e7160 ns4.google.com (bucket 14) 15-Aug-2018 00:20:11.041 delete_node(): 0x7f267b6e70f0 ns3.google.com (bucket 9) 15-Aug-2018 00:20:11.041 validating google.com/A: bad cache hit (com/DS) 15-Aug-2018 00:20:11.041 broken trust chain resolving 'google.com/A/IN': 192.168.1.1#53 15-Aug-2018 00:20:11.041 client @0x7f26740aa5e0 127.0.0.1#58953 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:10721 15-Aug-2018 00:20:11.041 fetch completed at resolver.c:5276 for google.com/A in 0.042605: broken trust chain/broken trust chain [domain:.,referral:1,restart:1,qrysent:1,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1,qminsteps:1] 15-Aug-2018 00:20:11.041 client @0x7f2674055aa0 127.0.0.1#58953 (google.com): servfail cache hit google.com/A (CD=0) 15-Aug-2018 00:20:11.041 client @0x7f2674055aa0 127.0.0.1#58953 (google.com): query failed (SERVFAIL) for google.com/IN/A at query.c:6112 

Mit dem oben genannten named.confkann ich auflösen dnssec-failed.org, was, wie ich es verstehe, eine schlechte Sache ist:

$ host dnssec-failed.org 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases:   dnssec-failed.org has address 69.252.80.75 

Ich kann dieses Problem nicht lösen, wenn ich 8.8.8.8 als Weiterleitung verwende.

Ich bin neugierig auf die Ursache des Problems und die Lösung, aber ich bin auch gespannt, wie ich einen fehlgeschlagenen Host-Lookup richtig debuggen sollte. Vielleicht sind alle notwendigen Informationen in der Debugging-Ausgabe enthalten, die ich gepostet habe, oder vielleicht gibt es ein Tool, das ich nicht kenne, z. B. traceroutefür DNS oder etwas anderes.