Dns forwarding что это: Как настроить условный форвардинг для вашего DNS сервера из командной строки

Настройка условной пересылки

Если у вас несколько внутренних доменов, вам стоит подумать о настройке условной пересылки. Она позволяет направлять запросы конкретных доменов для разрешения на конкретные DNS-серверы. Условная пересылка полезна, если в вашей организации есть несколько внутренних доменов и вам требуется разрешать запросы между ними.

Чтобы настроить условную пересылку, выполните следующие действия:

1. В консоли Диспетчер DNS (DNS Manager) щелкните правой кнопкой папку Серверы условной пересылки (Conditional Forwarders) нужного вам сервера. В контекстном меню выберите команду Создать условную пересылку (Conditional Forwarder).

2. В диалоговом окне Создать сервер условной пересылки (New Conditional Forwarder) введите имя домена, в который следует пересылать запросы, например, logi.cc.

3. Щелкните список ІР-адрес (IP Address), введите ІР-адрес полномочного DNS-сервера в указанном домене и нажмите Enter. Повторите процесс, чтобы указать дополнительные ІР-адреса.

4. При использовании интеграции DNS с Active Directory установите флажок Сохранять условную пересылку в Active Directory (Store This Conditional Forwarder In Active Directory) и выберите одну из следующих стратегий репликации.

• Все DNS-серверы в этом лесу (All DNS Servers In This Forest)   Это обширнейшая стратегия репликации. Помните, что лес Active Directory включает все деревья доменов, использующие данные каталога совместно с текущим доменом.

• Все DNS-серверы в этом домене (All DNS Servers In This Domain)   Выберите эту стратегию, чтобы реплицировать информацию DNS внутри текущего домена и его дочерних доменов.

• Все контроллеры домена в этом домене (All Domain Controllers In This Domain) Выберите эту стратегию, если хотите реплицировать информацию DNS на все контроллеры домена внутри текущего домена и его дочерних доменов. Хотя эта стратегия обеспечивает более широкую репликацию информации DNS внутри домена, не каждый контролер домена является DNS-сервером (вам и не нужно настраивать каждый контроллер домена как DNS-сервер).

5. Задайте время ожидания пересылки, то есть, время, в течение которого сервер пытается запросить сервер пересылки в случае отсутствия ответа. По истечении времени ожидания сервер пытается запросить следующий полномочный сервер из списка. Стандартное время ожидания составляет пять секунд. Щелкните ОК.

6. Повторите процедуру, чтобы настроить условную пересылку для других доменов.

Что такое переадресация домена (Web-forwarding, URL-forwarding, Web-redirect, HTTP-redirect)?

Услуга «Переадресация домена» (называемая также Web-forwarding, URL-forwarding, Web-redirect, HTTP-redirect)
позволяет настроить переадресацию с одного домена на другой, а также на веб-страницу с другим адресом.

При настройке переадресации используется 301 редирект.

Примеры переадресаций

• с домена mysite.ru на домен my-new-site.ru;
• с домена mysite.ru на страницу my-new-site.ru/shop.

Все пользователи, набравшие адрес вашего домена (или пришедшие на него по ссылке), попадут на веб-страницу, адрес которой вы укажете в настройках услуги «Переадресация домена». Использование услуги позволит вам иметь постоянный адрес веб-страницы, который не придется менять при смене провайдера.

Услуга «Переадресация домена» может также использоваться при регистрации дополнительного доменного имени для уже существующего веб-сайта.

Внимание

• Установка SSL-сертификатов на услугу веб-форвардинг невозможна. Поэтому перенаправление с https://mysite.ru/ не производится.
• Настроить перенаправление с поддомена (например, с subdomain.domain.ru) на какую-либо страницу невозможно.

В качестве примера предлагаем рассмотреть такую ситуацию:

У вас есть домен mycompany. ru, на котором полноценно работает сайт. На нём есть раздел продукции одного из ваших поставщиков. Адрес этой страницы: www.mycompany.ru/mybrand/index.html или подобный.

Для лучшего продвижения товара этого поставщика вы приобретаете целевое доменное имя: mybrand.ru и заказываете для него услугу «Переадресация домена» на адрес уже существующего раздела на вашем основном сайте: www.mycompany.ru/mybrand/index.html.

Теперь посетители могут набирать прямой адрес сайта бренда mybrand.ru, а вы использовать этот адрес в прямой рекламе продукции этого бренда. Легче запомнить адрес – выше эффективность!

Одиночное перенаправление запроса

forwarding

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

Пример:

• настроена переадресация site1. ru — site2.ru;
• посетители видят в строке браузера: site2.ru.

Одиночное перенаправление с маскировкой адреса во фрейме

forwarding2

В этом случае посетители видят адрес той страницы, с которой происходит перенаправление. Веб-страница будет находиться внутри фрейма, и при всех переходах по ссылкам внутри этого фрейма в адресе URL посетители будут видеть доменное имя, с которого происходит переадресация.

Пример:

• настроена переадресация site1.ru — site2.ru;
• посетители видят в строке браузера: site1.ru.

Техническая справка

Необходимо помнить, что если вы выбираете «маскировку адреса во фрейме», и хотите установить на вашей веб-странице ссылки на другие ресурсы, в теге ссылки необходимо указать target=_top. В противном случае чужая веб-страница также будет открыта внутри вашего фрейма, и посетитель будет видеть в строке браузера URL-адрес вашего домена. Также необходимо иметь в виду, что истинный адрес веб-страницы, на которую осуществляется перенаправление, хотя и не отображается в строке браузера, все же может быть легко вычислен любым посетителем.

Массовое перенаправление всех страниц

