Оновлення: я повинен був перевірити журнал зміни 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 )
The 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 або щось інше.