Создание записей DNS для зон DNS Azure

• 03.03.2020
• Время чтения: 7 мин

В этой статье

Если вы не нашли то, что вы ищете, обратитесь к разделу Вопросы и ответы по доменам.Check the Domains FAQ if you don’t find what you’re looking for.

Если Azure является поставщиком услуг хостинга DNS, выполните действия, описанные в этой статье, чтобы проверить домен и настроить записи DNS для электронной почты, Skype для бизнеса Online и т. д.If Azure is your DNS hosting provider, follow the steps in this article to verify your domain and set up DNS records for email, Skype for Business Online, and so on.

Ниже перечислены основные записи, которые нужно добавить.These are the main records to add.

Когда вы добавите эти записи в Azure, ваш домен будет настроен для работы со службами Office 365.After you add these records at Azure, your domain will be set up to work with Office 365 services.

Примечание

Обычно на вступление изменений DNS в силу требуется около 15 минут. Однако иногда распространение внесенного изменения в системе DNS по всему Интернету занимает больше времени. Если после добавления записей DNS возникла проблема с потоком обработки почты или другие неполадки, см. статью Устранение неполадок после смены имени домена или записей DNS.Typically it takes about 15 minutes for DNS changes to take effect. However, it can occasionally take longer for a change you’ve made to update across the Internet’s DNS system. If you’re having trouble with mail flow or other issues after adding DNS records, see Troubleshoot issues after changing your domain name or DNS records.

Изменение записей сервера доменных именChange your domain’s nameserver (NS) records

Важно!

Эту процедуру необходимо выполнить на сайте регистратора доменных имен, на котором вы приобрели и зарегистрировали свой домен.You must perform this procedure at the domain registrar where you purchased and registered your domain.

При регистрации в Azure вы создали группу ресурсов в зоне DNS и назначили имя домена этой группе ресурсов.When you signed up for Azure, you created a resource group within a DNS zone, and then assigned your domain name to that resource group. Это имя домена регистрируется во внешнем регистраторе доменов; Azure не предоставляет службы регистрации доменов.That domain name is registered to an external domain registrar; Azure does not offer domain registration services.

Чтобы проверить и создать записи DNS для вашего домена в Office 365, сначала необходимо изменить серверов доменных имен в регистраторе доменных имен, чтобы они использовали серверов доменных имен Azure, назначенные группе ресурсов.To verify and create DNS records for your domain in Office 365, you first need to change the nameservers at your domain registrar so that they use the Azure nameservers assigned to your resource group.

Чтобы самостоятельно изменить серверы доменных имен на веб-сайте регистратора доменных имен, выполните следующее:To change your domain’s name servers at your domain registrar’s website yourself, follow these steps.

1. Найдите на веб-сайте регистратора домена область, в которой можно изменить серверы доменных имен для вашего домена.Find the area on the domain registrar’s website where you can edit the nameservers for your domain.

2. Создайте две записи серверов доменных имен, используя значения из приведенной ниже таблицы, либо измените существующие записи серверов доменных имен, чтобы они соответствовали следующим значениям:Either create two nameserver records by using the values in the following table, or edit the existing nameserver records so that they match these values. Ниже приведен пример назначенного серверов доменных имен Azure.An example of Azure assigned nameservers is shown below.

Первое имя сервера доменных имен: Используйте значение сервера имен, назначенное Azure.First nameserver: Use the name server value assigned by Azure.
Второе nameserver: Используйте значение сервера имен, назначенное Azure.Second nameserver: Use the name server value assigned by Azure.

Совет

You should use at least two name server records.You should use at least two name server records. Если на веб-сайте регистратора доменных имен указаны другие серверы, их следует удалить.If there are any other name servers listed at your domain registrar’s website, you should delete them.

3. Сохраните изменения.Save your changes.

Примечание

На распространение изменений, внесенных вами в записи серверов имен, в системе DNS по всему Интернету может потребоваться несколько часов. После этого ваша электронная почта и все остальные службы Office 365 будут настроены на работу с новым доменом.Your nameserver record updates may take up to several hours to update across the Internet’s DNS system. Then your Office 365 email and other services will be all set to work with your domain.

Добавление записи TXT для проверкиAdd a TXT record for verification

Прежде чем вы сможете использовать свой домен в Office 365, мы должны убедиться в том, что вы являетесь его владельцем. Если вы войдете в свою учетную запись на сайте регистратора доменных имен и создадите запись DNS, это послужит для Office 365 подтверждением того, что вы владеете доменом.Before you use your domain with Office 365, we have to make sure that you own it. Your ability to log in to your account at your domain registrar and create the DNS record proves to Office 365 that you own the domain.

Примечание

Эта запись используется исключительно для проверки принадлежности домена. При желании вы сможете удалить ее позже.This record is used only to verify that you own your domain; it doesn’t affect anything else. You can delete it later, if you like.

1. Чтобы приступить к работе, перейдите на страницу ваших доменов в Azure, используя эту ссылку.To get started, go to your domains page at Azure by using this link. Сначала вам потребуется выполнить вход.You’ll be prompted to log in first.

2. С помощью панели поиска на странице панели мониторинга введите DNS-зоны.Using the search bar on the Dashboard page, type in DNS zones. В окне Отображение результатов выберите пункт зоны DNS в разделе службы .In the results display, select DNS zones under the Services portion. После перенаправления выберите домен, который вы хотите обновить.Once you’ve been redirected, select the domain that you want to update.

3. На странице Параметры домена в области зона DNS выберите пункт + набор записей.On the Settings page for your domain, in the DNS zone area, select + Record set.

4. В поля для нового набора записей в области Добавление набора записей выберите значения из таблицы ниже.In the Add record set area, in the boxes for the new record set, select the values from the following table.

   В раскрывающихся списках выберите значения Type (тип ) и TTL (TTL ).(Choose the Type and TTL unit values from the drop-down lists.)

   ИмяName	ТипType	TTL (Срок жизни)TTL	Единица срока жизни TTL unit	ЗначениеValue
   @	TXTTXT	1,11	ЧасыHours	MS=ms XXXXXXXXMS=ms XXXXXXXX Примечание. Это пример. Используйте здесь собственное значение Назначение или адрес «указывает на» из таблицы в Office 365. Где это находится?Note: This is an example. Use your specific Destination or Points to Address value here, from the table in Office 365. How do I find this?

5. Нажмите кнопку ОК.Select OK.

6. Подождите несколько минут, пока созданная запись не будет обновлена в Интернете.Wait a few minutes before you continue, so that the record you just created can update across the Internet.

Теперь, когда запись добавлена на сайте регистратора доменных имен, вернитесь в Office 365 и подайте запрос на ее поиск.Now that you’ve added the record at your domain registrar’s site, you’ll go back to Office 365 and request Office 365 to look for the record.

Если Office 365 обнаружит правильную запись TXT, это значит, что домен проверен.When Office 365 finds the correct TXT record, your domain is verified.

1. В Центре администрирования перейдите на страницу Settings (Параметры) > Domains (Домены).In the admin center, go to the Settings > Domains page.

2. На странице Domains (Домены) выберите домен, который нужно проверить.On the Domains page, select the domain that you are verifying.

3. На странице Setup (Настройка) выберите Start setup (Начать настройку).On the Setup page, select Start setup.

4. На странице

   Проверка домена выберите Проверить.On the Verify domain page, select Verify.

Примечание

Обычно на вступление изменений DNS в силу требуется около 15 минут. Однако иногда распространение внесенного изменения в системе DNS по всему Интернету занимает больше времени. Если после добавления записей DNS возникла проблема с потоком обработки почты или другие неполадки, см. статью Устранение неполадок после смены имени домена или записей DNS.Typically it takes about 15 minutes for DNS changes to take effect. However, it can occasionally take longer for a change you’ve made to update across the Internet’s DNS system. If you’re having trouble with mail flow or other issues after adding DNS records, see Troubleshoot issues after changing your domain name or DNS records.

Добавление записи MX, необходимой для доставки сообщений электронной почты для вашего домена в Office 365Add an MX record so email for your domain will come to Office 365

1. Чтобы приступить к работе, перейдите на страницу ваших доменов в Azure, используя эту ссылку.To get started, go to your domains page at Azure by using this link. Сначала вам потребуется выполнить вход.You’ll be prompted to log in first.

2. На странице «панель мониторинга» в области » все ресурсы » выберите домен, который необходимо обновить.On the Dashboard page, in the All resources area, select the domain that you want to update.

3. На странице Параметры домена в области зона DNS выберите пункт + набор записей.On the Settings page for your domain, in the DNS zone area, select + Record set.

4. В поля для нового набора записей в области Добавление набора записей выберите значения из таблицы ниже.In the Add record set area, in the boxes for the new record set, select the values from the following table.

   В раскрывающихся списках выберите значения Type (тип ) и TTL (TTL ).(Choose the Type and TTL unit values from the drop-down lists.)

   ИмяName	ТипType	TTL (Срок жизни)TTL	Единица срока жизниTTL unit	Preference (Предпочтение)Preference	Обмен сообщениямиMail Exchange
   @	MXMX	1,11	ЧасыHours	10 10 Дополнительные сведения о приоритете см. в статье Приоритет записей MX.For more information about priority, see What is MX priority?	<ключ_домена> .mail.protection.outlook.com<domain-key> .mail.protection.outlook.com Примечание: Получите * <ключ> домена* из учетной записи Office 365.Note: Get your <domain-key> from your Office 365 account. Как его найти?How do I find this?

5. Нажмите кнопку ОК.Select OK.

6. Если в разделе MX Records (записи MX ) указаны другие записи MX, их необходимо удалить.If there are any other MX records listed in the MX Records section, you must delete them.

   Сначала в области зона DNS выберите набор записей MX.First, in the DNS zone area, select the MX Record set.

   Затем выберите запись MX, которую нужно удалить.Next, select the MX record you want to delete.

7. Выберите контекстное меню (…), а затем нажмите кнопку Удалить.Select the Context menu (…), and then choose Remove.

8. Нажмите кнопку Сохранить.Select Save.

Добавьте четыре записи CNAME, необходимые для Office 365.Add the four CNAME records that are required for Office 365

1. Чтобы приступить к работе, перейдите на страницу ваших доменов в Azure, используя эту ссылку.To get started, go to your domains page at Azure by using this link. Сначала вам потребуется выполнить вход.You’ll be prompted to log in first.

2. На странице «панель мониторинга» в области » все ресурсы » выберите домен, который необходимо обновить.On the Dashboard page, in the All resources area, select the domain that you want to update.

3. На странице Параметры домена в области зона DNS выберите пункт + набор записей.On the Settings page for your domain, in the DNS zone area, select + Record set.

4. Добавьте первую из четырех записей CNAME.Add the first of the four CNAME records.

   В поля для нового набора записей в области Добавление набора записей введите (или скопируйте и вставьте) значения из первой строки в приведенной ниже таблице.In the Add record set area, in the boxes for the new record set, type or copy and paste the values from the first row in the following table.

   В раскрывающихся списках выберите значения Type (тип ) и TTL (TTL ).(Choose the Type and TTL unit values from the drop-down lists.)

   ИмяName	ТипType	TTL (Срок жизни)TTL	Единица срока жизниTTL unit	Alias (Псевдоним)Alias
   autodiscoverautodiscover	CNAMECNAME	1,11	ЧасыHours	autodiscover.outlook.comautodiscover.outlook.com
   sipsip	CNAMECNAME	1,11	ЧасыHours	sipdir.online.lync.comsipdir.online.lync.com
   lyncdiscoverlyncdiscover	CNAMECNAME	1,11	ЧасыHours	webdir.online.lync.comwebdir.online.lync.com

5. Нажмите кнопку ОК.Select OK.

6. Добавьте остальные три записи CNAME.Add each of the other three CNAME records.

   В области зона DNS выберите + набор записей.In the DNS zone area, select + Record set. Затем в пустом наборе записей создайте запись, используя значения из следующей строки таблицы, и снова нажмите кнопку ОК , чтобы завершить эту запись.Then, in the empty record set, create a record by using the values from the next row in the table, and again select OK to complete that record.

   Повторяйте эту процедуру, пока не будут созданы все четыре записи CNAME.Repeat this process until you have created all four CNAME records.

7. Необязательно Добавьте 2 записи CNAME для MDM.(Optional) Add 2 CNAME records for MDM.

Важно!

Если вы пользуетесь решениями для управления мобильными устройствами (MDM) для Office 365, необходимо создать две дополнительные записи CNAME.If you have Mobile Device Management (MDM) for Office 365, then you must create two additional CNAME records. Повторите действия, которые вы совершали при добавлении предыдущих четырех записей CNAME, подставив значения из таблицы ниже.Follow the procedure that you used for the other four CNAME records, but supply the values from the following table. (Если MDM нет, вы можете пропустить этот шаг.)(If you do not have MDM, you can skip this step.)

ИмяName	ТипType	TTL (Срок жизни)TTL	Единица срока жизниTTL unit	Alias (Псевдоним)Alias
enterpriseregistrationenterpriseregistration	CNAMECNAME	1,11	ЧасыHours	enterpriseregistration.windows.netenterpriseregistration.windows.net
enterpriseenrollmententerpriseenrollment	CNAMECNAME	1,11	ЧасыHours	enterpriseenrollment-s.manage.microsoft.comenterpriseenrollment-s.manage.microsoft.com

Добавление записи TXT для SPF, предотвращающей рассылку спамаAdd a TXT record for SPF to help prevent email spam

Важно!

Для записи инфраструктуры политики отправителей (SPF) для домена можно указать только одну запись TXT.You cannot have more than one TXT record for SPF for a domain. Если у вашего домена больше одной записи SPF, это приведет к сбоям в работе почты и ошибкам классификации входящих писем и спама.If your domain has more than one SPF record, you’ll get email errors, as well as delivery and spam classification issues. If you already have an SPF record for your domain, don’t create a new one for Office 365.If you already have an SPF record for your domain, don’t create a new one for Office 365. Вместо этого добавьте необходимые значения Office 365 в текущую запись. Таким образом, в одной записи SPF будут указаны оба набора значений.Instead, add the required Office 365 values to the current record so that you have a single SPF record that includes both sets of values.

1. Чтобы приступить к работе, перейдите на страницу ваших доменов в Azure, используя эту ссылку.To get started, go to your domains page at Azure by using this link. Сначала вам потребуется выполнить вход.You’ll be prompted to log in first.

2. На странице «панель мониторинга» в области » все ресурсы » выберите домен, который необходимо обновить.On the Dashboard page, in the All resources area, select the domain that you want to update.

3. В области зона DNS выберите набор записей TXT.In the DNS zone area, select the TXT record set.

4. В полях для нового набора записей в области Свойства набора записей выберите значения из таблицы ниже.In the Record set properties area, in the boxes for the new record set, select the values from the following table.

   В раскрывающихся списках выберите значения Type (тип ) и TTL (TTL ).(Choose the Type and TTL unit values from the drop-down lists.)

   ИмяName	ТипType	TTL (Срок жизни)TTL	Единица срока жизниTTL unit	ЗначениеValue
   @	TXTTXT	1,11	ЧасыHours	v=spf1 include:spf.protection.outlook.com -allv=spf1 include:spf.protection.outlook.com -all Примечание. Рекомендуется скопировать и вставить эту запись, чтобы сохранить все пробелы. Note: We recommend copying and pasting this entry, so that all of the spacing stays correct.

5. Нажмите кнопку Сохранить.Select Save.

Добавление двух записей SRV, необходимых для Office 365Add the two SRV records that are required for Office 365

1. Чтобы приступить к работе, перейдите на страницу ваших доменов в Azure, используя эту ссылку.To get started, go to your domains page at Azure by using this link. Сначала вам потребуется выполнить вход.You’ll be prompted to log in first.

2. На странице «панель мониторинга» в области » все ресурсы » выберите домен, который необходимо обновить.On the Dashboard page, in the All resources area, select the domain that you want to update.

3. На странице Параметры домена в области зона DNS выберите пункт + набор записей.On the Settings page for your domain, in the DNS zone area, select + Record set.

4. Добавьте первую из двух записей SRV.Add the first of the two SRV records.

   В поля для нового набора записей в области Добавление набора записей выберите значения из первой строки в следующей таблице.In the Add record set area, in the boxes for the new record set, select the values from the first row in the following table.

   В раскрывающихся списках выберите значения Type (тип ) и TTL (TTL ).(Choose the Type and TTL unit values from the drop-down lists.)

   ИмяName	ТипType	TTL (Срок жизни)TTL	Единица срока жизниTTL unit	Priority (Приоритет)Priority	Weight (Вес)Weight	Port (Порт)Port	Target (Назначение)Target
   _sip. _tls_sip._tls	SRVSRV	1,11	ЧасыHours	100100	1,11	443443	sipdir.online.lync.comsipdir.online.lync.com
   _sipfederationtls. _tcp_sipfederationtls._tcp	SRVSRV	1,11	ЧасыHours	100100	1,11	50615061	sipfed.online.lync.comsipfed.online.lync.com

5. Нажмите кнопку ОК.Select OK.

6. Добавьте вторую запись SRV.Add the other SRV record.

   В поля для новой записи введите (или скопируйте и вставьте) значения из второй строки таблицы.In the boxes for the new record, type or copy and paste the values from the second row of the table.

Примечание

Обычно на вступление изменений DNS в силу требуется около 15 минут. Однако иногда распространение внесенного изменения в системе DNS по всему Интернету занимает больше времени. Если после добавления записей DNS возникла проблема с потоком обработки почты или другие неполадки, см. статью Устранение неполадок после смены имени домена или записей DNS.Typically it takes about 15 minutes for DNS changes to take effect. However, it can occasionally take longer for a change you’ve made to update across the Internet’s DNS system. If you’re having trouble with mail flow or other issues after adding DNS records, see Troubleshoot issues after changing your domain name or DNS records.

Развертывание разделенной системы DNS с помощью политики DNS

• 15.01.2020
• Время чтения: 7 мин

В этой статье

Область применения: Windows Server 2016Applies to: Windows Server 2016

С помощью этого раздела вы узнаете, как настроить политику DNS в Windows Server® 2016 для раздельных развертываний DNS, где есть две версии одной зоны — одна для внутренних пользователей в интрасети организации, а другая — для внешних пользователей, которые обычно являются пользователями в Интернете.You can use this topic to learn how to configure DNS policy in Windows Server® 2016 for split-brain DNS deployments, where there are two versions of a single zone — one for the internal users on your organization intranet, and one for the external users, who are typically users on the Internet.

Ранее этот сценарий требовал, чтобы администраторы DNS поддерживали два разных DNS-сервера, каждый из которых предоставляет службы каждому набору пользователей, внутренним и внешним.Previously, this scenario required that DNS administrators maintain two different DNS servers, each providing services to each set of users, internal and external. Если только несколько записей в зоне были разбиты-были обделены или оба экземпляра зоны (внутренние и внешние) были делегированы в один и тот же родительский домен, это стало загадкаом управления.If only a few records inside the zone were split-brained or both instances of the zone (internal and external) were delegated to the same parent domain, this became a management conundrum.

Еще один сценарий настройки для развертывания с разделением-мозгом — выборочный контроль рекурсии для разрешения DNS-имен.Another configuration scenario for split-brain deployment is Selective Recursion Control for DNS name resolution. В некоторых обстоятельствах DNS-серверы предприятия должны выполнять рекурсивное разрешение для внутренних пользователей, а также как полномочные серверы имен для внешних пользователей и блокировать рекурсию для них.In some circumstances, the Enterprise DNS servers are expected to perform recursive resolution over the Internet for the internal users, while they also must act as authoritative name servers for external users, and block recursion for them.

Данный раздел содержит следующие подразделы.This topic contains the following sections.

Пример развертывания DNS с разделением-мозгомExample of DNS Split-Brain Deployment

Ниже приведен пример того, как можно использовать политику DNS для выполнения описанного выше сценария «разделение-DNS».Following is an example of how you can use DNS policy to accomplish the previously described scenario of split-brain DNS.

Этот раздел содержит следующие подразделы.This section contains the following topics.

В этом примере используется одна вымышленная компания Contoso, которая поддерживает веб-узел карьеры по адресу www.career.contoso.com.This example uses one fictional company, Contoso, which maintains a career Web site at www.career.contoso.com.

Сайт имеет две версии — один для внутренних пользователей, где доступны внутренние сообщения о заданиях.The site has two versions, one for the internal users where internal job postings are available. Этот внутренний сайт доступен по локальному IP-адресу 10.0.0.39.This internal site is available at the local IP address 10.0.0.39.

Вторая версия — это общедоступная версия того же сайта, которая доступна по общедоступному IP-адресу 65.55.39.10.The second version is the public version of the same site, which is available at the public IP address 65.55.39.10.

В отсутствие политики DNS администратору необходимо размещать эти две зоны на отдельных DNS-серверах Windows Server и управлять ими отдельно.In the absence of DNS policy, the administrator is required to host these two zones on separate Windows Server DNS servers and manage them separately.

С помощью политик DNS эти зоны теперь можно размещать на одном DNS-сервере.Using DNS policies these zones can now be hosted on the same DNS server.

Этот сценарий показан на следующем рисунке.The following illustration depicts this scenario.

Как работает развертывание с разделением DNSHow DNS Split-Brain Deployment Works

Если DNS-сервер настроен с использованием требуемых политик DNS, каждый запрос разрешения имен оценивается по политикам на DNS-сервере.When the DNS server is configured with the required DNS policies, each name resolution request is evaluated against the policies on the DNS server.

В этом примере интерфейс сервера используется в качестве критерия для различения внутренних и внешних клиентов.The server Interface is used in this example as the criteria to differentiate between the internal and external clients.

Если серверный интерфейс, на котором получен запрос, соответствует любой из политик, то соответствующая область зоны используется для ответа на запрос.If the server interface upon which the query is received matches any of the policies, the associated zone scope is used to respond to the query.

Таким образом, в нашем примере запросы DNS для www.career.contoso.com, полученные на частном IP-адресе (10.0.0.56), получают ответ DNS, который содержит внутренние IP-адреса. и запросы DNS, получаемые в общедоступном сетевом интерфейсе, получают ответ DNS, содержащий общедоступный IP-адрес в области зоны по умолчанию (это то же самое, что и обычная разрешающая способность запросов).So, in our example, the DNS queries for www.career.contoso.com that are received on the private IP (10.0.0.56) receive a DNS response that contains an internal IP address; and the DNS queries that are received on the public network interface receive a DNS response that contains the public IP address in the default zone scope (this is the same as normal query resolution).

Настройка развернутого сервера с разделением DNSHow to Configure DNS Split-Brain Deployment

Чтобы настроить развертывание с разделением DNS с помощью политики DNS, необходимо выполнить следующие действия.To configure DNS Split-Brain Deployment by using DNS Policy, you must use the following steps.

В следующих разделах приведены подробные инструкции по настройке.The following sections provide detailed configuration instructions.

Важно!

В следующих разделах приведены примеры команд Windows PowerShell, которые содержат примеры значений для многих параметров.The following sections include example Windows PowerShell commands that contain example values for many parameters. Перед выполнением этих команд обязательно замените примеры значений в этих командах значениями, подходящими для вашего развертывания.Ensure that you replace example values in these commands with values that are appropriate for your deployment before you run these commands.

Создание областей зоныCreate the Zone Scopes

Область зоны — это уникальный экземпляр зоны.A zone scope is a unique instance of the zone. Зона DNS может иметь несколько областей зоны, при этом каждая область зоны содержит собственный набор записей DNS.A DNS zone can have multiple zone scopes, with each zone scope containing its own set of DNS records. Одна и та же запись может присутствовать в нескольких областях с разными IP-адресами или IP-адресами.The same record can be present in multiple scopes, with different IP addresses or the same IP addresses.

Примечание

По умолчанию область зоны существует в зонах DNS.By default, a zone scope exists on the DNS zones. Эта область зоны имеет то же имя, что и зона, а устаревшие операции DNS работают в этой области.This zone scope has the same name as the zone, and legacy DNS operations work on this scope. В этой области зоны по умолчанию будет размещена внешняя версия www.career.contoso.com.This default zone scope will host the external version of www.career.contoso.com.

Можно использовать следующий пример команды, чтобы секционировать область зоны contoso.com для создания внутренней области зоны.You can use the following example command to partition the zone scope contoso.com to create an internal zone scope. Внутренняя область зоны будет использоваться для сохранения внутренней версии www.career.contoso.com.The internal zone scope will be used to keep the internal version of www.career.contoso.com.

Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "internal"

Дополнительные сведения см. в разделе Add-днссерверзонескопе .For more information, see Add-DnsServerZoneScope

Добавление записей в области зоныAdd Records to the Zone Scopes

Следующим шагом является добавление записей, представляющих узел веб-сервера, в две области зоны — внутренние и по умолчанию (для внешних клиентов).The next step is to add the records representing the Web server host into the two zone scopes — internal and default (for external clients).

В области внутренней зоны www.Career.contoso.com запись добавляется с IP-адресом 10.0.0.39, который является частным адресом. и в области зоны по умолчанию с IP-адресом 65.55.39.10 добавляется та же запись www.Career.contoso.com.In the internal zone scope, the record www.career.contoso.com is added with the IP address 10.0.0.39, which is a private IP; and in the default zone scope the same record, www.career.contoso.com, is added with the IP address 65.55.39.10.

При добавлении записи в область зоны по умолчанию в следующих примерах команд отсутствует параметр – зонескопе .No –ZoneScope parameter is provided in the following example commands when the record is being added to the default zone scope. Это похоже на добавление записей в зону обычный.This is similar to adding records to a vanilla zone.

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39” -ZoneScope "internal"

Дополнительные сведения см. в разделе Add-днссерверресаурцерекорд.For more information, see Add-DnsServerResourceRecord.

Создание политик DNSCreate the DNS Policies

После определения интерфейсов сервера для внешней сети и внутренней сети, а также для создания областей зоны необходимо создать политики DNS, которые соединяют внутренние и внешние области зоны.After you have identified the server interfaces for the external network and internal network and you have created the zone scopes, you must create DNS policies that connect the internal and external zone scopes.

Примечание

В этом примере серверный интерфейс используется в качестве критерия для различения внутренних и внешних клиентов.This example uses the server interface as the criteria to differentiate between the internal and external clients. Другим способом различения внешних и внутренних клиентов является использование подсетей клиента в качестве критерия.Another method to differentiate between external and internal clients is by using client subnets as a criteria. Если вы можете определить подсети, к которым принадлежат внутренние клиенты, можно настроить политику DNS, чтобы отличать их от подсети клиента.If you can identify the subnets to which the internal clients belong, you can configure DNS policy to differentiate based on client subnet. Сведения о настройке управления трафиком с помощью критериев подсети клиента см. в статье Использование политики DNS для управления трафиком на основе географического расположения с основными серверами.For information on how to configure traffic management using client subnet criteria, see Use DNS Policy for Geo-Location Based Traffic Management with Primary Servers.

Когда DNS-сервер получает запрос к частному интерфейсу, ответ на запрос DNS возвращается из внутренней области зоны.When the DNS server receives a query on the private interface, the DNS query response is returned from the internal zone scope.

Примечание

Для сопоставления области зоны по умолчанию не требуются никакие политики.No policies are required for mapping the default zone scope.

В следующем примере команда 10.0.0.56 является IP-адресом частного сетевого интерфейса, как показано на предыдущем рисунке.In the following example command, 10.0.0.56 is the IP address on the private network interface, as shown in the previous illustration.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName contoso.com

Дополнительные сведения см. в разделе Add-днссерверкуериресолутионполици.For more information, see Add-DnsServerQueryResolutionPolicy.

Пример управления выборочной рекурсией DNSExample of DNS Selective Recursion Control

Ниже приведен пример того, как можно использовать политику DNS для выполнения описанного выше сценария управления селективной рекурсией DNS.Following is an example of how you can use DNS policy to accomplish the previously described scenario of DNS selective recursion control.

Этот раздел содержит следующие подразделы.This section contains the following topics.

В этом примере используется та же вымышленная компания, что и в предыдущем примере, Contoso, который поддерживает веб-узел карьеры по адресу www.career.contoso.com.This example uses the same fictional company as in the previous example, Contoso, which maintains a career Web site at www.career.contoso.com.

В примере развертывания DNS Split-мозгового сервера тот же DNS-сервер отвечает как внешним, так и внутренним клиентам и предоставляет им разные ответы.In the DNS split-brain deployment example, the same DNS server responds to both the external and internal clients and provides them with different answers.

Некоторые развертывания DNS могут потребовать, чтобы один и тот же DNS-сервер выполнял рекурсивное разрешение имен для внутренних клиентов, помимо того, чтобы выступать в роли полномочного сервера имен для внешних клиентов.Some DNS deployments might require the same DNS server to perform recursive name resolution for internal clients in addition to acting as the authoritative name server for external clients. Это называется контролем выборочной рекурсии DNS.This circumstance is called DNS selective recursion control.

В предыдущих версиях Windows Server Включение рекурсии означало, что оно было включено на всем DNS-сервере для всех зон.In previous versions of Windows Server, enabling recursion meant that it was enabled on the whole DNS server for all zones. Так как DNS-сервер также прослушивает внешние запросы, рекурсия включается как для внутренних, так и для внешних клиентов, что делает DNS-сервер открытым сопоставительом.Because the DNS server is also listening to external queries, recursion is enabled for both internal and external clients, making the DNS server an open resolver.

DNS-сервер, настроенный как открытый сопоставитель, может быть уязвим для исчерпания ресурсов и может быть заражен вредоносными клиентами для создания атак с отражением.A DNS server that is configured as an open resolver might be vulnerable to resource exhaustion and can be abused by malicious clients to create reflection attacks.

По этой причине Администраторы DNS Contoso не хотят, чтобы DNS-сервер для contoso.com выполнял рекурсивное разрешение имен для внешних клиентов.Because of this, Contoso DNS administrators do not want the DNS server for contoso.com to perform recursive name resolution for external clients. Для внутренних клиентов требуется только управление рекурсией, в то время как управление рекурсией может быть заблокировано для внешних клиентов.There is only a need for recursion control for internal clients, while recursion control can be blocked for external clients.

Этот сценарий показан на следующем рисунке.The following illustration depicts this scenario.

Как работает управление селективной рекурсией DNSHow DNS Selective Recursion Control Works

Если получен запрос, для которого DNS-сервер Contoso является неполномочным, например для https://www.microsoft.com, запрос разрешения имени оценивается по политикам на DNS-сервере.If a query for which the Contoso DNS server is non-authoritative is received, such as for https://www.microsoft.com, then the name resolution request is evaluated against the policies on the DNS server.

Поскольку эти запросы не попадают ни в одну зону, политики уровня зоны (, как определено в примере Split-мозг) не оцениваются.Because these queries do not fall under any zone, the zone level policies (as defined in the split-brain example) are not evaluated.

DNS-сервер оценивает политики рекурсии, а запросы, получаемые в частном интерфейсе, соответствуют сплитбраинрекурсионполици.The DNS server evaluates the recursion policies, and the queries that are received on the private interface match the SplitBrainRecursionPolicy. Эта политика указывает на область рекурсии, в которой включена рекурсия.This policy points to a recursion scope where recursion is enabled.

Затем DNS-сервер выполняет рекурсию для получения ответа на https://www.microsoft.com из Интернета и кэширует ответ локально.The DNS server then performs recursion to get the answer for https://www.microsoft.com from the Internet, and caches the response locally.

Если запрос получен на внешнем интерфейсе, политики DNS не совпадают, и параметр рекурсии по умолчанию, который в данном случае отключен , применяется.If the query is received on the external interface, no DNS policies match, and the default recursion setting — which in this case is Disabled — is applied.

Это не позволяет серверу выступать в качестве открытого сопоставителя для внешних клиентов, пока он выступает в качестве сопоставителя кэширования для внутренних клиентов.This prevents the server from acting as an open resolver for external clients, while it is acting as a caching resolver for internal clients.

Настройка управления выборочной рекурсией DNSHow to Configure DNS Selective Recursion Control

Чтобы настроить управление выборочной рекурсией DNS с помощью политики DNS, необходимо выполнить следующие действия.To configure DNS selective recursion control by using DNS Policy, you must use the following steps.

Создание областей рекурсии DNSCreate DNS Recursion Scopes

Области рекурсии являются уникальными экземплярами группы параметров, которые управляют рекурсией на DNS-сервере.Recursion scopes are unique instances of a group of settings that control recursion on a DNS server. Область рекурсии содержит список серверов пересылки и указывает, включена ли рекурсия.A recursion scope contains a list of forwarders and specifies whether recursion is enabled. DNS-сервер может иметь много областей рекурсии.A DNS server can have many recursion scopes.

Устаревший параметр рекурсии и список серверов пересылки называются областью рекурсии по умолчанию.The legacy recursion setting and list of forwarders are referred to as the default recursion scope. Невозможно добавить или удалить область рекурсии по умолчанию, которая определяется по имени dot («.»).You cannot add or remove the default recursion scope, identified by the name dot (“.”).

В этом примере параметр рекурсии по умолчанию отключен, а также создается новая область рекурсии для внутренних клиентов, где включена рекурсия.In this example, the default recursion setting is disabled, while a new recursion scope for internal clients is created where recursion is enabled.

Set-DnsServerRecursionScope -Name . -EnableRecursion $False
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True 

Дополнительные сведения см. в разделе Add-днссерверрекурсионскопе .For more information, see Add-DnsServerRecursionScope

Создание политик рекурсии DNSCreate DNS Recursion Policies

Можно создать политики рекурсии DNS-сервера, чтобы выбрать область рекурсии для набора запросов, соответствующих указанным условиям.You can create DNS server recursion policies to choose a recursion scope for a set of queries that match specific criteria.

Если DNS-сервер не является полномочным для некоторых запросов, политики рекурсии DNS-сервера позволяют управлять способом разрешения запросов.If the DNS server is not authoritative for some queries, DNS server recursion policies allow you to control how to resolve the queries.

В этом примере внутренняя область рекурсии с включенной рекурсией связана с частным сетевым интерфейсом.In this example, the internal recursion scope with recursion enabled is associated with the private network interface.

Для настройки политик рекурсии DNS можно использовать приведенный ниже пример команды.You can use the following example command to configure DNS recursion policies.

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39"

Дополнительные сведения см. в разделе Add-днссерверкуериресолутионполици.For more information, see Add-DnsServerQueryResolutionPolicy.

Теперь DNS-сервер настроен с использованием требуемых политик DNS для сервера доменных имен с разделением или DNS-сервера, для которого включено выборочное управление рекурсией для внутренних клиентов.Now the DNS server is configured with the required DNS policies for either a split-brain name server or a DNS server with selective recursion control enabled for internal clients.

Вы можете создавать тысячи политик DNS в соответствии с требованиями к управлению трафиком, а все новые политики применяются динамически, без перезапуска DNS-сервера во входящих запросах.You can create thousands of DNS policies according to your traffic management requirements, and all new policies are applied dynamically — without restarting the DNS server — on incoming queries.

Дополнительные сведения см. в разделе руководств по сценариям политики DNS.For more information, see DNS Policy Scenario Guide.

Делегирование обратной зоны подсети менее /24 в BIND. Как это работает / Habr

Встала однажды передо мной задача, отдать одному из клиентов право на редактирование PTR-записей отданной ему подсети /28. Автоматизации для редактирования настроек BIND извне у меня нет. Поэтому я решил пойти другим путем — делегировать клиенту кусок PTR-зоны подсети /24.

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

Кто захочет сам разобраться, тот может почитать RFC
Кто хочет готового решения, добро пожаловать под кат.

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

1. Практика. Делегируем зону /28

Допустим у нас есть подсеть 7.8.9.0/24. Нам надо делегировать подсеть 7.8.9.240/28 на днс-клиента 7.8.7.8 (ns1.client.domain).

На провайдерском днс надо найти файл, описывающий обратную зону этой подсети. Пусть будет 9.8.7.in-addr.arpa.
Записи от 240 до 255 комментируем, если есть. И в конец файла пишем следующее:

255-240  IN  NS      7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240

не забываем увеличить serial зоны и делаем

rndc reload

На этом провайдерская часть закончена. Переходим к клиентскому днс.

Для начала создадим файл /etc/bind/master/255-240.9.8.7.in-addr.arpa следующего содержания:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

И в named.conf дописываем описание нашего нового файла:

zone "255-240.9.8.7.in-addr.arpa." IN {
        type master;
        file "master/255-240.9.8.7.in-addr.arpa";
};

B перезапускаем процесс bind.

/etc/init.d/named restart

Все. Теперь можно проверять.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

Обратите внимание, что отдается не только PTR-запись и но и CNAME. Так и должно быть. Если интересно почему, то добро пожаловать в следующую главу.

2. Теория. Как это работает.

Сложно настраивать и отлаживать черный ящик. Гораздо проще, если понимаешь что происходит внутри.

Когда мы делегируем поддомен в домене domain, то пишем что-то вроде этого:

client.domain.	NS	ns1.client.domain.
ns1.client.domain.	A	7.8.7.8

Мы говорим всем спрашивающим, что за этот участок не отвечаем и говорим кто отвечает. И все запросы на client.domain редиректятся на 7.8.7.8. При проверке мы видим следующую картину (опустим что там у клиента. это неважно):

# host test.client.domain
test.client.domain has address 7.8.9.241

Т.е. нам сообщили, что есть такая А запись и ее ip 7.8.9.241. Никакой лишней информации.

А как то же самое можно сделать с подсетью?

Т.к. наш DNS-сервер прописан в RIPE, то при запросе PTR ip-адреса из нашей сети, все равно первый запрос будет к нам. Логика та же что и с доменами. Вот только как вписать подсеть в файл зоны?

Пробуем вписать вот так:

255-240  IN  NS      7.8.7.8

И… чуда не произошло. Мы не получаем никакого перенаправления запроса. Все дело в том, что bind вообще не в курсе что вот эти записи в файле обратной зоны это ip-адреса и уж тем более не понимает запись диапазона. Для него это просто некий символьный поддомен. Т.е. для bind не будет разницы между «255-240» и «oursuperclient«. И запрос чтобы запрос ушел куда надо, адрес в запросе должен выглядеть вот так: 241.255-240.9.8.7.in-addr.arpa. Или вот так, если мы используем символьный поддомен: 241.oursuperclient.9.8.7.in-addr.arpa. Это отличается от обычного: 241.9.8.7.in-addr.arpa.

Руками такой запрос будет сделать проблематично. А если и получится, то все равно непонятно как это применить в реальной жизни. Ведь по запросу 7.8.9.241 нам по прежнему отвечает провайдерский DNS, а не клиентский.

А вот тут в игру вступают CNAME.

На стороне провайдера нужно сделать для всех ip-адресов подсети алиас в формат, который переправит запрос клиентскому DNS.

255-240  IN  NS      ns1.client.domain.
241     IN  CNAME   241.255-240
242     IN  CNAME   242.255-240
и т.д.

Это для трудолюбивых =).

А для ленивых больше подойдет конструкция ниже:

255-240  IN  NS      ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240

Теперь запрос информации по адресу 7.8.9.241 из 241.9.8.7.in-addr.arpa на днс-сервере провайдера будет преобразован в 241.255-240.9.8.7.in-addr.arpa и уйдет на днс-клиента.

Со стороны клиента нужно будет обрабатывать такие запросы. Соответственно мы создаем зону 255-240.9.8.7.in-addr.arpa. В ней мы в принципе можем размещать обратные записи для любых ip всей подсети /24, но спрашивать у нас будут только про те, которые провайдер к нам переадресует, так что побаловаться не получится =).
Для иллюстрации еще раз приведу пример содержания файла обратной зоны со стороны клиента:

$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@                       1D IN SOA       ns1.client.domain. root.client.domain. (
                        2008152607      ; serial
                        3H              ; refresh
                        15M             ; retry
                        1W              ; expiry
                        1D )            ; minimum
@                       IN NS        ns1.client.domain.
@                       IN NS        ns2.client.domain.
241                     IN PTR          test.client.domain.
242                     IN PTR          test2.client.domain.
245                     IN PTR          test5.client.domain.

Вот из-за того, что мы со стороны провайдера используем CNAME, то и получаем в ответ на запрос данных по ip-адресу две записи, а не одну.

#>  host 7.8.9.245 
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.

И не забывайте корректно настраивать ACL. Потому что бессмысленно забирать себе PTR-зону и не отвечать никому из внешки =).

Делаем свой локальный DNS (PDNSD), с блэкджеком и быстрее Google Public DNS / Habr

С каждым годом скорость интернета — как последней мили, так и магистральных каналов становится все выше. Лишь одно неизменно — латентность уже уперлась в физические ограничения: скорость света в оптоволокне — около 200тыс километров в секунду, и соответственно, быстрее чем за ~150ms ответ от сервера через атлантический океан не получить в обозримой перспективе (хотя конечно есть изыски, вроде оптоволокна с воздушной сердцевиной или радиорелейной связи, но это для простых смертных едва-ли доступно).

Когда мы пытаемся например из России открыть web-сайт, расположенный в США (его NS сервера вероятно там же), и домен не нашелся в DNS-кэше вашего провайдера — то ждать придется долго даже на гигабитном интернете, возможно даже целую секунду: пока мы через океан получим имена NS серверов домена, пока разрезолвим их IP, пока отправим и получим собственно сам DNS запрос…

Пару лет назад Google завела свои публичные DNS сервера, а для агитации перехода на них — они разработали утилитку NameBench, которая прогоняет тесты DNS по вашей истории серфинга и показывает, насколько Google DNS быстрее DNS сервера вашего провайдера.

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

pdnsd — кэширующий DNS proxy. Помимо банального кэширования DNS запросов (с возможностью жестко задавать минимальный TTL — может быть нужно на очень плохом интернете), он умеет отсылать запрос одновременно на несколько «родительских» DNS серверов, и отдавать клиенту первый вернувшийся ответ.

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

Ставится в Ubuntu — банальным apt-get.

Пара моментов в конфиге

global {
	perm_cache=10240; //Максимальный размер кэша в килобайтах. 
                      //По дефолту было 1024, все записи у меня не влазили.
	cache_dir="/var/cache/pdnsd";
[...]
	min_ttl=60m;    // Минимальное время сохранения записи в кэше.
                   //Даже если TTL придет меньше 60минут - будет 60минут
	max_ttl=1w;	   // Максимальное время сохранения записи в кэше
	neg_ttl=5m; //Время кеширования отрицательных ответов (т.е. если домен не найден)
[..]
	par_queries=3; //Количество одновременно опрашиваемых "родительских" DNS серверов
}

server {
	label = "main";
	ip = 	85.21.192.5 //Тут 4 сервера, если первые 3 не ответят, то будет отправлен запрос на 4-й
	,       213.234.192.7 //Первые 2 сервера - это сервер вашего провайдера, и какого-нибудь соседнего
	,	8.8.4.4 //Это Google Public DNS - у них закэшировано все редкое и резолвят они быстро
	,	8.8.8.8
	;
[..]
}

В принципе, кэширование можно сделать менее агрессивным (min_ttl=1m например), но за год работы проблем особых не возникло. В случае проблем — при желании можно вытереть одну запись из кэша:

sudo pdnsd-ctl record 3.14.by delete

или сразу все:

sudo pdnsd-ctl empty-cache

Результаты тестирования в NameBench

Видим, что для 50% запросов ответ мы получаем менее чем за 10мс, для 85% быстрее Google Public DNS, ну а дальше результаты естественно совпадают с гуглом.

По результатам тестов NameBench нам радостно сообщает:

8.8.8.8 	Slower replica of SYS-192.167.0.98 [192.167.0.98]
8.8.4.4 	Slower replica of SYS-192.167.0.98 [192.167.0.98]

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