Я пытаюсь понять, как (или если) DNS-сервер различает настройку поддомена как зону и настройку как запись в зоне домена на том же сервере.
Скажем, я должен был создать зону DNS на DNS-сервере для домена, например. example.com.
Что должно помешать кому-либо создать еще одну зону test.example.com на том же сервере и «захватить» этот субдомен домена?
Когда DNS-запрос сделан на сервер имен для test.example.com, DNS-сервер вернет:
(и если запись A для test.example.com не существует в example.com, она не вернет такую запись или продолжит работу в зоне test.example.com)
Есть ли способ предотвратить ответ зоны поддомена без перемещения доменов на их собственный сервер уникальных имен? Как с этим справляются такие компании, как ZoneEdit и Amazon Route53?
(Если поддомен был размещен на отдельном сервере, главная зона, например, example.com, должна была бы делегировать поддомен этому отдельному серверу, верно? (Согласно эта статья Technet).)
Такой контроль должен быть внешним по отношению к BIND, поскольку сам BIND не имеет таких средств контроля доступа.
Я ищу официальную документацию, но считаю, что bind соответствует наиболее конкретной зоне, определенной в named.conf.
Таким образом, зоны будут обрабатываться в наиболее или менее конкретном порядке. Если у вас были уникальные зоны для каждого из:
host.sub.domain.com
sub.domain.com
domain.com
Тогда поиск a.host.sub.domain.com будет использоваться предпочтительно по сравнению с другими зонами.
Итак, чтобы ответить на ваш вопрос, вам нужно будет встроить такую защиту в редактор зон или ограничить доступ, чтобы пользователи могли редактировать только свои собственные файлы зон.
Я работаю в системах cPanel / WHM, и они используют файлы зон для каждого поддомена. Панель WHM обеспечивает безопасность, необходимую для предотвращения взлома пользователем другой зоны пользователя.
«Что может помешать кому-либо создать еще одну зону test.example.com на том же сервере и« захватить »этот субдомен домена?»
Что ж, если они могут это сделать, они также могут просто изменить исходный файл зоны; в общем, если у кого-то есть доступ к вашему DNS-серверу, он может изменить DNS так, как захотят.
"Когда DNS-запрос сделан на сервер имен для test.example.com, DNS-сервер вернет:
The main A record of the test.example.com zone or
The test.example.com A record in the example.com zone"
Как всегда, ответ - «Все зависит от того, как вы это настроили». Если сервер является авторитетным для example.com и не делегировал test.example.com, он ответит, но настроен для ответа; с точки зрения протокола нет разницы в том, что зона test.example.com имеет @ Запись и зона example.com, имеющая test Запись. Если вы спрашиваете, что происходит, если есть коллизии (например, вы определили test.example.com в файле зоны example.com, а ваш гнусный нарушитель определил файл зоны test.example.com, ну, опять же, он нужно было написать named.conf, чтобы BIND прочитал его с самого начала, после чего он мог просто делать все, что хотел). IIRC Windows DNS откажется загружать конфликты, и BIND будет работать с тем, что было загружено последним (хотя у меня это может быть и наоборот). Но в любом случае, чтобы кто-то получил определение своей зоны на работающем сервере имен, он должен иметь достаточный доступ, чтобы в любом случае делать с вашим DNS все, что он хочет.
Не уверен в привязке, но Windows DNS падает (сначала оценивается example.com), и поскольку зона не переделегирует test.example.com - это конец (т.е. test.example.com никогда не запрашивается).