Методы публикации DNS

Проблемы с DNS нередко упоминаются на форумах и в почтовой рассылке ISAserver.org. Недавно там появилась целая куча вопросов относительно публикации DNS. Поток вопросов на данную тему заинтересовал меня, поскольку публикация DNS – это довольно простой процесс, и сложно представить, что он может вызвать такие затруднения. Как оказалось, основной причиной сложностей является не сама публикация DNS, а непонимание того, что люди пытаются выполнить, что и приводит к проблемам.

В этой статье говорится о публикации DNS. В следующих я переключусь на проблемы с исходящими запросами DNS. Это две совершенно разные темы, и поэтому подробное обсуждение разницы между входящими и исходящими DNS поможет объяснить некоторые сложности, прежде чем мы перейдем к методам публикации.

DNS Advertisers(Публикующие сервера).

При публикации DNS сервера, он располагается в защищенной сети ISA Firewall. Цель публикации DNS сервера в том, чтобы позволить внешним пользователям получить доступ к серверу при использовании DNS протокола для разрешения имен серверов Интернет. (Я не говорю про те варианты, где ISA Firewall - это внутренний брандмауэр, используемый для защиты того сегмента сети, который содержит DNS сервера). Когда вы публикуете DNS сервер, вы предоставляете информацию, которую Интернет-клиенты могут использовать для того, чтобы разрешать имена ваших доменов.

Например, предположим, что ваши Веб-серверы расположены в зоне DMZ за брандмауэром ISA Firewall. Когда внешние пользователи хотят соединиться с вашей Веб-страницей, им нужно сперва перевести имя страницы в IP-адрес с помощью того внешнего интерфейса ISA Firewall, что используется сервисом веб-прослушивания по правилу публикации Web Publishing Rule для данной страницы. Так, если они хотят зайти на ваш Интернет-сайт www.company.com, им необходимо послать DNS запрос на ваш опубликованный DNS сервер, чтобы перевести имя www.company.com в IP адрес с помощью внешнего интерфейса ISA Firewall, который используется веб-прослушивателем.

Это лишь один пример, как вы можете использовать DNS для внешних пользователей. Еще один случай – если вы хотите использовать свой собственный DNS, но ваш Интернет и почтовые серверы расположены где-то на другом хосте. В таком случае, вы настраиваете свой опубликованный DNS сервер на возврат IP-адресов хостера ваших серверов. То, что у вас размещаются ваши собственные сервисы DNS, не означает, что вы должны быть хостом для всех своих сервисов. В некоторых случаях вы будете размещать у себя ваши собственные службы (такие как Exchange), но передадите хостинг веб-сайта третьему лицу. В таком случае, ваш DNS сервер будет возвращать IP-адреса вашего хостера веб-сайта и IP-адреса внешнего интерфейса ISA Firewall, используемого для E-mail публикации.

Опубликованные DNS сервера не должны содержать частную информацию. Когда вы публикуете DNS сервер, вы делаете это для предоставления публичного доступа к ресурсам, находящимся под вашим контролем. Цель не в том, чтобы предоставлять информацию о ваших личных ресурсах. Никогда не публикуйте DNS сервер, содержащий ваши личные сетевые записи. DNS сервера такого типа также называются публикующими (DNS Advertisers), так как они предоставляют информацию о ваших ресурсах, находящихся в открытом доступе.

DNS Resolvers(Сервера разрешения имен)

Если публикация DNS используется для предоставления открытого доступа к доменным именам, находящимся под вашим контролем, то исходящий DNS доступ предназначен для разрешения имен для внутренних клиентов. Когда вы позволяете исходящий доступ к DNS, вы даете внутренним клиентам и серверам возможность разрешать имена серверов в Интернет. Например, если внутренний клиент хочет посетить сайт http://www.microsoft.com/, DNS сервер должен быть настроен так, чтобы он мог разрешить это имя для клиента. Такие DNS сервера могут быть предназначены для разрешения лишь Интернет-имен, или они могут отвечать за разрешение и имен и внешних и внутренних хостов. В обоих случаях, эти системы называются серверами разрешения имен (DNS resolvers), так как их главной задачей считается разрешение тех имен, что являются внешними для вашей организации.

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

Причина, почему мы ни в коем случае не хотим, чтобы внутренние пользователи использовали наши публикующие сервера для разрешения имен, в том, что они могут публиковать имена лишь ваших ресурсов, находящихся в открытом доступе. Они не могут разрешать имена любого другого домена. Так что, даже если вы хотели использовать публикующие сервера для разрешения лишь ваших открытых ресурсов, вам бы пришлось позволить внутренним клиентам наталкиваться на брандмауэр ISA Firewall при попытке достичь внутренних ресурсов или тех, что находятся в зоне DMZ. Решение этой проблемы в использовании разделенной инфраструктуры DNS с тем, чтобы внутренние клиенты не натыкались на внешний интерфейс ISA Firewall, пытаясь добраться до хоста, находящегося в том же или другом сегменте сети под защитой ISA Firewall.

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

Мы поговорим подробней о серверах разрешения имен в следующей статье. Эта статья о публикующих серверах.

Защита системных настроек сервера DNS для публикующего сервера

На этом этапе вы уже знаете, что при публикации DNS сервера, вы получаете публикующий сервер (DNS advertiser). Пользователи из Интернета, скорее всего, получат анонимный доступ к подобным серверам, поскольку аутентификация не предусмотрена в мерах безопасности для разрешения имен DNS. Поэтому ваши DNS сервера вполне могут быть атакованы анонимным Интернет-пользователем, и вследствие этого вам стоит предпринять некоторые действия для того, чтобы заблокировать системные настройки вашего DNS сервера. Стоит отметить, что атаки будут идти только с 53-их портов UDP и TCP, потому что ваше правило публикации DNS Server Publishing Rule не позволит никаких других подключений к DNS серверу.

