BIND9 DNS Sec Fails at New COLO

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

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

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

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

Единственные изменения, которые я внес, были в /etc/ named.conf:[1230 visibleremoved 'listen-on port 53 {127.0.0.1; }; ' (это заставляет его прослушивать порт 53 на всех устройствах.)

Это приводит к созданию файла /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 + trace для сервера в новой инструкции указывает, что он не может получить 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. домен по той же причине. Хотя в этом случае ответ будет исходить от корневых серверов.

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

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