Назад | Перейти на главную страницу

Проверка работоспособности архитектуры DNS

Я разрабатываю службу DNS для сети, и у меня возникло несколько вопросов по архитектуре. В О'Рейли / Cricket Liu DNS книга и Руководство по безопасности NIST DNS не отвечайте на эти вопросы иначе как в очень общем виде.

Вот предлагаемая сеть, которая имеет внутренние (пространство RFC 1918) и сегменты DMZ (с несколькими серверами, а не только DNS-серверами), а также почтовые и www-серверы во внешнем пространстве. DNS-серверы - это синие прямоугольники:

Вот требования:

Вот мои вопросы:

  1. Есть ли что-то явно сломанное в этом дизайне?

  2. Есть ли здесь какие-то недостающие или посторонние элементы?

  3. Можно запустить скрытый мастер в той же подсети, что и внутренние подчиненные серверы?

  4. Учитывая относительно небольшой трафик DNS (<1 Мбит / с) во внутренних сетях и сетях DMZ, есть ли проблемы с безопасностью при запуске серверов только для кэширования в тюрьмах (на языке BSD для виртуальных машин) на авторитетных серверах? Или они должны быть на выделенных машинах?

Заранее спасибо!

Вот мои вопросы:

1) Есть что-нибудь очевидно сломаны об этом дизайне?

Ничего Очевидно неправильно. .. По крайней мере, это я вижу.

2) Есть ли здесь отсутствующие или посторонние элементы?

Отсутствует: Вам комфортно, если вы не готовы оказать поддержку своему скрытому хозяину? Система кажется довольно спроектированной (я не хочу называть ее чрезмерно спроектированной, не видя вашего варианта использования), чтобы полагаться на один основной хост. Это выходит за рамки вашей диаграммы, но есть ли у вас план действий на случай непредвиденных обстоятельств, когда [не если] первичный мастер взорвется?

Посторонний: Имейте в виду, что каждый DNS-сервер, который вы добавляете в микс, является другим сервером, которым необходимо управлять. Учитывая ваше использование, критично ли иметь такое количество DNS-серверов?

3) Можно запустить скрытый мастер в той же подсети, что и внутренние подчиненные серверы?

Я ожидал, что скрытый мастер и авторитетные подчиненные DNS будут в dmz. Зафиксируйте мастер соответствующим образом. Внутренние рабы являются правильно отвечать на авторитетные запросы вашей зоны в Интернете? Если внутренние подчиненные устройства отвечают только на запросы вашей зоны от внутренних хостов, вам либо потребуется ОГРОМНЫЙ зона, а глупый количество внутренних запросов к вашей внутренней зоне (рассмотрите возможность кэширования DNS-серверов на уровне хоста / рабочей станции), или вы слишком сильно увеличили мощность внутреннего DNS. Если они отвечают на запросы из Интернета, я ожидаю, что они будут в демилитаризованной зоне. Вы можете обозначать их, как хотите.

Поскольку мастер находится в той же подсети, что и подчиненные - заблокируйте его. Это не должно быть проблемой (и сэкономит вам некоторые накладные расходы на маршрутизацию во время xfer зоны).

4) Учитывая относительно небольшой трафик DNS (<1 Мбит / с) во внутренних сетях и сетях DMZ, есть ли проблемы с безопасностью при запуске серверов только для кэширования в тюрьмах (на языке BSD для виртуальных машин) на авторитетных серверах? Или они должны быть на выделенных машинах?

Да. Всегда есть проблемы с безопасностью. Если серверы только для внутреннего кэширования заблокированы, чтобы принимать только трафик из внутренних источников, они помещаются в тюрьмы, предположительно в среде BSD, и регулярно обновляются и контролируются ... Хакеру предстоит много работы, чтобы использовать среду .

Ваш самый большой риск (см .: не профессиональный аналитик рисков), скорее всего, хакер, совершив чудо, может похитить один из ваших авторитетных ведомых DNS-серверов. Скорее всего, это приведет к частичному искажению или, если злоумышленник действительно гениален, некоторому «отравлению» и краже информации (см. SSL / TLS, чтобы помешать этому).

Следующий по величине (см .: не профессиональный аналитик рисков) - это повреждение подчиненной ОС, требующее переустановки / восстановления.

В конечном итоге:

Это довольно прочный дизайн, и без обзора сети (которую вы не ожидаете предоставить нам) довольно сложно найти недостатки / недостатки в дизайне. Единственное, что явно выделяется, - это то, что здесь много деталей, сложная установка и много инженерной мысли ... Убедитесь, что для этого есть бизнес.

Пример: вы можете запустить Bind9 как полномочный подчиненный сервер, который выполняет рекурсивный / пересылающий поиск и кэширует все в одном демоне. (и сохраняет множественную адресацию / переадресацию портов / другую сетевую магию, чтобы два демона DNS отвечали на одном и том же поле).