В настоящее время я настраиваю DNS-сервер для своей домашней лаборатории. Я создал файл зоны, соответствующий домену лаборатории, скажем, home.lab, и сервер теперь знает, что он является авторитетным сервером для этой зоны, и теперь может отвечать на запросы о device.home.lab.
Теперь я хотел бы использовать этот DNS-сервер на других моих устройствах, чтобы он был авторитетным в home.labзоне, но мне также нужно, чтобы они все еще могли разрешать глобальные интернет-домены. Похоже, что нет способа настроить конечные хосты так, чтобы они использовали его только для home.labпоиска, а в противном случае какой-то другой. Пока я вижу несколько решений:
- настроить этот сервер также для рекурсивного разрешения других зон (что будет работать, как описанов этом вопросе)
- заставить сервер при запросе зоны, отличной от его собственной, отвечать ссылкой на корневые серверы, а оттуда заставить клиентов рекурсивно запрашивать иерархию самостоятельно
- настроить другой DNS-сервер, который при запросе
home.labбудет пересылать ответ от авторитетного DNS-сервера, а в противном случае пересылать кэшированный ответ
Первый вариант кажется плохим, потому что тогда авторитетный сервер также имеет двойную обязанность как рекурсивный резолвер для остальных доменов. Второй вариант неэффективен, так как тогда клиентам придется вручную разрешать вниз по иерархии для каждого нового домена, что может быть довольно медленно.
Таким образом, третий вариант пока кажется лучшим. Как мне настроить это в BIND9, и/или мне следует рассмотреть альтернативное решение?
решение1
Первый вариант кажется плохим, поскольку тогда авторитетный сервер также выполняет двойную функцию рекурсивного резолвера для остальных доменов.
Для небольших локальных сетей/домашних лабораторий это не проблема.
(Это также часто делается, например, в средах Active Directory, где администратор указывает всем клиентам напрямую использовать контроллер домена AD, на котором размещена зона DNS AD, а не выделенный распознаватель — этоненужный,(но не строго плохо.)
Могут быть некоторые пограничные случаи (например, флаг DNSSEC AD), но я считаю, что они приводят кнетот добавления функций резолвера к авторитетному серверу, а от обратного — заставить машины использовать авторитетный сервер, как если бы он был резолвером, что вы и делаетеужеделает.
Второй вариант неэффективен, поскольку в этом случае клиентам придется вручную разрешать иерархию для каждого нового домена, что может быть довольно медленно.
Это также не сработает, так как большинство клиентов толькозаглушкарешатели – они не будут следовать рекомендациям.
Полный распознаватель, с другой стороны, будеткэшрефералов. Публичный DNS-резолвер, который вы использовали (будь то интернет-провайдер, Google или кто-то еще), также должен разрешать иерархию для каждого нового домена — он, конечно, не хранит полную копию всех записей DNS в мире — но он не медленный, потому что, по крайней мере, первый уровень (TLD) обычно кэшируется в памяти, и в любом случае для типичного домена не так уж много уровней иерархии.
Таким образом, третий вариант пока кажется лучшим. Как мне настроить это в BIND9, и/или мне следует рассмотреть альтернативное решение?
В BIND9 создайте type static-stubзону, указывающую на сервер аутентификации домашней лаборатории. (Это похоже на type forwardзону, но «static-stub» ожидает указания непосредственно на авторитетный сервер, а «forward» ожидает соединения с другим резолвером. Я не уверен в точных различиях.)
Для всех остальных доменов вы можете указать серверы upstream, как forwarders{}в глобальной конфигурации BIND. Это не обязательно – сам BIND9 способен отслеживать рефералы от корневых DNS-серверов (и будет делать это по умолчанию, пока настроена псевдозона «root hints»), что на самом делене являетсямедленно (хотя, безусловно, может быть медленнее, чем пересылка запросов на вышестоящий сервер с собственным огромным кэшем).
Распространенной альтернативой является Unbound (которая больше ориентирована на использование в качестве резолвера, с минимальными функциями авторитарного сервера). Конфигурация Unbound похожа, за исключением типа зоны stubвместо "static-stub". Чтобы сделать запросы Unbound forward, настройте "."как зону "type: forward".
Имейте в виду, что изобретение собственных TLD не будет хорошо сочетаться с проверкой DNSSEC, поскольку в корневой зоне есть записи NSEC, подтверждающие отсутствие , поэтому lab.вам может потребоваться явно исключить свой домен из проверки как в LAN resolver, так и иногда в самих хостах. Только домен home.arpa.зарезервирован для такого рода использования (имея намеренно неподписанные записи NS).
(В качестве альтернативы вы можетедавать возможностьDNSSEC, подпишите свою внутреннюю зону и укажите пользовательский «якорь доверия» на всех проверяющих резолверах. Хотя DNSSEC на самом деле не нужен в домашней лаборатории, преимущество здесь в том, что добавление якоря доверия может быть проще, чем добавление исключения, особенно в BIND.)