Как отладить локальное имя с разбитым dnssec

Обновление: я должен был проверить журнал изменений BIND, чтобы начать, я вижу эту запись между двумя версиями, которые я использовал:

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] 

Очевидно, DNSSEC до недавнего времени по умолчанию был "выключен", по крайней мере, в моей конфигурации, в которой нет ключей, "явно настроенных в named.conf".

Я оставляю вопрос открытым, потому что я все еще хотел бы выяснить, почему DNSSEC работает, когда я named.confуказал на Google (8.8.8.8), а не когда я указал на мой локальный маршрутизатор (192.168.1.1).

После недавнего обновления моих пакетов Arch Linux я обнаружил, что DNS-запросы больше не работают. Я проследил проблему до моей локальной конфигурации BIND . (Я /etc/resolv.confуказал на localhost (127.0.0.1), чтобы я мог перехватывать DNSBL- запросы и перенаправлять их непосредственно на соответствующие серверы, избегая, таким образом, попаданий правила URIBL_BLOCKED в Spamassassin )

На namedвыходе упоминается «сломанная цепочка доверия», что привело меня к этой теме . Тогда у меня появилась идея поиграться с опциями dnssec-enable и dnssec-validate в named.conf. Если для обеих опций выбрано «да», это снова сработает, но по иронии судьбы эта комбинация приводит к отключению DNSSEC . Видимо, установка dnssec-enable«да» и dnssec-validate«авто» вызывает DNSSEC и воссоздает проблему для меня.

Проблема исчезает, когда я меняю строку «пересылки» с 192.168.1.1 (мой маршрутизатор) на 8.8.8.8 (общедоступный DNS Google).

Вот мой 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"; }; 

Это вывод, namedкогда я делаю неудачный поиск. Я включил вывод для двух отдельных поисков, потому что они кажутся немного отличающимися, только второй упоминает «сломанную цепочку доверия»:

$ 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 

С вышеизложенным named.confя могу решить dnssec-failed.org, что, как я понимаю, это плохо:

$ 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 

Я не могу решить эту проблему, если я использую 8.8.8.8 в качестве сервера пересылки.

Мне любопытно узнать причину проблемы и ее решение, но мне также любопытно, как правильно отладить неудачный поиск хоста. Возможно, вся необходимая информация содержится в результатах отладки, которые я разместил, или, может быть, есть инструмент, о котором я не знаю, например, tracerouteдля DNS или чего-то еще.