Назад | Перейти на главную страницу

bind9 неправильно разрешает dnssec

У меня проблема с настройкой DNS-сервера. Мой сервер привязки в основном является кеш-сервером, но также обслуживает некоторые внутренние домены. Он слушает только мою частную сеть и обслуживает только запросы оттуда.

Сегодня я хотел включить привязку для проверки DNSSEC, но почему-то она делает это неправильно. Если я разрешаю имя хоста на самой машине bind linux, недопустимый DNSSEC отлично отображается как таковой. Но если я снова попытаюсь разрешить тот же домен, используя ту же команду dig на другом моем компьютере в сети, проверка DNSSEC не завершится ошибкой, и домен будет разрешен нормально. Я хочу, чтобы он отправил правильный SERVFAIL другим моим DNS-клиентам в сети.

Вот вся информация, которая может вам понадобиться (версия привязки, конфигурации и т. Д.). Я добавлю свои раскопки в конце.

Версия ОС

root@thor:/etc/bind# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 8.5 (jessie)
Release:        8.5
Codename:       jessie

root@thor:/etc/bind# uname -a
Linux thor.home.intranet 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

привязать версию

BIND 9.9.5-9+deb8u6-Debian (Extended Support Version)

named.conf

include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";

named.conf.options

options {
        directory "/var/cache/bind";

        forwarders {
                208.67.222.222; # resolver1.opendns.com
                208.67.220.220; # resolver2.opendns.com
#               8.8.8.8; # google-public-dns-a.google.com
#               8.8.4.4; # google-public-dns-b.google.com
        };

        dnssec-enable yes;
        dnssec-validation auto;
        auth-nxdomain no;    # conform to RFC1035

        listen-on {
                127.0.0.1;
                192.168.10.36;
        };

        recursion yes;
        allow-recursion { 127.0.0.0/8; 192.168.10.0/24; };

        max-ncache-ttl 0;
};

named.conf.local

zone "intranet" {
        type master;
        file "/etc/bind/master/db.intranet";
};

zone "10.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/master/db.10.168.192";
};

zone "box" {
        type master;
        file "/etc/bind/master/db.box";
};

named.conf.default-зоны

// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

Результаты DNS
Если я запрашиваю недопустимый домен на моем сервере (тор), я получаю следующее:

user@thor:/etc/bind$ dig @192.168.10.36 sigfail.verteiltesysteme.net

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @192.168.10.36 sigfail.verteiltesysteme.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11750
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; Query time: 256 msec
;; SERVER: 192.168.10.36#53(192.168.10.36)
;; WHEN: Fri Jul 08 21:27:37 CEST 2016
;; MSG SIZE  rcvd: 57

Если я сделаю точно такой же запрос на моем клиенте под управлением Windows 10 с использованием cygwin, я получу следующее:

user@COMPUTER:~$ dig @192.168.10.36 sigfail.verteiltesysteme.net

; <<>> DiG 9.10.3-P4 <<>> @192.168.10.36 sigfail.verteiltesysteme.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52681
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN     A       134.91.78.139

;; AUTHORITY SECTION:
verteiltesysteme.net.   3600    IN      NS      ns1.verteiltesysteme.net.
verteiltesysteme.net.   3600    IN      NS      ns2.verteiltesysteme.net.

;; ADDITIONAL SECTION:
ns1.verteiltesysteme.net. 2910  IN      A       134.91.78.139
ns1.verteiltesysteme.net. 2910  IN      AAAA    2001:638:501:8efc::139
ns2.verteiltesysteme.net. 2910  IN      A       134.91.78.141
ns2.verteiltesysteme.net. 2910  IN      AAAA    2001:638:501:8efc::141

;; Query time: 52 msec
;; SERVER: 192.168.10.36#53(192.168.10.36)
;; WHEN: Fr Jul 08 21:27:46 CEST 2016
;; MSG SIZE  rcvd: 197

Я надеюсь, что вы можете мне помочь.

заранее спасибо


-- РЕДАКТИРОВАТЬ --
Благодаря @ HåkanLindqvist я заметил, что конфигурация сильно запуталась. Чтобы немного почистить вещь и избавиться от всех этих ошибок, я выбросил всю пересылку и разрешил теперь самостоятельно. Это не должно иметь большого значения, поскольку сервер все равно кэширует это.
Мой named.conf.options теперь выглядит так:

options {
        directory "/var/cache/bind";

        dnssec-enable yes;
        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on {
                127.0.0.1;
                192.168.10.36;
        };

        recursion yes;
        allow-recursion { 127.0.0.0/8; 192.168.10.0/24; };

        max-ncache-ttl 0;
};

В журнале больше нет нечетных ошибок, и неверные подписи теперь корректно регистрируются:

Jul  9 00:33:05 thor named[2940]: validating @0x7fd2d0391140: sigfail.verteiltesysteme.net A: no valid signature found
Jul  9 00:33:05 thor named[2940]: error (no valid RRSIG) resolving 'sigfail.verteiltesysteme.net/A/IN': 134.91.78.141#53

