Вопрос или проблема
У меня на роутере PC установлен bind9. Он служит DNS-сервером для всех машин в моей домашней сети. Он настроен так, чтобы только перенаправлять DNS-запросы на stubby (слушающий локально на порту 54321), который затем отправляет эти DNS-запросы безопасно на какой-то глобальный DNS-сервер через TLS. В целом это работает нормально, если только не возникает тайм-аут, вот так (взято из системных журналов):
Feb 05 15:51:19 router named[512]: timed out resolving 'accounts.youtube.com/A/IN': 127.0.0.1#54321
Когда я включил tcpdump, я обнаружил, что эти запросы с тайм-аутом отправляются в открытом тексте на порт 53 на случайные (?) имена серверами. Не имея терпения разбираться с этим, я просто заблокировал исходящие пакеты на порт 53, и теперь в системном журнале появились новые записи (естественно, больше таких запросов видно в PCAPS от tcpdump нет) после логов с тайм-аутами:
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.5.6.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.33.14.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.26.92.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.31.80.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.35.51.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.42.93.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.54.112.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.43.172.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.48.79.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.52.178.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.41.162.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.55.83.30#53
Feb 05 15:51:19 router named[512]: permission denied resolving 'accounts.youtube.com/A/IN': 192.12.94.30#53
Что происходит? Почему bind9 переключается на все эти DNS-серверы, полностью игнорируя stubby, который настроен как единственный форвардер? Это файл named.conf.options:
options {
directory "/var/cache/bind";
forwarders {
127.0.0.1 port 54321;
};
dnssec-validation yes;
allow-recursion { localhost; localnets; 192.168.0.0/24; };
listen-on { 127.0.0.1; 192.168.0.0; };
listen-on-v6 { none; };
};
У меня DHCP-сервер настроен так, чтобы он устанавливал все сетевые интерфейсы для всех машин в сети (включая роутер), чтобы они использовали только мой собственный DNS-сервер, работающий на роутере PC, поэтому я считаю (и журналы, похоже, подтверждают это), что bind9 сам решает попробовать другие DNS-серверы, без моего явного разрешения. Возникает три вопроса:
- Почему это происходит?
- Откуда он берет имена серверов для переключения?
- Как отключить его от этого? Хотя блокировка исходящего трафика на порт 53 работает, у меня все же журналы засорены его попытками попробовать другие DNS-серверы для разрешения запросов с истекшим временем ожидания, и мне это не нравится.
Эти DNS-серверы являются ‘корневыми’ DNS-серверами. Подробности см. https://kb.isc.org/docs/aa-01309.
Ответ или решение
Теория
Проблема, которую вы описали, заключается в поведении DNS-сервера BIND9, который после истечения времени ожидания при обращении к stubby неожиданно начинает выполнять запросы к ряду внешних DNS-серверов. Это происходит из-за того, что BIND9 пытается использовать корневые серверы DNS в целях резолвинга запросов, когда не удается получить ответ от указанных форвардеров.
Пример
BIND9 — это мощный инструмент для резолвинга DNS-запросов, часто используемый для организации кэширования и форвардинга DNS в локальных сетях. Когда сетевой администратор настраивает BIND9 в режиме форвардера, как в вашем случае, ожидание состоит в том, что все DNS-запросы будут направлятся на указанный форвардер (в вашем случае, stubby, функционирующий на 127.0.0.1:54321).
Стандартная конфигурация BIND9 предполагает, что при невозможности получения ответа от своих форвардеров, сервер попытается использовать корневые DNS сервера напрямую (например, 192.5.6.30, 192.33.14.30 и другие, которые вы видите в логах). Эти IP-адреса относятся к корневым серверам, которые предоставляют начальные точки для резолвинга запросов любого домена.
Применение
Почему BIND9 это делает?
По умолчанию, BIND9 настроен так, чтобы обеспечивать высокую доступность и надежность резолвинга DNS-запросов. При возникновении проблем с указанными форвардерами, BIND9 автоматически переходит на использование корневых серверов, чтобы не нарушать процесс DNS-резолвинга.
Откуда берутся дополнительные DNS-серверы?
Адреса DNS-серверов, которые вы видите в логах, это список корневых DNS-серверов, жестко закодированных в конфигурации BIND9. Они выступают в качестве резервных источников информации.
Как отключить использование этих серверов?
Если вы хотите предотвратить резолвинг через корневые серверы, можно внести изменения в конфигурационный файл named.conf.options. Вам следует использовать опцию forward only; внутри секции options, которая заставит BIND9 использовать только указанные форвардеры, не прибегая к резолвингу через корневые DNS-серверы. Вот модифицированный пример вашего файла named.conf.options:
options {
directory "/var/cache/bind";
forwarders {
127.0.0.1 port 54321;
};
forward only;
dnssec-validation yes;
allow-recursion { localhost; localnets; 192.168.0.0/24; };
listen-on { 127.0.0.1; 192.168.0.0; };
listen-on-v6 { none; };
};Используя директиву forward only;, вы говорите BIND9 игнорировать любые другие источники информации, кроме указанных форвардеров.
Заключение
Настройка BIND9 в роли форвардера требует четкого понимания его поведения по умолчанию и изменений, которые необходимо внести, чтобы полностью контролировать процесс резолвинга DNS-запросов. Ваша текущая настройка с блокировкой трафика на порту 53 временно решает проблему отправки неожиданных запросов, но правильная конфигурация решит это на уровне программного обеспечения, устраняя ненужные попытки резолвинга и добавляя уверенности в безопасности вашего сетевого окружения.