У меня есть работающий сервер DHCP/DNS (ISC Bind 9.6, DHCP 3.1.1) на Debian, к которому я хотел бы добавить функциональность DynamicDNS. У меня довольно простой вопрос: требует ли DynamicDNS (или рекомендует) отдельные поддомены? Я видел несколько руководств, в которых клиенты, получающие свои IP-адреса и другую сетевую информацию через DHCP, находятся на другом поддомене, чем серверы, которые настроены статически (как с точки зрения IP, так и DNS). Например: все клиенты находятся на ws.example.org, а серверы на example.org.
Сейчас все наши серверы и клиенты находятся в одном домене (example.org), но разбросаны по разным файлам зон (потому что у нас несколько подсетей). Клиенты настроены с помощью DHCP, а серверы настроены статически. Если я хочу настроить DynamicDNS для клиентов, должен ли я использовать отдельный поддомен? Какова здесь лучшая практика (и почему или почему не стоит поступать иначе)?
Спасибо.
решение1
Нет, технически не требуется иметь отдельную зону для динамических обновлений.
Я думаю, что самый большой фактор в использовании поддоменов для динамического DNS связан с политиками безопасности для обновления зоны. По моему мнению, разрешения, которые вы можете задать в bind, не очень гибкие, хотя более новые версии несколько лучше. С allow-update(Bind 8.*) разрешения применяются на уровне зоны, а не для каждой записи. Поэтому клиент a может обновить запись для вашего критического сервера, если он использует IP-адрес, который был авторизован для выполнения обновлений.
Поэтому при принятии решения о вашей динамической конфигурации DNS вам нужно решить, считаете ли вы хорошей идеей разрешить вашим рабочим станциям изменять записи обновлений для некоторых критических служб. Или вы хотите отделить критические службы в одну зону без динамических обновлений, а другие машины — в более динамические зоны.
решение2
Динамический DNS ненуждатьсяотдельный поддомен, но это самый простой (и лучший) способ его настроить.
Если вы ограничиваете обновления DynamicDNS поддоменом (ws.example.org) и подсетью (оба без серверов), довольно просто настроить ограничения, чтобы ничего плохого не случилось. Худший случай, если что-то пойдет не так, — это когда одна рабочая станция будет идентифицирована как другая рабочая станция.
Если вы настраиваете обновления DynamicDNS в том же основном домене, где находятся серверы, вам нужно быть осторожным и устанавливать ограничения, чтобы рабочие станции не могли динамически обновляться, например, до www.example.org. Прошло много времени с тех пор, как я это рассматривал, но вам может понадобиться отдельный ACL для каждого сервера (или другого устройства, для которого вы хотите защитить имя). Аналогичные проблемы с подсетями.