Но моя проблема с противоречивыми результатами все еще остается. Оба клиента используют один и тот же сервер привязки:

компьютер:

user@COMPUTER:~$ dig +short @192.168.10.36 hostname.bind CH TXT
"thor.home.intranet"
user@COMPUTER:~$ dig +short @192.168.10.36 version.bind CH TXT
"9.9.5-9+deb8u6-Debian"

сервер:

user@thor:/etc/bind# dig @192.168.10.36 +short hostname.bind CH TXT
"thor.home.intranet"
user@thor:/etc/bind# dig @192.168.10.36 +short version.bind CH TXT
"9.9.5-9+deb8u6-Debian"

Но результаты все равно разные.
компьютер:

user@COMPUTER:~$ nslookup sigfail.verteiltesysteme.net
Server:         192.168.10.36
Address:        192.168.10.36#53

Non-authoritative answer:
Name:   sigfail.verteiltesysteme.net
Address: 134.91.78.139

сервер:

root@thor:/etc/bind# nslookup sigfail.verteiltesysteme.net
Server:         192.168.10.36
Address:        192.168.10.36#53

** server can't find sigfail.verteiltesysteme.net: SERVFAIL

Важно отметить (я думаю): даже если я отправлю запрос на свой компьютер, мой сервер скажет в журналах, что нет действительной подписи. Таким образом, он окончательно распознает, что проверка DNSSEC не проходит .. Но он все равно отправляет NOERROR на мой компьютер.


- РЕДАКТИРОВАТЬ2 - Даже с явно установленным флагом EDNS я все равно получаю результат.

user@COMPUTER:~$ dig @192.168.10.36 +dnssec sigfail.verteiltesysteme.net

; <<>> DiG 9.10.3-P4 <<>> @192.168.10.36 +dnssec sigfail.verteiltesysteme.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48091
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sigfail.verteiltesysteme.net.  IN      A

;; ANSWER SECTION:
sigfail.verteiltesysteme.net. 60 IN     A       134.91.78.139
sigfail.verteiltesysteme.net. 60 IN     RRSIG   A 5 3 60 20200610081125 20150611081125 30665 verteiltesysteme.net. //This+RRSIG+is+deliberately+broken///For+more+informati on+please+go+to/http+//dnssec+vs+uni/hyphen/+due+de////r eplace+/hyphen/+with+character////////////////////////// //8=

;; AUTHORITY SECTION:
verteiltesysteme.net.   3600    IN      NS      ns2.verteiltesysteme.net.
verteiltesysteme.net.   3600    IN      NS      ns1.verteiltesysteme.net.
verteiltesysteme.net.   3600    IN      RRSIG   NS 5 2 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. s4iS0q402GTqtpy1WWspX1KHY3hb0/SOq79qWzRL5PFacAAKK+2ltxWW PTuwsYOWP3l+uq7xu80G0UQNtWPmISa2SYnktvXoZWbdy8F7q8GOH5xw 2t+JokxheEz5Xe4Xy7TmONIxVGq7M9FX4hDBva62PztcGq7UMZMWgyNs P/o=

;; ADDITIONAL SECTION:
ns1.verteiltesysteme.net. 69    IN      A       134.91.78.139
ns1.verteiltesysteme.net. 69    IN      AAAA    2001:638:501:8efc::139
ns2.verteiltesysteme.net. 69    IN      A       134.91.78.141
ns2.verteiltesysteme.net. 69    IN      AAAA    2001:638:501:8efc::141
ns1.verteiltesysteme.net. 69    IN      RRSIG   A 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. kIcbu+YRC6xby461JYrNE3WSOQmTM6UstxKYo8uO1mEysvfDUs23Yuv6 nG+yMo3enmdIg89pPuLWIsz16uYxswl4DlplCYYPP9nT4d+9bjbMHu5S 7hi/uTlYEFwUCDlyQn38sEwnDHwbBnuW0uvYwV/TPTTjtcfYEw0R8zGI QQU=
ns1.verteiltesysteme.net. 69    IN      RRSIG   AAAA 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. PzZiFVbjYHb1+xpIfZGbbtogY94uNvpqHBBibk0Sp7n5BLz4PJZ+dJYc rlikoNK1KyhnHugqCzh6Cr/t23lpioXUPjMWHFYcHsV4kcldTzt7Pl9Q 8h/IvlvtC33TYXnopmmGoV9vbjgpmgpAt//dY8UdNlXD/Dh6CDver+XT 34A=
ns2.verteiltesysteme.net. 69    IN      RRSIG   A 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. PVIDSVFi0GLHavnTFj2JnHn+1A/wOAKS8fMzavMhkFycWjudxDuC19uW Ak9vCV5dR/3ZW4UGQUjZFgVI45fQP2yCJ5H98Z7vfn4FF9gxKwGy+TDt dLeOzcdorOF70aYHEWyYWK5tcq1SqXLXJQMp3G/MY362vqCzbFiIUk32 3q4=
ns2.verteiltesysteme.net. 69    IN      RRSIG   AAAA 5 3 3600 20200610081125 20150611081125 30665 verteiltesysteme.net. Fhg3JLyBsuXG4UCvG3y48gL8lz2Tu5Hx+ClxoXf4NjWs2MK/XScHEzwb UdOhz4aHnZbfWORoXHSD3DR92vBooix+522Z2GhCg1eiXBP66VDyypqT Ar7kUTXJHmsa70k/ubYHC6P6Imy68CbIi5xPr+OFZHrL/CTv9fcLVg3A ikU=

