Обновление: я должен был проверить журнал изменений 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 на "yes" и dnssec-validate на "auto" вызывает 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 или что-то еще.