Безопасность передачи зон для bind
Haha! Если вы сделали это, то запустите недействительную команду для gnome-терминала...
- Нажмите
Alt + F2 - тип
гном-терминал -e ":)"
В верхней части терминала STATIC (наконец) должно появиться сообщение об ошибке, в котором говорится Не удалось выполнить дочерний процесс ":)". (нет такого файла или директории).
Готово... (сразу после щелчка правой кнопкой мыши и перехода к Profiles > Preferenes или нажмите кнопку Profile Preferences (Параметры профиля) сверху и отредактируйте Ваши настройки так, чтобы Вы могли правильно открыть терминал)
:)
. Все разговоры в Интернете должны быть приватными. DNS всегда должен быть частным, он запускает Интернет, без чистых записей DNS , на которые мы не могли рассчитывать в сети.
Если между ведущим и ведомым произошла атака MITM и они изменили записи на ведомом, им нужно только первичный сервер DOS , и ведомый начнет обслуживать неправильные записи
Чтение эта хорошая статья
Нет никакой практической опасности в отправке зон в открытом виде, если только:
- Зона содержит записи, которые не должны быть открыты для посторонних глаз (например. : в вашей зоне "example.net" есть запись "hiddenstuff.example.net", которая будет использоваться только несколькими людьми).
- Существуют некоторые особые проблемы безопасности в отношении сетей (например: передача идет через сеть Ethernet с провинившимися пользователями).
Вы, вероятно, не преследуете правильную проблему, но вы не предоставляете достаточного контекста, чтобы действительно помочь вам взглянуть на вещи в перспективе.
Вы можете защитить передачу файла зоны между разными хостами различными способами. Во-первых, ведущий может запретить запросы AXFR/IXFR только от своих подчиненных устройств, а подчиненные устройства могут ограничить запросы NOTIFY (подчиненные устройства извлекают данные из главного устройства, поэтому оно является инициатором ). Для более надежной аутентификации у вас есть TSIG. См. это для Bind9:ftp://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch04.html#tsig
Также в настоящее время многие созвездия серверов имен настраиваются из одного источника и/или выделяются из -диапазона -. Например, контент может находиться в базе данных, генерироваться в каком-то месте, а затем распространяться с помощью rsyncили эквивалентно всем серверам имен. Между серверами имен нет DNS-сообщений для обновления их друг от друга.
Отдельным образом вы часто имеете «скрытый» главный :сервер имен, где все изменения файла зоны отображаются для всех общедоступных серверов имен. Там нет возможности MITM, поскольку вы даже не знаете, что есть скрытый мастер, и тем более, где он находится и его IP (, за исключением случаев, когда вы уже смогли получить контроль над одним из серверов имен, и в этом случае это полностью другая проблема ).
И, как я сказал в другом комментарии, теперь у вас есть DNSSEC.Если ваша зона правильно настроена с помощью DNSSEC, даже если кому-то удастся изменить ее содержимое либо на сервере имен, либо при передаче, то любой проверяющий рекурсивный сервер имен обнаружит изменение, поскольку новый ответ будет либо вообще не подписан, либо подписан неправильно.