bind9 DNS не отвечает на запросы в локальной сети

Я настраиваю bind9 в качестве DNS-сервера для нашей локальной сети. Сервер работает, как ожидалось, для запросов DNS от машины, на которой запущен сервер, но не отвечает на запросы от других машин в сети. Выполняя tcpdump на DNS-сервере, я вижу поступающие запросы от других машин, но не вижу никакого ответа или чего-либо в журналах bind9, чтобы указать на ошибку. Любые предложения о возможных источниках этой проблемы или способах ее устранения были получены с благодарностью!

В деталях:

Запуск bind9 в Ubuntu. Моя конфигурация:

options {
    directory "/etc/bind";
    listen-on port 53 {100.1.1.2; };
    listen-on-v6 port 53 { none; };
    allow-query { any; };
    dnssec-validation no;
};

zone "mydomain.com" IN {
    type master;
    file "mydomain.com.db";
    allow-update { none; };
};

zone "1.1.100.in-addr.arpa" {
    type master;
    file "revp.100.1.1";
};

файл зоны

$ORIGIN mydomain.com.
$TTL    5; 3600
@   IN  SOA dns admin.mydomain.com. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; DNS Servers
            NS      dns

; Machine Names
localhost   IN  A   127.0.0.1
dns     IN  A   100.1.1.2
bar     IN  A   100.1.1.10
baz     IN  A   100.1.1.11

Начиная с named с sudo named -c /etc/bind/named.conf -g -d100. Глядя в журналы, он действительно прослушивает правильный IP-адрес (я вижу listening on IPv4 interface enp6s0, 100.1.1.2#53). Проверяя поиск DNS на том же компьютере, на котором запущен DNS-сервер с dig baz.mydomain.com @100.1.1.2, я получаю ответ от DNS-сервера с соответствующей записью в named журнале. Я также вижу DNS-запрос в sudo tcpdump -i lo -u port 53.

Затем, теперь на панели ПК, я запустил dig baz.mydomaain.com @100.1.1.2. Этот запрос не получает ответа от DNS-сервера, и я ничего не вижу в журналах DNS. Глядя на sudo tcpdump -u port 53 на DNS-сервере, я вижу, что DNS-запросы поступают от bar, но нет ответа, так что это не похоже на проблему с брандмауэром.

Есть предложения по дальнейшим действиям?


networking dns named bind9
person tph43    schedule 02.02.2021    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я бы начал с того, что не использовал адресный блок MCI Communication Services и использовал правильный сетевой блок из RFC1918:

NetRange:       100.0.0.0 - 100.19.255.255
CIDR:           100.16.0.0/14, 100.0.0.0/12
NetName:        V4-VZO
NetHandle:      NET-100-0-0-0-1
Parent:         NET100 (NET-100-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS19262
Organization:   MCI Communications Services, Inc. d/b/a Verizon Business (MCICS)
RegDate:        2010-12-28
Updated:        2018-01-10
Ref:            https://rdap.arin.net/registry/ip/100.0.0.0

Затем, конечно же, с помощью wirehark (или tcpdump), чтобы посмотреть, куда маршрутизируются пакеты. Но использование чужих сетей категорически не рекомендуется.

person oerdnj    schedule 02.02.2021
comment
Спасибо за ответ. Да, мы на самом деле на 10.0.0.0 netblock, выше было просто для быстрого примера. Точка взята из-за хорошей практики, но я не думаю, что это имеет отношение к проблеме здесь. - person tph43; 02.02.2021

arrow_upward
0
arrow_downward

Хорошо, это оказалось основной проблемой брандмауэра. Короче говоря, я не осознавал, что tcpdump видит пакеты до брандмауэра, поэтому входящие DNS-запросы не означают, что они достигают сервера. дох!

person tph43    schedule 02.02.2021