BIND9 DNS Sec не работает при новом COLO

Я работаю над созданием нового сайта, включая новую инфраструктуру и услуги. У меня есть Bind DNS-сервер, работающий на CentOS 7.3, и я недавно заметил, что рекурсивный поиск внешних ресурсов не работает. Этого не происходит в нашей устаревшей инфраструктуре.

И у нового коло, и у старого коло есть доступ в Интернет. Я могу маршрутизировать внешние ресурсы в обоих (например, 8.8.8.8). Хотя ISP и маршрут будут отличаться.

Чтобы попытаться устранить неполадки и устранить различия в конфигурации между самими новыми / старыми DNS-серверами, я установил две новые виртуальные машины CentOS 7. Один в старом и один в новом. Я использовал один и тот же образ и метод для создания обоих, чтобы они были одинаковыми (без имени хоста / ip) после сборки.

Я установил Bind (версия 9.9.4) и настроил оба как простые рекурсивные DNS-серверы (без конфигурации для конкретной зоны или иначе). Оба имеют конфигурацию CentOS по умолчанию: /etc/ named.conf / var / named /

Единственные изменения, которые я внес, были в /etc/ named.conf:

• удален порт прослушивания 53 {127.0.0.1; }; ' (это заставляет его прослушивать порт 53 на всех устройствах).
• установить порт 53 для прослушивания v6 {нет; }; (Не слушайте ipv6)
• установить allow-query {любой; }; (разрешить запрос любому хосту)

В результате получается файл /etc/ named.conf по умолчанию, который выглядит так:

//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// See the BIND Administrator's Reference Manual (ARM) for details about the
// configuration located in /usr/share/doc/bind-{version}/Bv9ARM.html

options {
    listen-on-v6 port 53 { none; };
    directory   "/var/named";
    dump-file   "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query     { any; };

    /*
     - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
     - If you are building a RECURSIVE (caching) DNS server, you need to enable
       recursion.
     - If your recursive DNS server has a public IP address, you MUST enable access
       control to limit queries to your legitimate users. Failing to do so will
       cause your server to become part of large scale DNS amplification
       attacks. Implementing BCP38 within your network would greatly
       reduce such attack surface
    */
    recursion yes;

    dnssec-enable no;

    managed-keys-directory "/var/named/dynamic";

    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};

zone "." IN {
    type hint;
    file "named.ca";
};

include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

Я также настроил каждый соответствующий сервер для разрешения против самого себя и только от себя в /etc/resolv.conf.

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

• физический / серверный гипервизор
• Colo / network / ISP

Я тестировал рекурсивные DNS-запросы на обоих (к таким ресурсам, как google.com, amazon.com, dropbox.com и т. Д.).

Как и в производственной среде, в тестовой среде рекурсивные запросы работают из старой инфраструктуры, но не из новой. Трассировка dig + для сервера в новой инструкции указывает, что он не может получить IP-адрес корневого NS:

dig @10.50.60.111 google.com +trace +additional

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> @10.50.60.111 google.com +trace +additional
; (1 server found)
;; global options: +cmd
.           518400  IN  NS  b.root-servers.net.
.           518400  IN  NS  d.root-servers.net.
.           518400  IN  NS  i.root-servers.net.
.           518400  IN  NS  g.root-servers.net.
.           518400  IN  NS  j.root-servers.net.
.           518400  IN  NS  a.root-servers.net.
.           518400  IN  NS  l.root-servers.net.
.           518400  IN  NS  k.root-servers.net.
.           518400  IN  NS  e.root-servers.net.
.           518400  IN  NS  h.root-servers.net.
.           518400  IN  NS  f.root-servers.net.
.           518400  IN  NS  c.root-servers.net.
.           518400  IN  NS  m.root-servers.net.
dig: couldn't get address for 'b.root-servers.net': no more

Ответ на этот вопрос должен быть предоставлен самим локальным сервером связывания, поскольку мы используем корневые подсказки по умолчанию, упакованные в /var/ named/root.ca

Быстрый просмотр журнала (/var/ named/data/ named.run) показал, что сервер в новой инфра-структуре, похоже, игнорирует эти ответы, потому что он получил «небезопасный ответ»:

validating @0x7fc3c8055510: . NS: got insecure response; parent indicates it should be secure
error (insecurity proof failed) resolving './NS/IN': 198.41.0.4#53

Но на сервере в старой инфраструктуре этой проблемы нет. Я попытался отключить dnssec (в /var/ named.conf), а также передать + nodnssec в раскопки. Это приводит к продвижению на один шаг вперед в рекурсии, но нам по-прежнему не удается получить NS для com. домен по той же причине. Хотя в этом случае ответ будет исходить от корневых серверов.

Я искал ответ и буду продолжать искать. Но я не понимаю, какие факторы могут привести к возникновению этой ошибки в одной сети / сети, а не в другой, если в остальном конфигурация Server / BIND такая же. Если у кого-то есть идеи о том, что может вызвать это, или где я должен искать дальше, я хотел бы это услышать.

В общем, я пытаюсь разобраться в следующем: может это все-таки простая неверная конфигурация привязки? Может ли это быть вызвано конфигурацией локальной сети? Нужно ли мне настраивать что-то ISP или внешний DNS-сервер, чтобы это работало с новым ISP / IP?