На рисунке, приведенном ниже, показано диалоговое окно Properties одного из моих публикующих серверов. Советуют иметь по меньшей мере два авторитетных DNS сервера для двух разных подсетей для большей отказоустойчивости. Однако, при публикации DNS серверов это не имеет особого смысла, так как если ваше соединение с Интернетом оборвется, не будет иметь значения, есть ли где-то еще один DNS сервер, способный разрешать имена, поскольку даже если внешний пользователь сможет разрешить имя, он в любом случае не сможет получить доступа к ресурсам, ведь соединения с Интернетом нет.

Тем не менее, полезно иметь как минимум два DNS сервера на тот случай, если один из них выйдет из строя. Обычно я устанавливаю два выделенных сервера разрешения имен в зону DMZ с анонимным доступом. Это не единственный способ сделать это, как вы увидите позже, когда мы будем говорить о различных методах публикации DNS.

Находясь в диалоговом окне Properties для сервера DNS, на вкладке Interfaces, убедитесь, что вы отметили условие Only the following IP addresses и затем выберите определенный IP адрес, который DNS server будет прослушивать в поисках входящих запросов DNS. Это мелочь, но я обнаружил, что она может предотвратить некоторые потенциальные сложности в устранении неполадок в тех случаях, когда к DNS серверу прикреплено несколько IP адресов (как в случае, когда DNS сервер также поддерживает множество веб-страниц, прослушивающих разные IP адреса).

Рисунок 1

На вкладке Forwarders, вам нужно убрать галочку рядом с опцией Enable forwarders. Причиной для этого служит то, что мы не хотим сделать наши публикующие серверы серверами разрешения имен. Если позволить серверу стать сервером разрешения имен, он откроется для потенциальных атак, которые были бы невозможны, будь он только публикующим сервером. Таким образом, это предотвращает использование DNS сервера для разрешения имен – почему вы должны предоставлять эти сервисы каждому встречному и позволять ему использовать вашу сеть? Он вполне может воспользоваться собственными серверами или подобным сервером своего провайдера.

Рисунок 2

На закладке Advanced нам нужно отметить опции Disable recursion и Secure cache against pollution. Опция Disable recursion запрещает DNS серверу разрешать те имена, для которых он не является авторитетным. Иначе говоря, если сервер не может разрешить имя, используя записи ресурса (Resource Records), настроенные на сервере, то DNS запрос не будет выполнен. Опция Secure cache against pollution не позволяет атакующим засорить кэш DNS сервера, хоть это и так технически невозможно, когда рекурсия отключена. Однако я все равно использую эту опцию, с ней мне как-то спокойнее (теперь я заговорил как настоящий админ-железячник!)

Рисунок 3

На закладке Root Hints показан список корневых серверов DNS в Интернете. Они используются, когда DNS серверу нужно выполнить рекурсию. Раз уж мы не хотим, чтобы наши публикующие серверы выполняли рекурсию, почему бы нам не убрать все корневые серверы из списка, и тем самым не избавиться от искушения ее включить? Это неплохая идея, и все, что вам надо сделать, это всего лишь выделить все корневые серверы в списке и нажать кнопку Remove. Когда это будет сделано, ваша закладка Root Hints должна будет выглядеть как моя на рисунке, приведенном ниже.

Рисунок 4

Теперь нажмите кнопку Apply, чтобы убедиться в том, что изменения приняты, и переключайтесь на вкладку Monitoring. Отметьте опцию A simple query against this DNS server и затем нажмите на кнопку Test Now. Для этого теста должно появиться значение PASS. Это означает, что ваш DNS сервер может разрешать имена, для которых он является авторитетным, что мы и хотели добиться. Отключите опцию A simple query against this DNS server и поставьте галочку рядом с A recursive query to other DNS servers. Нажмите кнопку Test Now. Для этого теста должно быть значение FAIL. Это то, что там нужно, раз мы не хотим, чтобы наш публикующий сервер выполнял рекурсию и разрешал те имена, для которых он не является авторитетным.

Рисунок 5

На данном этапе наши системные настройки DNS сервера защищены так, как только мы можем это сделать. Заметьте, для этого примера я использовал серверWindows DNS, который работает превосходно и стабилен настолько, насколько это возможно (Он был запущен у меня около года и я перезагружал его лишь один раз, когда я устанавливал обновление, связанное со службами DNS). Однако вам необязательно использовать сервер Windows DNS. Любой сервер подходит, и если вы хотите сэкономить, вы легко можете использовать общедоступный DNS сервер. Просто убедитесь в том, что вы настроили его так, что он не будет выполнять рекурсии любого типа и будет отвечать на запросы лишь для тех доменов и ресурсов, для которых он является авторитетным.

Прежде чем закончить сегодняшнее обсуждение, я хочу осветить одну проблему, которая никогда передо мной не стояла, но, на мой взгляд, это то, о чем необходимо рассказать, чтобы никто не был в замешательстве. Это проблема с передачами зон. Я встречал нескольких людей, которые считали, что когда они опубликовали свой публикующий сервер, им нужно включить передачу зон с DNS сервера внутренней сети к публикующему серверу, который чаще всего расположен в зоне DMZ. Меня никогда не касалась эта проблема потому что, что записи на вашем внутреннем DNS сервере никогда не должны быть те же, что и на публикующем.

Если вы позволите передачу зон с внутреннего сервера на публикующий, вы передадите частные записи о вашей внутренней сети на открытый DNS сервер, а это как раз то, чего делать не стоит! В общем, вам не нужно включать передачу зон с внутреннего DNS сервера на публикующий сервер.