Все запросы с одного адреса (например, http://faq-reg.ru) будут перенаправлены на соответствующие страницы другого адреса. Вы сможете настраивать множество перенаправлений с вашего домена (с разных адресов на базе домена).

Пример

Вы зарегистрировали домен newdomain.ru и ваш сайт находится по адресу http://mysite.narod.ru. Услуга позволит вам перенаправить запросы: с newdomain.ru, newdomain.ru/news, newdomain.ru/info и всех остальных страниц сайта на http://mysite.narod.ru.

О настройке различных вариантов услуги «Переадресация домена» читайте ниже в инструкции Как настроить Переадресацию домена.

1. 1.
   Перейдите в Личный кабинет.
2. 2.

   Кликните по домену, для которого хотите подключить услугу:

3. 3.

   Пролистайте открывшуюся страницу вниз и напротив «Переадресация домена» нажмите Заказать:

4. 4.

   Выберите период, на который хотите заказать услугу, и нажмите кнопку Продолжить:

5. 5.

   Проверьте позиции в корзине и нажмите Оплатить:

6. 6.
   Выберите удобный способ оплаты и оплатите выставленный счет.

Готово, теперь услуга доступна в вашем Личном кабинете.

С помощью услуги «Переадресация домена» вы можете настроить следующие виды переадресации:

• одиночное перенаправление конкретного адреса;
• одиночное перенаправление с маскировкой адреса во фрейме;
• массовое перенаправление всех страниц.

Подробнее про каждый способ.

Для корректной работы услуги:

• к новому домену должен быть привязан IP-адрес старого домена,
• для домена должны быть прописаны DNS-серверы ns1.reg.ru и ns2.reg.ru. Если для домена прописаны другие DNS-серверы, используйте инструкцию Как изменить DNS-серверы.

1. 1.

   Перейдите к списку услуг и выберите Web-forwarding:

   Проверить IP 1

2. 2.

   Нажмите Как настроить домен:

   Проверить IP 2

3. org/HowToStep»>
   3.

   В шторке вы увидите, какие ресурсные записи должны быть у нового домена:

   Проверить IP 3

4. 4.
   Проверьте, соответствуют ли ресурсные записи нового домена записям, полученным в шаге 3. Если нет, то измените их по инструкции Добавление A-записи.

1. 1.
   Перейдите в Личный кабинет.
2. 2.

   Кликните по имени домена, для которого подключена услуга «Переадресация домена».

3. 3.

   Во вкладке «Управление» в блоке «DNS-серверы и управление зоной» нажмите Изменить:

4. org/HowToStep»>
   4.

   Выберите DNS-серверы ns1.reg.ru и ns2.reg.ru:

   Готово, вы изменили DNS-серверы. Если ранее вы использовали другие DNS-серверы, изменения вступят в силу в течение 24 часов.

Чтобы настроить переадресацию с одного домена на другой:

1. 1.

   Перейдите к списку услуг и выберите Web-forwarding:

2. 2.

   Во вкладке «Управление» пролистайте страницу вниз и в блоке «Перенаправления» нажмите Добавить:

3. 3.

   В шторке справа выберите нужное перенаправление:

4. 4.

   Заполните необходимые поля:

   • в поле «С адреса» укажите относительный адрес (без имени вашего домена), с которого требуется перенаправлять посетителей;
   • в поле «На адрес» укажите имя сайта, на который будут перенаправлены посетители.

   Нажмите Готово:

Готово, одиночная переадресация с одного домена на другой настроена. Перенаправления других видов настраиваются аналогичным образом.

Что делать, если при маскировке адреса во фрейме сайт не адаптируется на мобильном устройстве?

При подключении маскировки адреса во фрейме сайт автоматически помещается в шаблон, который убирает принудительное масштабирование сайта. Это защищает сайты с современным адаптивным дизайном от проблем при использовании данного способа переадресации домена.

В коде head автоматически добавляется метатег:

meta name=“viewport” content=“width=device-width, initial-scale=1.0”

Он указывает на то, что сайт современен и оптимизирован для мобильных устройств.

Если при подключении маскировки адреса во фрейме, ваш сайт не масштабируется на мобильных устройствах или масштабируется неправильно — значит он не адаптивен.

Для устранения проблемы обратитесь к разработчикам вашего сайта.

Обратите внимание! При удалении услуги «Переадресация домена» средства не возвращаются.

1. 1.
   Перейдите в Личный кабинет.
2. 2.

   Выберите Web-forwarding в списке услуг.

3. 3.

   Во вкладке «Операции» нажмите Удалить услугу:

4. 4.

   Подтвердите удаление услуги.

Готово, услуга будет удалена в течение 15 минут.

Помогла ли вам статья?

784
раза уже помогла

Разделение функций серверов DNS | Windows IT Pro/RE

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

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

Функциональное назначение серверов DNS

Прежде чем мы обсудим разделение ролей, следует рассмотреть функции, выполняемые сервером DNS. К ним относятся авторизованные ответы (authoritative responses), рекурсия (recursion), перенаправление (forwarding) и кэширование (caching).

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

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

Процесс рекурсии начинается с обращения к одному из корневых серверов (root server), размещенных в Internet. Предположим, например, что браузер вашего компьютера пытается найти IP-адрес, соответствующий имени http://www.osp.ru/adm/edit/www.example.com. Если сервер DNS сам не имеет этих данных, он запросит их у одного из корневых серверов. Корневой сервер тоже вряд ли что-либо «знает» о запрашиваемом имени хоста, однако ему известен IP-адрес сервера, обслуживающего имена верхнего уровня .com, соответственно он возвращает ссылку на этот сервер. Далее ваш сервер DNS обращается к серверу DNS домена .com, который, вероятно, также не имеет сведений об интересующем вас хосте, но у него есть данные о DNS-сервере, обслуживающем домен example.com, поэтому он возвращает IP-адрес этого сервера. Что касается DNS-сервера example.com, то он является авторизованным для данного домена, поэтому может дать авторизованный ответ на запрос адреса http://www. osp.ru/adm/edit/www.example.com.

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

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

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

Например, если серверу DNS организации уже известны IP-адреса серверов DNS вышеупомянутого домена example.com, то ему нет необходимости запрашивать какие-либо внешние серверы, что позволяет снизить нагрузку как на корневые серверы, так и на другие серверы высших уровней иерархии.

Основные роли DNS

Исходя из понимания основных аспектов работы DNS становится ясно, что в организации эта служба может играть несколько ролей. При этом наиболее распространенная ошибка, допускаемая сетевыми администраторами, состоит в том, что каждый существующий в сети сервер DNS конфигурируется сразу под все эти роли. О типичных уязвимых местах стандартных конфигураций DNS рассказано во врезке «Уязвимые места DNS». Предлагаемый подход с разделением ролей поможет предотвратить или по крайней мере минимизировать возможности проведения различных атак.

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

• Публикующий сервер (Advertiser). Сервер DNS, имеющий связь с Internet и предоставляющий информацию об общедоступных серверах сети компании.
• Мастер внутреннего домена (Internal domain master). Данный сервер, обычно интегрированный с Active Directory (AD), предоставляет авторизованные ответы по разрешению имен хостов локального домена.
• Сервер разрешения имен (Resolver). Эти серверы DNS размещены централизованно и реализуют функции перенаправления и кэширования.

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

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

Настройка публикующих серверов

Публикующие серверы позволяют всем внешним клиентам разрешать имена общедоступных хостов, таких как серверы Web и FTP, а также почтовые серверы. Публикующие серверы чаще всего являются объектами атак, поэтому необходимо тщательно отбирать информацию, которую они могут предоставлять. Здесь должны храниться сведения только об общедоступных хостах, но не должно быть никакой информации об IP-адресах внутренней сети. Кроме того, публикующие серверы следует настраивать так, чтобы они разделяли информацию о зонах только с другими публикующими DNS-серверами сети предприятия.

Многие организации пользуются услугами своих Internet-провайдеров для размещения публичных записей DNS, и в этом случае возможность управления конфигурацией DNS практически отсутствует. Однако администраторы, самостоятельно обслуживающие свои публичные серверы DNS, могут воспользоваться утилитой DNScmd из пакета Support Tools (файл Support.cab). Данный файл находится на установочном компакт-диске Windows Server 2003 в каталоге support ools. Первым делом следует настроить публикующий сервер на прослушивание единственного IP-адреса. Предположим, ваш публичный сервер DNS имеет адрес 192.0.34.166. Тогда надо использовать следующую команду:

dnscmd resetlistenaddresses 192.0.34.166

Далее нужно отключить рекурсию, для того чтобы сервер DNS отвечал на запросы только внутри собственной зоны. Для этого применяется команда:

dnscmd /Config /NoRecursion 1

На следующем шаге требуется сделать сервер DNS корневым. Это реализуется путем добавления корневой зоны. Если сервер является корневым, то он предполагает, что имеет всю необходимую информацию и не будет пытаться обращаться к другим серверам DNS. Соответствующая команда выглядит следующим образом:

dnscmd /ZoneAdd . /Primary

Поскольку в данном случае сервер DNS имеет подключение к общедоступной сети, я рекомендовал бы выполнить еще несколько настроек, чтобы предотвратить возможность атак. Во-первых, с помощью приведенной ниже команды следует запретить серверу DNS использовать протокол RPC:

dnscmd /Config /RPCProtocol 0

Во-вторых, если имена всех зон состоят только из символов ANSI (т. е. не содержат специальных символов и букв нелатинского алфавита), тогда можно настроить сервер имен так, чтобы он обрабатывал лишь имена, совместимые с RFC. Для этого используется команда:

dnscmd /Config /NameCheckFlag 0

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

dnscmd /Config /AddressAnswerLimit 5

Настройка мастеров внутреннего домена

Мастерами внутреннего домена являются серверы DNS, обрабатывающие запросы на разрешение имен в локальных доменах AD. Для того чтобы иметь возможность более детального управления параметрами безопасности и улучшения работы механизмов репликации по сравнению с теми, которые мы имеем после установки системы, следует настроить эти серверы (если это не было сделано сразу) как зоны, интегрированные в AD. Данные серверы являются авторизованными только для своих зон, никаких попыток разрешения имен в «чужих» зонах они предпринимать не будут.

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

dns /zoneadd . /Primary

Настройка сервера разрешения имен

Теперь рассмотрим, как настраиваются серверы разрешения имен. Такие серверы должны иметь центральное размещение, причем, с одной стороны, к ним должны иметь доступ клиенты внутренней сети, а с другой стороны, они должны иметь возможность подключения к другим серверам DNS. В этом случае первое, что следует сделать, — это убедиться в том, что сервер разрешения имен прослушивает только IP-адреса внутренней сети. Например, если сервер разрешения имен должен прослушивать адрес 192.168.0.54, можно воспользоваться следующей командой:

dnscmd resetlistenaddresses
192.168.0.54

Обратите внимание, что этот IP-адрес, а также те адреса, которые аналогичным образом задаются для дополнительных серверов разрешения имен, будут теми самыми адресами, которые необходимо указывать на каждом клиенте в настройках протокола TCP/IP в качестве серверов DNS (в разделе «Свойства TCP/IP»).

Вторая задача состоит в том, чтобы настроить каждый сервер разрешения на выполнение переадресации запросов разрешения имен внутри домена на те серверы, которые являются мастерами домена. Например, если имя домена example.corp, а серверы-мастера домена имеют адреса 192.168.0.11 и 192.168.0.12, то соответствующая команда настройки будет выглядеть так:

dnscmd /zoneadd example. corp /forwarder
192.168.0.11 192.168.0.12 /slave

Здесь параметр /slave предписывает серверу разрешения имен не предпринимать самостоятельных попыток поиска адреса, если сервер DNS не отвечает. Поскольку в данном случае мы имеем в виду серверы DNS внутреннего домена предприятия, то, соответственно, они не должны выполнять поиск где-либо еще.

Далее нужно настроить сервер перенаправления так, чтобы он обрабатывал все остальные запросы к DNS. Этот сервер должен быть внешним сервером DNS, например тем, который предоставляет Internet-провайдер. Так, если серверы DNS Internet-провайдера имеют IP-адреса 192.14.9.22 и 192.15.9.23, можно воспользоваться следующей командой:

dnscmd /resetforwarders 192.14.9.22 192.15.9.23

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

Для того чтобы проверить правильность выполненных настроек, следует указать в параметрах сетевого адаптера компьютера адреса этих серверов DNS. Затем с помощью команды Nslookup нужно попытаться выполнить поиск, задавая различные имена локальных и публичных хостов.

Правильный подход к планированию

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

Марк Барнетт ([email protected]) — независимый программный консультант по безопасности и автор, специализирующийся на безопасности Windows. Обладатель сертификата IIS MVP и автор нескольких книг, в том числе Perfect Passwords и Hacking the Code (издательство Syngress)

Уязвимые места DNS

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

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

Еще одним типичным приемом, применяемым для атак серверов DNS, является атака типа «отказ в обслуживании» (Denial of Service, DoS). В этом случае сервер DNS перегружается лавинообразно нарастающим трафиком, при этом злоумышленник задействует все его доступные ресурсы, в результате чего сервер просто перестает отвечать на запросы. Но если у вас имеется несколько серверов в отдельной сети, причем роли их четко разграничены, это поможет существенно уменьшить ущерб от подобных атак. В этом случае атаки на внешние серверы никак не повлияют на механизмы разрешения имен во внутренней сети предприятия. Существует и такая опасность, как «засорение кэша DNS» (DNS cache poisoning). В этом случае злоумышленник «обманывает» сервер DNS, записывая в кэш некорректные данные DNS. Это позволяет ему перенаправлять запросы пользователей не на тот хост, который им нужен, а на какой-то другой. Данная ситуация весьма благоприятна для различных атак. Служба DNS, реализованная в Windows, имеет специальные механизмы для блокирования подобных атак, однако эти механизмы несовершенны, поэтому будем надеяться, что проведенные исследования позволят в дальнейшем улучшить их. Таким образом, самый эффективный способ защиты от подобных атак состоит в том, чтобы предотвратить доступ злоумышленников к кэширующим серверам DNS.

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

Поделитесь материалом с коллегами и друзьями

Настройка DNS на маршрутизаторах Cisco

Целью этого документа является сведение воедино некоторых данных об использовании DNS маршрутизаторами Cisco.

Требования

Читатели данного документа должны обладать знаниями по следующим темам:

Используемые компоненты

Сведения, содержащиеся в данном документе, касаются следующих версий программного обеспечения и оборудования:

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Можно настраивать конфигурацию маршрутизатора для использования поиска DNS, если вы хотите использовать команды ping или traceroute с именем хоста, а не IP адресом. Используйте для этого следующие команды:

Команда	Описание
команда ip domain lookup	Включает преобразование имени хоста в адрес на основе DNS. Эта команда включена по умолчанию.
ip name-server	Задает адрес одного или более сервера доменных имен.
ip domain list	Задает список доменов, для каждого из которых выполняется попытка использования.  Примечание. Если список доменов отсутствует, используется доменное имя, заданное с помощью команды глобальной кофигурации ip domain name. При наличии списка доменов доменное имя по умолчанию не используется.
ip domain name	Задает доменное имя по умолчанию, которое используется ПО Cisco IOS для дополнения неполных имен хоста (имен без доменных имен в виде десятичного представления с точкой). Не включайте первую точку, которая отделяет неполное имя от доменного имени.
ip ospf name-lookup	Настраивает протокол OSPF для поиска имен DNS, которые необходимо использовать во всех выводах команды OSPF show EXEC. Эта функция упрощает идентификацию маршрутизатора, потому что маршрутизатор называется по имени, а не по идентификатору маршрутизатора или соседа.

Здесь приведен пример конфигурации на маршрутизаторе, конфигурированном для основного поиска DNS:

 

Router# show running-config
Building configuration... 
Current configuration : 470 bytes
!
version 12. 2
service timestamps debug datetime msec
service timestamps log uptime
no service password-encryption
!
hostname Router
!
!
ip subnet-zero
ip name-server 192.168.1.100

!--- Configures the IP address of the name server. !--- Domain lookup is enabled by default.
 
!
!
interface Ethernet0
 ip address 192.168.1.1 255.255.255.0
!
!  

!--- Output Suppressed.

 end

Router# ping www.cisco.com
Translating "www.cisco.com"...domain server (192.168.1.100) [OK]
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 224/228/236 ms

Устранение неисправностей

Довольно редко можно увидеть одну из следующих ошибок:

Router# debug ip udp
UDP packet debugging is on
Router# ping www.yahoo.com 
Translating "www.yahoo. com"...domain server (129.250.35.250) 
*Mar  8 06:26:41.732: UDP: sent src=209.69.16.66(5476), dst=129.250.35.250(53), length=59 
*Mar  8 06:26:44.740: UDP: sent src=209.69.16.66(5476), dst=129.250.35.250(53), length=59 
*Mar  8 06:26:47.744: UDP: sent src=209.69.16.66(5476), dst=129.250.35.250(53), length=59 
% Unrecognized host or address, or protocol not running. 
Router#undebug allAll possible debugging has been turned off

Router# ping www.yahoo.co.kr 
Translating "www.yahoo.co.kr"...domain server (169.140.249.4) ¡¦ 
Not process 
 
Router# ping www.novell.com 
Translating "www.novell.com"...domain server (255.255.255.255) 
% Unrecognized host or address, or protocol not running.

Для того чтобы устранить эту проблему, выполните следующие шаги:

1. Убедитесь, что маршрутизатор может достичь сервера DNS. Отправьте на сервер DNS эхозапрос от маршрутизатора с помощью его IP-адреса и убедитесь, что для настройки IP-адреса сервера DNS на маршрутизаторе используется команда ip name-server.

2. Используйте эти шаги, чтобы проверить, перенаправляет ли маршрутизатор запросы поиска:

   1. Задайте список контроля доступа (ACL), совпадающий на пакетах DNS:

      access-list 101 permit udp any any eq domain 
      access-list 101 permit udp any eq domain any
      

   2. Используйте команду debug ip packet 101.

       Примечание. Убедитесь, что задан ACL. При выполнении без ACL объем выходных данных команды debug ip packet в консоли может оказаться слишком большим, что приведет к перезагрузке маршрутизатора.

3. Убедитесь, что на маршрутизаторе включена команда ip domain-lookup.

В редких случаях доступ к определенным веб-сайтам по имени невозможен. Обычно проблема возникает из-за недоступных сайтов, выполняющих обратный поиск DNS на исходном IP адресе с целью проверки того, что адрес не имитируется. При возврате неверной записи или отсутствии записей (иными словами, при отсутствии cвязанного названия для диапазона IP-адресов) запрос HTTP будет заблокирован.

Получив доменное имя в Интернете, следует также обратиться за получением домена inaddr.arpa. Этот специальный домен иногда называют обратным доменом. Домен обратного преобразования осуществляет преобразование цифровых IP-адресов в доменные имена. Если интернет-провайдер предоставляет вам сервер имен или назначил вам адрес из блока своих адресов, не требуется самостоятельно обращаться за получением домена in-addr.arpa. Консультация Интернет-провайдера.

Давайте Давайте Рассмотрим пример, в котором используется www.cisco.com. Приведенные ниже выходные данные были получены от рабочей станции UNIX. Использовались программы nslookup и dig. Обратите внимание на различия в выходных данных:

sj-cse-280% nslookup www.cisco.com 
Note:  nslookup is deprecated and may be removed from future releases.  
Consider using the 'dig' or 'host' programs instead.  Run nslookup with 
the '-sil[ent]' option to prevent this message from appearing. 
Server:         171.68.226.120 
Address:        171.68.226.120#53 
Name:   www.cisco.com 
Address: 198.133.219.25

sj-cse-280% nslookup 198.133.219.25 
Note:  nslookup is deprecated and may be removed from future releases. 
Consider using the 'dig' or 'host' programs instead.  Run nslookup with 
the '-sil[ent]' option to prevent this message from appearing. 
Server:         171.68.226.120 
Address:        171.68.226.120#53 
25.219.133.198.in-addr.arpa     name = www.cisco.com.

Программа dig дает более детальную информацию о DNS пакетах:

sj-cse-280% dig 198.133.219.25 
 
; <<>> DiG 9.0.1 <<>> 198.133.219.25 
;; global options:  printcmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5231 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
 
;; QUESTION SECTION: 
;198. 133.219.25.                        IN      A 
 
;; AUTHORITY SECTION: 
.                       86400   IN      SOA     
A.ROOT-SERVERS.NET. nstld.verisign-grs.com. 
( 2002031800 1800 900 604800 86400 ) 

;; Query time: 135 msec 
;; SERVER: 171.68.226.120#53(171.68.226.120) 
;; WHEN: Mon Mar 18 09:42:20 2002 
;; MSG SIZE  rcvd: 107

В зависимости от уровня сетевой активности маршрутизатор может запросить несколько серверов имен, перечисленных в конфигурации. Ниже представлен пример:

router> test002 
Translating ?test002?...domain server (172.16.33.18) (171.70.10.78) 
(171.100.20.78) 
(172.16.33.18) (171.70.10.78) (171.10.20.78)
Translating ?test002?...domain server (172.16.33.18) [OK] 
Trying test002.rtr.abc.com (171.68.23.130)... Open

Это поведение весьма вероятно и имеет место, когда маршрутизатору требуется создать запись протокола разрешения адресов (ARP) для сервера DNS. По умолчанию маршрутизатор поддерживает ARP-запись в течение четырех часов. В периоды низкой активности маршрутизатору требуется дополнить ARP-запись и затем выполнить запрос DNS. Если ARP-запись для сервера DNS отсутствует в ARP-таблице маршрутизатора, при передаче только одного запроса DNS произойдет сбой. Поэтому отправляются два запроса: один для получения ARP-записи, если необходимо, а второй — для отправки запроса DNS. Такое поведение является обычным для приложений TCP/IP.

Поддержка | Synology Inc.

Служба ремонта Synology

Synology предоставляет гарантийное обслуживание всех аппаратных продуктов. Восстановительный ремонт выполняется специалистами Synology, и мы тщательно отслеживаем все детали процесса, гарантируя, что компонент будет отремонтирован надлежащим образом. Для некоторых моделей профессионального уровня доступно продление срока ограниченной гарантии на оборудование.

Служба ремонта

Указанные компоненты будут отремонтированы или восстановлены в течение гарантийного срока в соответствии со стандартом Synology (с новыми или восстановленными компонентами), чтобы гарантировать правильную работу компонентов после ремонта.

Прочитайте это перед тем, как обращаться в службу ремонта.

• Прочитайте и примите Warranty agreement.
• Гарантия может отличаться для разных моделей, поэтому убедитесь, что гарантия распространяется на указанный компонент. Learn more
• Убедитесь, что вы выполнили checklist и определили, что причина неисправности в оборудовании.

Примечание.
В обычных условиях гарантия активируется с даты, указанной в счете, выставленном компанией Synology, ее уполномоченными дистрибьюторами или реселлерами.

Процедура ремонта

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

Чтобы подать заявку на услуги ремонта от Synology, войдите в учетную запись Synology Account.

Примечание.

1. Перед отправкой NAS в службу ремонта необходимо выполнить резервное копирование личных данных и конфигураций. Компания Synology и ее авторизованные партнеры не несут ответственности за сохранение вашей конфиденциальности.
2. Устройство и система будут восстановлены до заводских настроек по умолчанию, и исходные данные нельзя будет восстановить. Компания Synology не несет ответственность за потерю данных во время ремонта.
3. Гарантия распространяется только на продукты Synology. На жесткие диски и другие совместимые устройства гарантия не распространяется.
4. Компания Synology сохраняет за собой все права на окончательное решение, и оно будет принято исключительно компанией Synology.

D-Link

Вопрос: Что такое Port Forwarding и как его настраивать на интернет-маршрутизаторах серии DIR-XXX

Ответ: 

Port Forwarding — это технология, которая позволяет обращаться из Интернет к компьютеру во внутренней сети за маршрутизатором, использующим NAT (NAPT). Доступ осуществляется при помощи перенаправления трафика определенных портов с внешнего адреса маршрутизатора на адрес выбранного компьютера в локальной сети.

Такое перенаправление нужно если вы, к примеру, используете пиринговые сети, или хотите развернуть на локальном компьютере сервер с доступом из Интернет. Также перенаправление иногда требуется для многопользовательских игр.

Подключаете устройство к компьютеру проводом, поставляющимся в комплекте. Открываете Internet Explorer и набираете в строке адреса 192.168.0.1. Подключение по беспроводной связи к устройству или попытка открытия настроек через любой другой Интернет-браузер не всегда могут быть успешными.
Login: admin
Password: (оставьте поле пустым)

На вкладке ADVANCED, выбираете вкладку Port Forwarding.

Создаваемое правило, выделяем галочкой.
Name — Имя правила, задаётся любой желаемый параметр (латинские буквы).
Application Name — Вы можете выбрать один из предустановленных виртуальных серверов — FTP, HTTP, HTTPS, DNS, SMTP, POP3, Telnet, IPSec, PPTP и нажать кнопку «
Public Port — На какой порт должны обращаться внешние клиенты.
Traffic Type — Вы можете выбрать один из протоколов TCP, UDP или любой (ANY).
IP Address — IP Address компьютера на котором запущен реальный сервер.
Computer Name — Вы можете задать IP Address компьютера вручную или выбрать из списка Computer Name.
Private port — Порт на котором работает реальный сервер.
Schedule — Вы можете выбрать одно из созданных расписаний (Например: Always — всегда) или создать новое, нажав на кнопку Add New.

Сохраняете настройки нажатием клавиши Save Settings.

Перенаправления в HTTP — HTTP

URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним  URL  адресом. HTTP предоставляет специальный вид ответов, HTTP redirect, для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.

В HTTP, перенаправление вызывается при отправке сервером специального ответа на запрос: redirects. HTTP перенаправление, это ответы с кодом статуса3xx. Когда браузер получает ответ перенаправления, он использует новый предоставленный URL-адрес и немедленно загружает его: в большинстве случаев переадресация невидима для пользователя, за исключением небольшого влияния производительность.

Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.

Постоянные перенаправления

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

[1] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не-GET методов.

Временные перенаправления

Иногда, доступ к запрашиваемому ресурсу не может быть предоставлен из определенного места, но может быть предоставлен из другого. В этом случае, могут быть использованы временные перенаправления. Поисковые роботы не запоминают новую, временную ссылку. Временные перенаправления также используются, когда создаются, обновляются, или удаляются ресурсы, которые представляют временные страницы.

Код	Текст	Обработка метода	Случаи использования
302	Found	GET методы неизменны. Другие методы могут  быть превращены в GET.[2]	Веб-страница недоступна по непредвиденым причинам. В этом случае поисковые роботы не будут обновлять свои ссылки.
303	See Other	GET методы неизменны. Другие превращены в GET (тело запроса теряется).	Используется для перенаправления после PUT или POST для предотвращения обновления страницы, что может спровоцировать повторный вызов операции.
307	Temporary Redirect	Метод и тело запроса  неизменны.	Веб-страница недоступна по непредвиденным причинам. В этом случае поисковые роботы не будут обновлять свои ссылки. Лучше чем код 302 когда не-GET ссылки/операции доступны на сайте.

[2] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не-GET методов.

Специальные перенаправления

В добавок к обычным перенаправлениям, есть 2 специальные.  Перенаправление с кодом 304 (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом 300 (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.

HTTP перенаправления это не единственный способ переадресации. Есть еще два метода: HTML перенаправления используют элемент <meta> , и JavaScript перенаправления используют DOM.

HTML перенаправления

HTTP перенаправления более предпочтительный способ создания перенаправлений, но, иногда, у веб-разработчиков нету контроля над сервером или возможности настроить его.  Для таких особых случаев, разработчики могут создать HTML страницу с элементом  <meta> и установить атрибуту http-equiv значение refresh в блоке <head>. Когда страница отображается, браузер найдет этот элемент и перейдет на указанную страницу.

<head>
  <meta http-equiv="refresh" content="0; URL=http://www.example.com/" />
</head>

Атрибут content начинается с числа, которое означает, сколько секунд браузер должен ждать, прежде чем перейти по данной ссылке. Всегда устанавливайте 0, для лучшей доступности.

Очевидно, этот метод работает только с HTML страницами и не может использоваться для изображений или другого типа контента.

Заметьте, что перенаправления не позволяют работать должным образом кнопке «Назад» в браузере: вы можете вернуться на страницу назад, но мгновенно будете перенаправлены на страницу с которой пришли.

JavaScript перенаправления

Перенаправления в JavaScript создаются установкой значения свойства window.location и новая страница загрузиться.

window.location = "http://www.example. com/";

Как и HTML перенаправления, этот тип не будет работать на всех ресурсах, и очевидно, что работает только на стороне клиента, который выполнит JavaScript. С другой стороны, вы можете вызвать перенаправление, только тогда, когда исполнится определенное условие.

Приоритетность

При использовании трех возможных способов URL перенаправления, некоторые методы могут быть вызваны одновременно, но какой из них будет применен первым? Порядок приоритетов следующий:

1. HTTP перенаправления всегда выполняются первыми, пока еще страница даже не была передана,  и конечно же, пока еще не прочитана.
2. HTML перенаправления (<meta>) выполняються только, если перенаправление не было в выполнено в HTTP.
3. JavaScript перенаправления используются как последняя возможность перенаправления, и работают только если разрешено выполнение JavaScript на клиентской стороне.

Используйте HTTP перенаправления, когда это возможно, и не используйте элемент <meta>. Если разработчик изменяет HTTP перенаправление и забывает изменить HTML перенаправление , тогда они больше не идентичны, и закончится это вечным циклом или другим ночным кошмаром.

Есть много случаев для использования перенаправлений, но поскольку они влияют на производительность, то должны использоваться как можно реже.

Связывание доменов

В идеале, есть только одно место, и следовательно один URL адрес, для одного ресурса. Но, есть несколько причин, чтобы иметь альтернативные имена для ресурса (несколько доменов, как с, так и без префикса www или более короткие и лёгкие для запоминания адреса, …). В этих случаях, использовать перенаправление к одному истинному URL адресу, более подходящий вариант, чем дублировать ресурс.

Связывание доменов может быть необходимым по нескольким причинам:

• Расширение вашего сайта. Распространенный случай, когда ваш сайт находится под доменом www.example.com , а доступ к страницам должен быть возможным также из example. com . В этом случае создаются перенаправления для  страниц из example.com к страницам www.example.com. Вы также можете предоставлять обычно используемые имена синонимов или частые опечатки ваших доменных имен.
• Переезд на другой домен. К примеру, ваша компания была переименована и вы хотите чтобы люди которые обычно использовали старый сайт компании находили вас под новым именем.
• Принужденный HTTPS. Запросы к HTTP версии вашего сайта буду перенаправлены к HTTPS версии.

Сохранения ссылок рабочими

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

Не смотря на то, что данный метод работает также для внутренних ссылок, вы должны избегать внутренних перенаправлений. Перенаправления имеют большое влияние на производительность, и если вы имеете возможность избежать их, корректируя внутренние ссылки, тогда делайте так.

Временные ответы для небезопасных запросов

Небезопасные запросы изменяют состояние сервера и пользователь не должен не нарочно запросить их.  Обычно, вы не хотите чтобы ваши пользователи повторно отправляли PUT, POST или DELETE запросы. Если вы только обслуживаете запросы, простое нажатие кнопки перезагрузки повторно отправит запрос. 

В этом случае, сервер вернет ответ 303 (Смотреть другие), который будет содержать правильную информацию, но если кнопка перезагрузки будет нажата, эта страница просто отобразится повторно без ответа на небезопасный запрос.

Временные ответы на долгие запросы

Некоторые запросы могут потребовать больше времени сервера, например запрос DELETE, который срабатывает по расписанию. В этом случае, ответом будет перенаправление 303 (Смотреть другие), которое связывает со страницей показывающей, что действие было запланировано, и в результате информирует о процессе или позволяет отменить запрос. /images/(.*)$ http://images.example.com/$1 permanent;

IIS

В IIS, вы используете элемент <httpRedirect> для настройки перенаправлений.

Циклы перенаправлений случаются когда за успешным перенаправлением следует другое, которое уже было выполнено. Другими словами, существует такой цикл, который никогда не закончится и в конечном счете ни одна страница не будет найдена.

В большинстве случаев это проблема сервера, и если сервер не может обнаружить её, то отправит код статуса 500 Internal Server Error. Если вы встретите такую ошибку вскоре после редактирования настроек сервера, то это скорее всего цикл перенаправлений.

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

тогда, как Chrome:

This Webpage has a redirect loop

В обоих случаях, пользователь не может ничего сделать (в отличие от ошибки на стороне клиента, например, несоответствие файлов куки или кеша).

Важно избегать циклов перенаправлений, так как они полностью нарушают работу пользователя.

Общие сведения о перенаправлении DNS

Разъяснения

Иногда возникает путаница между пересылкой DNS и перенаправлением HTTP или использованием записей CNAME для обозначения псевдонимов DNS.

Перенаправление DNS относится исключительно к процессу, при котором определенные запросы DNS пересылаются на назначенный DNS-сервер для разрешения.

Это не решение для перенаправления одного домена на другой, для которого вы бы использовали перенаправление HTTP.Также он бесполезен для создания псевдонима субдомена для другого домена: это работа записей CNAME (каноническое имя).

Что такое перенаправление DNS?

Перенаправление DNS — это процесс, при котором определенные наборы DNS-запросов обрабатываются назначенным сервером, а не исходным сервером, с которым связывается клиент. Обычно все DNS-серверы, которые обрабатывают разрешение адресов в сети, настроены на пересылку запросов для адресов, находящихся за пределами сети, на выделенный сервер пересылки.

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

Терминология

Терминология пересылки DNS может немного сбивать с толку, потому что сервер пересылки имеет DNS-запросы, пересылаемые ему DNS-серверами, которые не являются пересылками — попробуйте повторить это пять раз быстро! Сервер пересылки DNS следует рассматривать как назначенный сервер, на который другие DNS-серверы в сети пересылают определенное подмножество запросов (либо для внешних адресов, либо для определенных внутренних адресов).Затем он отправляет (пересылает) эти запросы на разрешение другим DNS-серверам.

Зачем использовать переадресацию DNS для внешних адресов?

Если DNS-сервер не назначен в качестве сервера пересылки, на который направляются внешние запросы, то все DNS-серверы в сети будут обрабатывать внешние запросы, что означает, что они будут запрашивать внешние преобразователи. Это нежелательно по двум основным причинам:

1. Внутренняя информация DNS может быть открыта в открытом Интернете. Гораздо лучше иметь строгое разделение между внутренним и внешним DNS.Раскрытие внутренних доменов в открытом Интернете создает потенциальную уязвимость безопасности и конфиденциальности.

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

Перенаправление DNS для внутренних адресов

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

Также опубликовано на Medium.

Перенаправление

DNS — Хостинг Википедия

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

Объяснение переадресации DNS

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

Перенаправление DNS

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

Но как на самом деле работает перенаправление DNS?

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

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

Лучшие методы пересылки DNS

В терминах системы доменных имен (DNS) сервер пересылки DNS — это DNS-сервер, который используется для пересылки DNS-запросов для внешних DNS-имен на DNS-серверы за пределами этой сети.Он делает это с DNS-запросами, которые он не может разрешить локально, то есть с DNS-запросами, о которых он лично не знает. Используя DNS-серверы пересылки, вы можете повысить эффективность разрешения имен для компьютеров в вашей сети, которые запрашивают DNS-имена за пределами вашей сети (например, имена в Интернете).

DNS-серверы на базе Windows поставляются с предустановленными функциями автоматического запроса имен в Интернете с использованием метода, называемого «DNS Root Hints». После установки роли DNS на сервере под управлением Windows Root Hints будут автоматически добавлены, и, практически говоря, позволят вам разрешить любое имя в Интернете, если у вас есть подключение к Интернету для этого сервера и нет правила брандмауэра, которое блокирует это от запросов к этим серверам.Никаких дополнительных настроек выполнять не нужно. Вы можете найти обновленный список корневых ссылок на ftp://ftp.rs.internic.net/domain/db.cache.

Пример списка корневых ссылок с ftp://ftp.rs.internic.net/domain/db.cache. (Изображение: Джефф Джеймс)

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

Примечание : Вы также можете настроить свой сервер для пересылки запросов на разные серверы в зависимости от DNS-суффикса, указанного в DNS-запросе. Для этого соответствующим образом настройте условную пересылку. Я расскажу об этом в следующей статье.

Рекомендации по перенаправлению DNS с Windows Server 2012 R2

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

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

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

Разница между использованием DNS-серверов пересылки и корневых подсказок

Какое решение является лучшим: использовать корневые подсказки или DNS-серверы моего локального интернет-провайдера в качестве пересылки? Для меня это часто задаваемый вопрос.

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

• Связано: Тема форума ИТ-базы знаний Петри — Корневые подсказки DNS

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

Во всех этих случаях вам потребуются правильные имена и IP-адреса вашего интернет-провайдера. Лучший способ узнать правильные имена и IP-адреса вашего интернет-провайдера — это выполнить поиск по списку в вашей любимой поисковой системе или просто обратиться в службу технической поддержки вашего интернет-провайдера.

Другая причина моей рекомендации связана с настройкой межсетевого экрана.Относительно легко разрешить DNS-запросы к 2 или 3 конкретным DNS-серверам ISP, используемым для серверов пересылки, вместо того, чтобы позволить DNS запрашивать большой список внешних корневых серверов подсказок и связанный рекурсивный трафик, который будет результатом этих запросов.

Наша программа предварительной оценки Petri Office 365 предназначена для обмена подробными знаниями от ведущих экспертов по Office 365. Доставляется раз в месяц на ваш почтовый ящик.

Petri.com может использовать вашу контактную информацию для предоставления обновлений, предложений и ресурсов, которые могут вас заинтересовать.Вы можете отписаться в любое время. Чтобы узнать больше о том, как мы управляем вашими данными, вы можете прочитать нашу Политику конфиденциальности и Условия использования.

! Уже являетесь участником Petri.com? Войдите здесь для регистрации в 1 клик.

Вам нужно запомнить одну важную вещь. Если вы в будущем смените своего интернет-провайдера, вы также должны будете изменить информацию DNS-сервера пересылки, поскольку, скорее всего, новый интернет-провайдер заблокирует DNS-запросы старого интернет-провайдера на основе вашего внешнего IP-адреса. Кроме того, когда вы используете подключение к Интернету, которое обеспечивает балансировку нагрузки подключений от нескольких интернет-провайдеров, вам может потребоваться проконсультироваться со всеми вашими интернет-провайдерами, чтобы узнать, как правильно настроить серверы пересылки DNS, или вы можете столкнуться с ошибкой разрешения имен всякий раз, когда ваше соединение переключается на другой провайдер.Вам не нужно беспокоиться об этом, если вы используете Root Hints.

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

DNS-перенаправление и условное перенаправление | Энтони Э.Альварес | Tech Jobs Academy

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

Мы обсудим два метода: пересылка и условная пересылка. Чтобы понять преимущества условной пересылки, мы должны сначала понять, как работает пересылка.

В простом примере сервер пересылки DNS отправляет запросы имен внешних доменов на удаленные DNS-серверы за пределами своей локальной сети для разрешения. Запросы внутреннего имени обрабатываются внутренним DNS-сервером.

Источник: https://technet.microsoft.com/en-us/library/cc782142(v=ws.10).aspx Клиент DNS отправляет запрос имени на локальный DNS-сервер. Условная пересылка не настроена для запрошенного домена. Запрос отправляется в Root Hints для разрешения. Источник Blogspot.com

Если на DNS-сервере не указан сервер пересылки для имени, указанного в запросе, он может попытаться разрешить запрос, используя стандартную рекурсию с использованием корневого файла подсказок.

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

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

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

Рекурсивные запросы имен работают быстрее, чем итеративные запросы имен

DNS-сервер, настроенный на использование сервера пересылки, будет вести себя иначе, чем DNS-сервер, который не настроен на использование сервера пересылки. Вот как работает DNS-сервер при пересылке:

1. Когда DNS-сервер получает запрос имени, он пытается разрешить этот запрос, используя свои первичные зоны, вторичные зоны и, наконец, свой кеш в указанном порядке.

2. Если запрос имени не может быть разрешен с использованием данных локальной зоны или кеша, он перенаправит запрос на DNS-сервер, назначенный в качестве сервера пересылки. В результате не будет использоваться метод корневых подсказок для разрешения имен.

3. Исходный DNS-сервер, получивший первоначальный запрос, ненадолго дождется ответа от сервера пересылки. Если это не удастся, он попытается связаться с DNS-серверами, указанными в его корневых подсказках, в крайнем случае.

Серверы условной пересылки позволяют улучшить разрешение имен между внутренними (частными) пространствами имен DNS, которые не являются частью пространства имен DNS в Интернете, например, в результате слияния компаний.

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

Давайте рассмотрим два примера, где условная пересылка действительно может пригодиться.Первый пример — это внутреннее имя, а второй — сценарий разрешения внешнего имени.

Пример 1.

Разрешение имени в интрасети

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

1. DNS-сервер получает запрос для сетей.example.microsoft.com.
2. Он сравнивает это доменное имя с microsoft.com и example.microsoft.com.
3. DNS-сервер определяет, что example.microsoft.com — это имя домена, которое более точно соответствует запросу имени домена.
4. DNS-сервер перенаправляет запрос на DNS-сервер с IP-адресом 172.31.255.255, который связан с example.microsoft.com.

DNS-клиент запрашивает запрос внутреннего имени, настроенного для условной пересылки DNS. Источник: Technet

Пример 2: разрешение имен в Интернете

DNS-серверы могут использовать серверы условной пересылки для разрешения запросов между доменными именами DNS компаний, которые обмениваются информацией. Например, две компании, Widgets Toys и TailspinToys, хотят улучшить то, как DNS-клиенты Widgets Toys разрешают имена DNS-клиентов Tailspin Toys. Администраторы Tailspin Toys информируют администраторов Widgets Toys о наборе DNS-серверов в сети Tailspin Toys, на которые Widgets могут отправлять запросы для домена dolls.tailspintoys.com. DNS-серверы в сети Widgets Toys настроены на пересылку всех запросов для имен, оканчивающихся на dolls.tailspintoys.com на назначенные DNS-серверы в сети для Tailspin Toys. Следовательно, DNS-серверам в сети Widgets Toys не нужно запрашивать свои внутренние корневые серверы или корневые серверы Интернета для разрешения запросов на имена, заканчивающиеся на dolls.tailspintoys.com.

Результат — более высокая производительность, меньшая пропускная способность сети и более довольные конечные пользователи, потому что их запросы имен между разными доменами решаются быстрее.

Локальный DNS-сервер перенаправляет все запросы имен внешних сайтов на удаленный DNS-сервер.

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

Настраивая DNS-серверы в одном внутреннем пространстве имен для пересылки запросов на полномочные DNS-серверы во втором внутреннем пространстве имен, серверы условной пересылки обеспечивают разрешение имен между двумя пространствами имен без выполнения итеративного запроса имени в пространстве имен DNS в Интернете, что приводит к лучшая производительность и использование DNS-серверов и снижение трафика в подсети локальной сети (LAN).

Источник: https://technet.microsoft.com/en-us/library/cc757172(v=ws.10).aspx

ЛВС — это компьютерная сеть, которая соединяет компьютеры на ограниченной территории, например в жилом доме, школе, лаборатория или офисное здание. Локальная сеть принципиально отличается от глобальной сети (WAN), в которой две или более LAN соединены и, таким образом, покрывают большее географическое расстояние и могут включать арендованные телекоммуникационные каналы, в то время как среда для LAN управляется локально.

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

Инструкции по настройке условного сервера пересылки DNS для разрешения внешних доменных имен с помощью Windows Server 2012 R2 описаны ниже.

1. В дереве консоли дважды щелкните соответствующий DNS-сервер. Разверните DNS , а затем дважды щелкните Применимый DNS-сервер .

Windows 2012 R2 Server Manager> Меню «Инструменты»> DNS Manager

2. В дереве консоли дважды щелкните соответствующий DNS-сервер. Разверните DNS , а затем дважды щелкните Применимый DNS-сервер .

3. В дереве консоли щелкните Серверы условной пересылки , а затем в меню Действие щелкните Новый сервер условной пересылки .

В меню «Действие» выберите «Новый сервер условной пересылки

» 4. В DNS-домене введите полное доменное имя (FQDN) домена, для которого вы хотите пересылать запросы.

Добавьте IP-адрес DNS и установите флажок Сохранить этот сервер условной пересылки в Active Directory

5. Щелкните IP-адреса главных серверов в списке , введите IP-адрес сервера, на который вы хотите пересылать запросы для указанного домена DNS, а затем нажмите Введите .

6.Установите флажок « Сохранить этот сервер условной пересылки в Active Directory » и реплицируйте его.

Теперь все запросы DNS-запросов для Contoso.com будут разрешены на 131.107.1.2.

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

Даже если у вас нет доступа к Windows Server или возможности запустить локальный DNS-сервер, вы все равно можете поэкспериментировать с пересылкой DNS, используя Google Public DNS или Cisco OpenDNS. Оба являются бесплатными вариантами, которые позволяют экспериментировать с переадресацией DNS. В обоих случаях весь ваш DNS-трафик будет перенаправлен на них, а не на вашего интернет-провайдера (ISP). Преимущества — повышенная производительность и безопасность от фишинга, вредоносных программ, бот-сетей и целевых сетевых атак.В обоих случаях ваш трафик, вероятно, будет отслеживаться и профилироваться, поэтому покупатель будьте осторожны. По крайней мере, эти службы помогут вам понять, как DNS Forwarding работает в реальной жизни.

Хотя настройка перенаправления DNS в Windows Server сложна, на обычном компьютере с Windows, однако, для настройки требуется только один экран.

Google Public DNS IP-адрес: 8.8.8.8 и 8.8.4.4

Инструкции

1. Открыть панель управления
2. Открыть Сеть и Интернет
3. Открыть Центр управления сетями и общим доступом
4. Нажмите Изменить настройки адаптера
5. Просмотр листа свойств для активного сетевого подключения
6. Просмотр листа свойств для Интернет-протокола версии 4

OpenDNS. com

Чтобы использовать OpenDNS вместо Google Public DNS, где написано « Preferred DNS Server » и « Alternate DNS server », используйте IP-адрес OpenDNS IP.

Для OpenDNS всегда используются следующие IP-адреса:

• 208.67.222.222
• 208.67.220.220

Если у вас есть вопросы или вам нужна дополнительная информация об условной переадресации DNS, оставьте свои комментарии ниже. Пока вы занимаетесь этим, почему бы вам не любить, не комментировать и не подписываться на эту статью, если такие темы вас интересуют.

Спасибо, Сарон Йитбарек, за редактирование этой статьи.

Что такое DNS-сервер пересылки?

Сервер пересылки — это сервер системы доменных имен (DNS) в сети, который пересылает запросы DNS для внешних имен DNS на серверы DNS за пределами этой сети. Вы также можете пересылать запросы в соответствии с определенными доменными именами, используя серверы условной пересылки.

Вы назначаете DNS-сервер в сети в качестве сервера пересылки, настраивая другие DNS-серверы в сети для пересылки запросов, которые они не могут разрешить локально, на этот DNS-сервер.Используя сервер пересылки, вы можете управлять разрешением имен для имен вне вашей сети, таких как имена в Интернете, и повышать эффективность разрешения имен для компьютеров в вашей сети.

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

DNS-сервер, настроенный на использование сервера пересылки, ведет себя иначе, чем DNS-сервер, который не настроен на использование сервера пересылки. DNS-сервер, настроенный на использование сервера пересылки, ведет себя следующим образом:

1. Когда DNS-сервер получает запрос, он пытается разрешить этот запрос, используя зоны, которые он размещает, и свой кэш.
2. Если запрос не может быть разрешен с использованием локальных данных, DNS-сервер пересылает запрос на DNS-сервер, назначенный в качестве сервера пересылки.
3. Если серверы пересылки недоступны, DNS-сервер пытается использовать свои корневые ссылки для разрешения запроса.

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

О перенаправлении DNS

Вы можете настроить Firebox для пересылки DNS-запросов с компьютеров в вашей сети на DNS-сервер. Например, вы можете использовать переадресацию DNS для отправки DNS-запросов из филиала на удаленный DNS-сервер в головном офисе.

Вы можете включить пересылку DNS из веб-интерфейса Fireware, диспетчера политик и интерфейса командной строки.Вы также можете добавить условные правила переадресации DNS. Эти правила позволяют отправлять DNS-запросы на разные DNS-серверы на основе имени домена в запросе.

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

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

В Fireware v11.12.1 или ниже вы можете включить переадресацию DNS только из командной строки, а условная пересылка DNS не поддерживается. Если вы включили переадресацию DNS перед обновлением до Fireware v11.12.2, перенаправление DNS остается включенным, но функциональные возможности меняются, как описано в этом разделе.
Инструкции по включению перенаправления DNS в Fireware v11.12.1 или ниже см. В разделе «Как включить перенаправление DNS» в базе знаний WatchGuard.

DNS-серверов на вашем Firebox

Эти DNS-серверы могут быть настроены на вашем Firebox:

• Сетевой DNS-сервер — DNS-сервер по умолчанию для всех интерфейсов и локальных процессов на Firebox
• Интерфейсный DNS-сервер — DNS-сервер для интерфейсов, которые вы указываете
• Условный DNS-сервер — DNS-сервер для доменных имен и интерфейсов, которые вы указываете в правиле переадресации DNS
• DNS-сервер, полученный от вашего интернет-провайдера — когда ваш Firebox настроен как DHCP-клиент или PPPoE-клиент
• DNSWatch server — DNS-сервер при включенном DNSWatch, в некоторых случаях

Каждый DNS-сервер имеет разные цели и настраивается в другом месте в настройках Firebox.

Некоторые DNS-серверы имеют приоритет над другими. При включении правила пересылки DNS имейте в виду, что:

• Серверы условного DNS имеют приоритет над сервером DNS сети и серверами DNSWatch.
• Интерфейсный DNS-сервер имеет приоритет над условным DNS-сервером.

Для получения дополнительной информации о приоритете DNS-сервера см. О DNS в Firebox.

Как это работает

Вы можете включить перенаправление DNS и условное перенаправление DNS в следующих сетевых режимах:

• Смешанный режим маршрутизации
• Режим прямого подключения
• Мостовой режим

При включении переадресации DNS:

• Вы должны выбрать один или несколько доверенных, необязательных или настраиваемых интерфейсов для участия в перенаправлении DNS.
• Локальные процессы в Firebox используют Firebox в качестве DNS-сервера.
• Firebox кэширует результаты DNS-запросов (до 10 000 записей).
• Если вы не добавляете условные правила пересылки DNS, запросы DNS, отправленные на локальный IP-адрес Firebox, перенаправляются на указанный вами сетевой DNS-сервер. Firebox кэширует результаты этих запросов.
• Если вы настроили Firebox как DHCP-сервер, DHCP-клиенты в вашей сети автоматически используют IP-адрес интерфейса в качестве DNS-сервера, если вы не укажете DNS-сервер в настройках DHCP-сервера.
• DNS-трафик, отправленный с интерфейсов, настроенных для переадресации DNS на Firebox, разрешен. Политика DNS и политика прокси DNS применяются только к сквозному трафику DNS.
• Если вы настроили интерфейс Firebox как DHCP-сервер, а интерфейс настроен для пересылки DNS:
  • Если вы не укажете DNS-сервер в настройках DHCP, DHCP-сервер автоматически предоставит IP-адрес интерфейса Firebox как DNS-сервер. Происходит перенаправление DNS.
  • Если вы укажете DNS-сервер, отличный от IP-адреса интерфейса Firebox в настройках DHCP, DHCP-сервер автоматически предоставит IP-адрес указанного вами DNS-сервера.Пересылка DNS не происходит.

Firebox может обрабатывать до 10 000 DNS-запросов одновременно.

Если вы включили ведение журнала для переадресации DNS, Firebox для генерации сообщения журнала при пересылке DNS.

Если у вас есть соединение виртуального интерфейса BOVPN между сайтами и вы настраиваете переадресацию DNS, вы должны добавить IP-адрес виртуального интерфейса в настройки виртуального интерфейса BOVPN, чтобы пересылка DNS работала через VPN.IP-адрес виртуального интерфейса необходим, поскольку DNS-сервер должен направлять трафик обратно на этот IP-адрес. Дополнительные сведения об IP-адресах виртуального интерфейса см. В разделе Настройка IP-адресов виртуального интерфейса BOVPN.

В Fireware v12.4 или выше вы можете включить DNSWatch в режиме моста. Чтобы Firebox разрешал имена хостов в локальных доменах, вы должны создать правила переадресации DNS для локальных доменов, которые определяют локальные DNS-серверы.

Условная переадресация DNS

Вы можете добавить условные правила переадресации DNS.Когда вы добавляете правило пересылки, Firebox использует кэшированную информацию для ответа на запрос DNS или пересылает запрос на DNS-сервер, указанный в правиле.

Например, в Firebox филиала, который имеет VPN-подключение к головному офису, вы можете настроить параметры DNS на:

• Перенаправляйте DNS-запросы для внутреннего домена example.com через VPN на DNS-сервер в головном офисе.
• Перенаправить все остальные DNS-запросы на общедоступный DNS-сервер, который физически находится ближе к филиалу.

Конфигурация

Когда вы включаете условную переадресацию DNS в Firebox, вы можете добавить правила пересылки DNS. Для каждого правила переадресации DNS вы указываете следующие параметры:

Доменное имя

Добавьте одно или несколько доменных имен. Вы можете указать неограниченное количество доменных имен.Более конкретные доменные имена имеют приоритет. Порядок доменных имен не имеет значения.

DNS-сервер

Укажите DNS-сервер. Запросы для добавленного вами доменного имени отправляются на указанный вами DNS-сервер. Вы можете добавить до четырех DNS-серверов для каждого доменного имени. Firebox связывается с первым DNS-сервером в списке и при необходимости связывается с другими DNS-серверами.

Пример

В этом примере в филиале настроен Firebox как DHCP-сервер.Интерфейсный DNS-сервер не указан в настройках DHCP-сервера. Внутренний DNS-сервер находится в сети в штаб-квартире. В Firebox в филиале правило условной переадресации DNS отправляет запросы для example.com на DNS-сервер в головном офисе. Все остальные DNS-запросы отправляются на сетевой DNS-сервер, указанный в Firebox.

Как это работает:

1. В филиале DHCP-клиент в сети отправляет DNS-запрос для примера доменного имени.com.
2. Firebox получает запрос и проверяет свой DNS-кеш.
3. Если кеш не содержит записи для example.com, Firebox проверяет свой список пересылки DNS.
4. Если example.com включен в список пересылки DNS, Firebox пересылает запрос на DNS-сервер, указанный для этого доменного имени.
   В нашем примере запрос пересылается на удаленный DNS-сервер в штаб-квартире, 10.50.1.253.
5. Если example.com не включен в список переадресации DNS, Firebox пересылает DNS-запрос на сетевой DNS-сервер, которым в нашем примере является 4.2.2.1.

На этих изображениях показаны настройки сетевого DNS и переадресации DNS для нашего примера:

Настройки переадресации DNS в веб-интерфейсе

WSM Help,en-US.WSM Online»>

Параметры пересылки DNS в диспетчере политик

В Fireware v12.6.4 или выше, вы можете отключить кеш DNS. Для получения дополнительной информации см. О DNS в Firebox.

См. Также

Настройка сетевых серверов DNS и WINS

Настройка серверов DNS и WINS для Mobile VPN с IPSec

Web UI Help,en-US.Web UI Online,en-US.WSM Help,en-US.WSM Online»> О DNS в Firebox

О WatchGuard DNSWatch

Настроить DNS-сервер | Игуасио

Обзор

Прикладные службы в кластерах Iguazio Data Science Platform («платформа») работают поверх Kubernetes (см. «Службы приложений и инструменты»).Доступ к сервисам осуществляется через входящие потоки Kubernetes, которые действуют как шлюзы, обеспечивающие доступ к кластерным приложениям и внутренним сервисам через URL-адреса сервисов.
Платформа использует DNS-сервер CoreDNS для разрешения URL-адресов кластерных служб и сопоставления их с IP-адресами внутренних служб.
DNS-сервер кластера должен быть настроен на использование условной пересылки, чтобы DNS-запросы, содержащие доменное имя кластера, и только такие запросы, перенаправлялись на платформу для разрешения.
В этом документе представлены пошаговые инструкции по настройке условной переадресации DNS в Linux или Windows.

Терминология

DNS

Domain Name System — интернет-сервис, переводящий доменные имена в IP-адреса.

Перенаправление DNS

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

Условные форвардеры

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

FQDN

Полное доменное имя

Конфигурация DNS в Linux

Выполните следующие шаги, чтобы настроить условную переадресацию DNS в Linux с помощью BIND — популярного DNS-сервера с открытым исходным кодом от Internet Systems Consortium (ISC), который можно найти в большинстве дистрибутивов Linux; Дополнительные сведения о BIND см. в разделе «Дополнительные ресурсы» этого документа.

Примечание

Следующая процедура предполагает, что у вас есть настроенный сервер BIND.

1. Откройте файл конфигурации сервера имен BIND (named.conf) в текстовом редакторе и добавьте следующие строки; замените заполнитель на полное доменное имя кластера платформы, на который вы хотите перенаправлять запросы, и замените заполнители на IP-адреса узлов основных данных кластера:

     зона "<доменное имя>" {
       типа вперед;
       только вперед;
       пересылки {; [; ...]};
   };
     

2. Проверьте и перезагрузите конфигурацию, выполнив следующие команды из командной строки Linux:

     с именем checkconf
   rndc reload
     

Конфигурация Windows DNS

Выполните следующие шаги, чтобы настроить условную переадресацию DNS в Windows.

Примечание

Следующие инструкции совместимы с Windows Server 2012 R2.
Конкретные шаги и пункты меню могут отличаться в других версиях Windows.

1. Откройте диспетчер сервера Windows (например, введя ServerManager в командной строке Windows).
   В окне диспетчера сервера выберите вкладку Инструменты.
   Затем выберите DNS из списка инструментов.

2. В окне диспетчера DNS выберите свой DNS-сервер.
   Затем выберите Серверы условной пересылки в дереве просмотра сервера.

3. Выберите «Действие» на панели инструментов верхнего меню, а затем выберите пункт меню «Новый сервер условной пересылки».

4. В окне «Новый условный экспедитор» —

   • В поле DNS Domain введите полное доменное имя кластера платформы, для которого вы хотите пересылать запросы.

   • В поле IP-адреса главных серверов добавьте IP-адреса узлов главных данных вашего кластера.

     No related posts.