Как предотвратить "взлом" субдомена на том же DNS-сервере?
Я пытаюсь понять, как (или если) DNS-сервер различает настройку поддомена как зону и одну настройку как запись в доменной зоне на том же сервере.
Скажем, я должен был создать зону DNS на DNS-сервере для домена, например example.com.
Что мешает кому-то создать другую зону, test.example.com, на том же сервере и "похитить" этот поддомен домена?
Когда DNS-запрос будет отправлен на сервер имен для test.example.com, DNS-сервер вернет:
- Основная запись A зоны test.example.com или
- Test.example.com Запись в зоне example.com
(и если запись A для test.example.com не существует в example.com, она не вернет такую запись или продолжит работу в зоне test.example.com)
Есть ли какой-нибудь способ предотвратить реагирование поддоменной зоны без перемещения доменов на их собственный уникальный сервер имен? Как с этим справляются ZoneEdit и Amazon Route53?
(Если субдомен был размещен на отдельном сервере, главная зона для example.com должна была бы делегировать субдомен этому отдельному серверу, правильно? (Согласно этой статье Technet).)
3 ответа
Не уверен насчет связывания, но Windows DNS выходит из строя (сначала оценивается example.com), и поскольку зона не переопределяет test.example.com - это конец (то есть test.example.com никогда не запрашивается).
"Что мешает кому-то создать другую зону, 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 начал его читать, и в этот момент он мог делать все, что хотел в любом случае). DNS Windows IIRC откажется загружать коллизии, и BIND будет работать с тем, что он загружал последним (хотя я могу иметь это в обратном направлении). Но в любом случае, чтобы кто-то мог получить определение своей зоны на работающем сервере имен, у него должен быть достаточный доступ, чтобы он мог в любом случае делать с вашим DNS все, что он хочет.
Такой контроль должен быть внешним по отношению к BIND, так как сам BIND не имеет таких элементов управления доступом.
Я ищу официальные документы, но я считаю, что bind соответствует самой конкретной зоне, определенной в named.conf.
Таким образом, зоны будут обрабатываться в максимально-менее конкретном порядке. Если у вас были уникальные зоны для каждой из:
host.sub.domain.com
sub.domain.com
domain.com
Тогда поиск для.host.sub.domain.com будет использоваться преимущественно над другими зонами.
Поэтому, чтобы ответить на ваш вопрос, вам нужно встроить такую защиту в редактор зон или ограничить доступ, чтобы пользователи могли редактировать только свои собственные файлы зон.
Я работаю в системах cPanel/WHM, и они используют файлы зон для каждого субдомена. Панель WHM обеспечивает безопасность, необходимую для предотвращения подмены пользователя другой зоной пользователя.