У меня есть работающий сервер 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 для клиентов, должен ли я использовать отдельный поддомен? Какая здесь лучшая практика (и почему или почему бы и нет, поступить иначе - плохая идея)?
Спасибо.
Нет, технически не требуется иметь отдельную зону для динамических обновлений.
Я думаю, что самый важный фактор в использовании поддоменов для динамического DNS связан с политиками безопасности для обновления зоны. На мой взгляд, разрешения, которые вы можете установить в bind, не очень гибкие, хотя более новые версии несколько лучше. С участием allow-update (Bind 8. *) разрешения применяются на уровне зоны, а не для каждой записи. Таким образом, клиент A может обновить запись для важного сервера, если он использует IP-адрес, который был авторизован для выполнения обновлений.
Поэтому, принимая решение о своей динамической конфигурации DNS, вы должны решить, считаете ли вы, что это хорошая идея, чтобы ваши рабочие станции могли изменять записи обновлений для некоторых критически важных услуг. Или вы хотите разделить критически важные службы в одну зону без динамических обновлений, а другие машины - в более динамические зоны.
Динамический DNS не работает необходимость отдельный субдомен, но это самый простой (и лучший) способ его настроить.
Если вы ограничиваете обновления DynamicDNS субдоменом (ws.example.org) и подсетью (в обеих нет серверов), довольно просто установить ограничения, чтобы ничего плохого не произошло. В худшем случае, если что-то пойдет не так, одна рабочая станция будет идентифицирована как другая.
Если вы настраиваете обновления DynamicDNS в том же основном домене, где находятся серверы, вы должны быть осторожны с установкой ограничений, чтобы рабочие станции не могли динамически обновляться, например, до www.example.org. Прошло много времени с тех пор, как я смотрел на это, но вам может потребоваться отдельный ACL для каждого сервера (или другого устройства, для которого вы хотите защитить имя). Аналогичные проблемы с подсетями.