;; Query time: 53 msec
;; SERVER: 192.168.10.36#53(192.168.10.36)
;; WHEN: Sa Jul 09 01:07:08 CEST 2016
;; MSG SIZE  rcvd: 1277

- РЕДАКТИРОВАТЬ3 - Я включил журнал запросов на уровне отладки 10, чтобы убедиться, что отправляется правильный запрос. Следующие три записи создаются запросом "dig @ 192.168.10.36 + dnssec sigfail.verteiltesysteme.net"

09-Jul-2016 01:23:50.419 client 192.168.10.36#47038 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
09-Jul-2016 01:23:59.620 client 192.168.10.2#64858 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)
09-Jul-2016 01:24:32.417 client 192.168.10.2#54071 (sigfail.verteiltesysteme.net): query: sigfail.verteiltesysteme.net IN A +ED (192.168.10.36)

192.168.10.2 - мой компьютер, 192.168.10.36 - сервер, на котором выполняется привязка.
Я дополнительно загрузил текущую версию привязки с isc.org, как вы предлагали, и запустил ее. Результат такой же, как и с cygwin. Третий результат в журнале выше генерируется связыванием isc.org.


- РЕДАКТИРОВАТЬ 4 -

Как очень позднее, но последнее изменение: я наконец нашел решение. Я использовал Avast в качестве своего антивирусного ПО, которое, по-видимому, перехватывало трафик DNS и перенаправляло его на свой «безопасный сервер» Avast. Удаление Avast и запуск Защитника Windows решили проблему.

В forwarders которые вы настроили, вызовут проблемы только при запуске проверяющего распознавателя, поскольку серверы Opendns не взаимодействуют при выполнении проверки DNSSEC.

Я полагаю, это в любом случае может сработать для вас, поскольку вы не указали forward only, так названный, будет возвращаться к разрешению вещей самостоятельно более или менее все время, поскольку пересылки продолжают не давать полезных результатов. Но даже если это вроде сработает, ваши журналы все равно будут беспорядочными.

Чтобы продемонстрировать, если я установил forward only и используйте те же пересылки, вот что происходит:

named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.220.220#53
named[20057]: error (no valid RRSIG) resolving 'net/DS/IN': 208.67.222.222#53
named[20057]: error (no valid DS) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.222.222#53
named[20057]: validating @0x7f36805ecb10: sigfail.verteiltesysteme.net A: bad cache hit (net/DS)
named[20057]: error (broken trust chain) resolving 'sigfail.verteiltesysteme.net/A/IN': 208.67.220.2

Как видите, это не удается, но по совершенно неправильной причине. (Он потерпел неудачу в DS для net, а не при проверке действительно сломанных подписей на sigfail.verteiltesysteme.net.)

Я ожидаю, что ваши журналы в настоящее время представляют собой смесь вещей, подобных приведенному выше, в сочетании с действительно релевантными записями из того, когда named возвращается к запросам правильно работающих серверов. Исправление этого должно помочь в устранении неполадок.

Что касается противоречивых результатов, я не уверен, что что-то в вашей конфигурации действительно может это объяснить. Вы уверены, что это действительно тот же именованный экземпляр, который ответил на запрос? Никаких странных правил NAT или чего-то в этом роде, которые заставляли бы клиентов прозрачно разговаривать с каким-то другим сервером или еще чем-то?

Запросы вроде dig @192.168.10.36 version.bind CH TXT и dig @192.168.10.36 hostname.bind CH TXT может разоблачить происходящее.

Это старый пост, но для тех, кто все еще испытывает трудности и сделал все, что мог, но все еще анализатор на https://dnssec-analyzer.verisignlabs.com/ не может видеть вашу запись DS, потому что вам нужно вставить свои записи DS, которые уже были созданы: в: Домен / менеджер хоста / панель вашего Регистратор домена не только на вашем DNS.

На панели управления регистратора домена найдите запись / информацию DNSSEC или запись о подписывающем делегировании, там вы увидите форму, в которую вы можете добавить информацию о своем DS. Если вы не работаете, значит, вы являетесь DNS-сервером, тогда информация DS будет предоставлена ​​вам вашим провайдером DNS.

Пример: