Как настроить BIND9 для пересылки зоны?

Редактировать: Это был в целом ужасный вопрос, так как он не был хорошо документирован. Он не был ужасным в том смысле, что я действительно не знал, что идет не так, и долго искал и изучал. В итоге я обратился к ServerFault с вопросом типа “ББББЛЛЛАраааггххх”. Заголовок остался прежним, но текст должен был быть таким:

Мой DNS-сервер, похоже, разрешает мои запросы с разными ответами в зависимости от того, к какой сети я подключен. Примеры:

# Команда DiG
  полученный вывод из первой зоны

# Команда DiG
  полученный вывод из второй зоны

Я с радостью предоставлю больше подробностей. Однако, объясните, как я должен их собрать.

Теперь вернемся к моему ужасному вопросу:

Я прочитал много других вопросов и ответов по BIND9 DNS на ServerFault, связанных с проблемами пересылки. Запросы (с использованием DiG) для FQDN, которые я ожидал, будут пересланы, отвечают так, будто у публичного интернета есть авторитетный ответ. Кроме DiG, какие инструменты я могу использовать, чтобы проследить мою конфигурацию BIND9? Похоже, что зона, которую я пытаюсь переслать, не пересылается.

В частности, я дома с подключением VPN к работе. Я хочу получить доступ к своей домашней зоне (myhome.com., с DNS-сервером на 10.71.73.10) и также к рабочей зоне (mywork.com., с DNS-сервером на 10.10.1.33).

Используя DiG для запроса hostname.mywork.com, DiG сообщает, что AUTHORITY — это публичный nameserver. Местный резолвер, похоже, игнорирует пересылающую зону BIND (db.mywork.com).

В /etc/bind/zones/db.mywork.com
// пересылает запросы mywork к DNS-серверам mywork
zone "mywork.com" {
        type forward;
        forwarders { 10.10.1.33; };
};

bind.conf:
include “/etc/bind/named.conf.options”;
include “/etc/bind/named.conf.local”;
include “/etc/bind/named.conf.default-zones”;
include “/etc/bind/rndc.key”;
include “/etc/bind/named.conf.logging”;

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};

named.conf.options

acl goodclients {
        10.71.73.0/24;
        localhost;
        localnets;
};

options {
        directory "/var/cache/bind";
        forwarders {
                8.8.8.8;        # Google DNS #1
                8.8.4.4;        # Google DNS #2
        };
        recursion yes;
        allow-query { goodclients; };

        dnssec-enable no;

        auth-nxdomain no;    # соответствовать RFC1035
        listen-on-v6 { any; };
        listen-on port 53 { localhost; };
};

и named.conf.local

# Пересылающая зона
zone "myhome.com." {
        type master;
        file "/etc/bind/zones/db.myhome.com";
};

# Обратная зона
zone "73.71.10.in-addr.arpa" IN {
        type master;
        notify no;
        file "/etc/bind/zones/db.10";
};

Редактировать: Теперь у меня гораздо больше опыта с доменными именами и резолверами. Корень этой проблемы заключается в наличии множества авторитетных имен серверов для одной зоны. Это означает, что два различных имен сервера заявляют об авторитете для разрешения DNS-запроса для определенной зоны (например, ‘example.com’). Имен сервер заявляет об авторитете через запись SOA (начало авторитета), говорящую “Приходите ко мне для любых запросов в зоне example.com”.

Я использовал публичное доменное имя (в этом объяснении ‘example.com’) для обращения к общедоступным URL (например, www.example.com = 183.34.22.82, которое перенаправляется и переводится в какой-то приватный адрес, например 192.168.1.2) И для частных URL (private-server-1.example.com = 192.168.1.1). Я назначил два разных имен сервера ответственными за одну и ту же домен. Первый был публичным DNS (в моем случае, Cloudflare). Второй — мой частный DNS — сервер BIND, работающий на внутреннем, приватном URL (private-dns-server-1.example.com). Этот сервер был бы недоступен для компьютера вне моей локальной сети (вездесущие адреса 192.168.x.x).

Такое двойное SOA работает, но не совсем. Когда вы находитесь за публичным компьютером, вы легко попадаете на www.example.com, потому что ваш публичный компьютер должен использовать публичный DNS как авторитетный ответ на “Какой IP-адрес у www.example.com?” Публичный компьютер не может достигнуть другой власти (private-dns-server-1.example.com). У публичного компьютера нет знания о именах или IP-адресах в частной сети. Когда вы на работе, в частной сети (у вас есть IP-адрес, такой как 192.168.1.32, и некоторые другие диапазоны также работают), ваш компьютер, вероятно, получит ответ на “IP для www.example.com” от внутреннего private-dns-server-1.example.com. Это отправит вас прямо к 192.168.1.1, вместо того чтобы отправить вас к приведенному выше публичному адресу (183.34.22.82), а затем перенаправить и перевести на приватный адрес 192.168.1.1.

Звучит хорошо, пока вы не учтете кэширование DNS. Резолверы DNS (это ‘клиенты’ в терминологии DNS) сохраняют предыдущие ответы для повторного использования. Это ускоряет ваш сёрфинг и уменьшает нагрузку на сервера в целом. Давайте снова прогоним пример выше.

Находясь в аэропорту в общественном Wi-Fi, вы обратились к www.example.com. Ваш резолвер DNS запросил Cloudflare и получил 183.34.22.82. Перевод и перенаправление сработали, и вы увидели вашу веб-страницу.

Возвратившись в офис, вы подключились к офисному Wi-Fi. Вы обновили браузер, но DNS-запрос все еще направлял вас на 183.34.22.82, что может или не может работать так же, как если бы вы пошли прямо на 192.168.1.1. Во многих случаях вы получите ту же веб-страницу. В некоторых случаях вы не получите того же поведения. В этом заключается проблема. Ошибку, которая, кажется, ведет себя по-разному в разное время, возможно, сложнее всего устранить.

Лучше всего избегать наличия нескольких авторитетных имен серверов для одной зоны. DNS-сервера, такие как BIND9, имеют некоторые умные конструкции для решения этой проблемы. Альтернативой является выбор внутренней зоны, которая отделена от вашей внешней зоны. Это не означает, что вы должны быть ‘example.com’ для всех и ‘awful324.int’ внутри вашей организации. Вы можете выделить зону внутри ‘example.com’, такую как ‘int.example.com’, для ваших внутренних адресов. Что бы вы ни выбирали, убедитесь, что вы владеете им публично (т.е. зарегистрировали доменное имя ‘awful324.com’), чтобы никто другой не зарегистрировал его и не создал запись начала авторитета (SOA) для этого доменного имени/зоны.

Что я написал несколько лет назад, когда все еще путался с Linux и интернет-протоколами в целом:

В этом случае я использовал tail для мониторинга файла журнала в /var/log/syslog, используя $ tail -f /var/log/syslog. Моя конфигурация имела несколько проблем:

• Я разместил свой директив пересылки внутри определения зоны. Я переместил его в /etc/bind/named.conf.options.
• Как отдельная проблема, некоторые публичные DNS-запросы не разрешались. При мониторинге файла syslog я обнаружил, что время сервера не было синхронизировано. Я настроил ntp на сервере, чтобы устранить эту проблему.