Зона dns что это: Основные сведения о DNS. Зоны и серверы DNS.

Содержание

Основные сведения о DNS. Зоны и серверы DNS.

Продолжение. Начало — «Основные сведения о DNS. Введение.«

Сервис системы доменных имен строится по стандартной для информационных технологий схеме «клиент-сервер». В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени). Это программное обеспечение и называют resolver.

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

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

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

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

При заказе своего доменного имени mysite.ru можно делегировать управление им серверам регистратора (благо, что практически все регистраторы предоставляют такую услугу бесплатно), можно поднять свой собственный DNS сервер и делегировать управление доменным именем ему (только поднимать нужно не один, а 2 сервера и на разных физических серверах, о чем говорят регулирующие документы Интернет) или использовать сторонние DNS сервера (например yandex или mail.

ru, которые предоставляют свои DNS сервера бесплатно).

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

Корневые серверы DNS — DNS-серверы, содержащие информацию о доменах верхнего уровня (TLD), указывающую на DNS-серверы, поддерживающие работу каждого из этих доменов.

Основные корневые серверы DNS размещены в домене root-servers.org и обозначаются латинскими буквами от A до М, IP-адреса которых широко известны. Они управляются различными организациями, действующими по согласованию с ICANN.

Из-за существовавших в прошлом ограничений на размеры DNS-пакета (512 байт) в DNS-ответ могло быть помещено всего 13 серверов (от A до M — тринадцатой буквы в алфавите), сейчас за этими 13 именами стоят более 200 серверов.

 В частности, российское зеркало сервера F расположено в РосНИИРОС в Москве, сервера K — в Новосибирске, а сервера L — в Ростове-на-Дону.

Ближайший (к пользователю) адрес «зеркала» корневого сервера выбирается автоматически благодаря IP AnyCast. Так, при обращении к K.root-servers.net пользователь из Новосибирска скорее всего обратится к новосибирскому серверу (в NSK-IX).

В качестве серверов доменных имен чаще всего используются различные версии BIND (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.

В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени). Это программное обеспечение и называют resolver.

Иногда, resolver не является отдельным сервисом или системной компонентой. Это набор процедур из библиотеки прикладного программного обеспечения (например, из библиотеки libc), которые позволяют программе, отредактированной с ними, выполнять запросы к системе доменных имен и получать ответы на них.

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

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

Самостоятельный resolver может быть собран и в BIND версии 9. Это так называемый lightweight resolver. Он состоит из resolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО. Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.

 

что это такое, какие функции выполняет

DNS (Domain Name System) – это система доменных имен, предназначенная для связывания доменов (названий сайтов) с IP-адресами компьютеров, обслуживающих их. То есть, данная система предназначена для облегчения поиска веб-сайтов.

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

Для чего нужен DNS?

Роль почтового адреса в интернете играет IP-адрес(по рус. Айпи). Он есть у всех устройств в сети, будь то домашняя сеть или Интернет. С его помощью устройства могут общаться между собой, отправляя запросы и отвечая на них по определенным IP-адресам. Они задают, на какое устройство необходимо отправить данные.

Айпи состоит из четырех чисел, начиная от 0 и заканчивая 255. К примеру, один из интернет-адресов сайта компании Google выглядит так: 77.214.53.237. Если вы скопируете данное сочетание цифр и вставите в адресную строку в браузере, то автоматически попадете на страницу google.com. Позже мы расскажем, почему домены могут иметь несколько IP.

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

В отличие от компьютеров, человеку тяжело держать в голове уйму цифр. IP-адрес очень похож на длинный мобильный номер. Чтобы не было необходимости запоминать номера телефонов, мы записываем их в «контакты» и называем, зачастую, именами владельцев этих номеров. Например: Иван Сидорович, +7-123-456-78-90. В следующий раз, когда мы захотим позвонить Ивану, нам достаточно ввести его имя, а про номер можно и вовсе забыть.

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

Например, чтобы зайти на сайт Ивана с доменным адресом yavanya.com, который он выбрал сам, достаточно ввести его в браузере, после чего DNS отправит компьютеру (через который вы сидите в браузере) необходимый IP-адрес. Допустим, 012.012.012.012 – это айпи, соответствующее сайту yavanya.com. Тогда сервер (компьютер), на котором размещен сайт, с таким адресом проанализирует введенный пользователем запрос и пришлет данные браузеру для отображения запрошенной страницы.

Где находятся записи соответствия доменов IP-адресам?


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

  • хранение списка айпи и соответствующих им доменов;
  • кэширование записей из других серверов системы.

Здесь стоит пояснить суть второй функции – кэширования. При каждом запросе пользователя, серверам приходится находить IP-адрес в соответствии с указанным названием ресурса.

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

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

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

Что такое DNS-зона?

Выше мы привели самый простой пример соответствия IP-адреса домену, которое происходит по такой схеме: одно доменное имя – один ресурс – один адрес.

Тем не менее, к единственному домену, кроме сайта, одновременно может относиться и почтовый сервер, адресуемый уже другим айпи. В данном случае нельзя не упомянуть о поддоменах, про которые мы писали раньше. Простой пример поддомена популярного в России почтового сервиса: mail.yandex.ru.

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

  • А – адрес «сайта» домена.
  • MX – адрес «почтового сервера» того же домена.
  • CNAME – синоним домена. То есть, доменный адрес www.yavanya.com – синоним yavanya.com и, введя в браузере запрос без «www», вас все равно перенаправит на сайт.
  • NS – в данной записи содержатся домены DNS-серверов, обслуживающих конкретный домен.
  • TXT – тут может содержаться любое примечание в текстовом формате.

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

Дополнительная информация

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

  1. Мы говорили о доменах с адресами, включающими в себя четыре числа. Они относятся к стандарту IPv4 и могут обслужить ограниченное количество устройств: 4 294 967 296. Да, более четырех миллиардов компьютеров – это немало, но технологический прогресс стремителен и устройства, подключаемые к Интернету, приумножаются с каждым днем. Это привело к нехватке адресов. Во избежание данной проблемы были внедрены новые IPv6 – адреса с шестью числами, которые в DNS-зоне обозначаются, как AAAA. Благодаря новому стандарту, IP-адреса смогут получить значительно больше компьютеров.
  2. Чтобы повысить продуктивность и надежность сайта, одно доменное имя привязывают к нескольким адресам.
    Как правило, при запросе страницы DNS-сервера выдают IP в непроизвольном порядке.
  3. Один и тот же IP-адрес может быть связан с несколькими доменами. Вообще, это никак не отвечает принципам DNS, где предполагается однозначная связь айпи с доменом. Но, как мы уже упоминали выше, адресов IPv4 уже не хватает на все существующие сегодня интернет-устройства, и приходится экономить. На деле это выглядит так: на сервере с определенным IP-адресом размещают несколько мелких веб-ресурсов с разными доменами, но с одинаковыми адресами. Получая запрос, обслуживающий сайты компьютер обрабатывает запрашиваемый домен и отсылает пользователю нужный веб-ресурс.

Подводим итоги

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

DNS-зоны: редактор — Техническая документация — Помощь

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

В Личном кабинете на странице DNS-зоны представлен перечень зон, которые вы можете редактировать (изменения, внесенные вами, обновятся на нашем сервере в течение 30-40 минут, однако то, как скоро это будет заметно пользователям — напрямую зависит от настроек сервера интернет-провайдера, через которого производится подключение к сети). При нажатии на имя зоны (пусть в нашем примере это будет domain.tld) открывается страница DNS-редактора. Рассмотрим по отдельности каждое из представленных на этой странице полей.

  • Поле «имя» предполагает несколько вариантов заполнения:

    • @ — символ «@» означает, что действие записи будет распространяться на ту зону, на странице редактирования которой вы находитесь. В нашем случае — это domain.tld.
    • abc — набор букв и цифр («abc» было выбрано в качестве примера — вы можете указать свое имя) означает, что действие записи будет распространяться на зону более низкого уровня, чем та, на странице редактирования которой вы находитесь. В нашем примере — действие записи будет распространяться на зону abc.domain.tld.
    • * — символ «*» означает, что действие записи будет распространяться на все варианты зон ниже той, на странице редактирования которой вы находитесь. В нашем случае — это 123.domain.tld, abc.domain.tld, qwe.rty.domain.tld и т.д.
  • В поле «тип» вам предлагается несколько вариантов. Рассмотрим по-отдельности каждый из них:

    • A — используется для указания соответствия имени хоста IP-адресу.
    • MX — используется для указания почтового сервера для домена.
    • CNAME — используется для перенаправления имени хоста на другое имя.
    • SRV — используется для указания сервера, предоставляющего услуги определенной службы. В грубом приближении это аналог MX-записи, которая указывает, куда должна доставляться электронная почта, которая адресована определенному домену. Штатно поддерживается такими протоколами как XMPP(Jabber), SIP, LDAP. За счет использования этого вида записи можно разместить Jabber-сервер на отдельной машине, а не на той же, куда указывает A-запись DNS.
    • TXT — используется для указания дополнительной текстовой информации, которую хочет сообщить владелец домена.
  • Поле «MX preference» доступно для заполнения только в случае создания/редактирования записей типа MX. Указанное в этом поле числовое значение определяет приоритет использования почтового сервера. Поскольку для одного домена может быть указано несколько почтовых серверов — то, в какой последовательности на эти серверы будут осуществляться попытки доставить письмо, определяется именно приоритетом соответствующей MX-записи. Чем меньше число в поле «MX preference» — тем выше приоритет самого сервера.
  • Поле «значение (IP/host.)» заполняется в зависимости от выбранной записи:

Характерные DNS-записи

Рассмотрим несколько наиболее популярных ситуаций:

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

  • Если это нужно сделать для домена, указанного в разделе «DNS-зоны», кликните на него мышкой и, в случае если на новой странице существует запись:

    • @ IN A <серверы .masterhost>

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

    • имя: @
    • тип: A
    • значение (IP/host.): IP-адрес сервера
  • Если это нужно сделать для поддомена домена, указанного в разделе «DNS-зоны», кликните на имя домена мышкой, и добавьте новую запись со следующими параметрами:
    • имя: abc («abc» указано в качестве примера. Работает, если вы хотите создать запись для домена abc.domain.tld в зоне домена domain.tld. В вашем случае будет какое-то другое имя)
    • тип: A
    • значение (IP/host.): IP-адрес сервера

MX-запись: необходимо, чтобы почта домена обслуживалась другим сервером

  • Если вам неизвестно имя сервера, но вы знаете его IP-адрес —необходимо сначала в зоне домена создать новую запись со следующими параметрами:

    • имя: mail-server
    • тип: A
    • значение (IP/host.): IP-адрес почтового сервера
  • Если вы хотите изменить почтовый сервер для домена, указанного в разделе «DNS-зоны», кликните на него мышкой и, в случае если на новой странице существует запись:

    • @ IN MX 10 <серверы .masterhost>

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

    • имя: @
    • тип: MX
    • MX preference: числовое значение, допустим, 10.
    • значение (IP/host.): mail-server
  • Если вы хотите изменить почтовый сервер для поддомена домена, указанного в разделе «DNS-зоны», кликните на имя домена мышкой, и добавьте новую запись со следующими параметрами:
    • имя: abc («abc» указано в качестве примера. Работает, если вы хотите создать запись для домена abc.domain.tld в зоне домена domain.tld. В вашем случае будет какое-то другое имя)
    • тип: MX
    • MX preference: числовое значение, допустим, 10.
    • значение (IP/host.): mail-server

SRV-запись

Для внесения SRV-записи необходимо получить от владельца службы следующие данные:

  • Служба (service)
  • Протокол (proto)
  • Приоритет (priority)
  • Вес (weight)
  • Порт (port)
  • Сервер (target)

* TTL не изменяется, поэтому его указывать не нужно;

Имя записи формируется из имени службы и протокола: _служба. _протокол

Значение записи имеет следующий формат: приоритет вес порт сервер. (в конце имени обязательно должна быть точка!)

Пример правильно заполненной формы.

Список NS-серверов поддомена

Если основной домен делегирован на сервера masterhost, то смена NS-серверов поддомена третьего уровня производится через редактор DNS-Зоны.

Если поддержка основного домена оказывается на сторонних серверах, то изменение списка NS-серверов для его поддоменов производится в панели управления этими серверами.

PTR-запись: вы выделили мне IP-адрес, и я хочу установить соответствие между этим IP-адресом и именем определенного хоста

Для этого необходимо зайти в раздел DNS-зоны, выбрать ваш IP-адрес и нажать на кнопку «>>». В поле, доступное для редактирования, ввести имя хоста с точкой на конце и нажать «сохранить».

SPF-запись

Достаточно распространенным приемом, используемым организаторами СПАМ-рассылок, является подделка обратного адреса письма. В этом случае на Ваши почтовые ящики иногда могут приходить служебные сообщения об ошибках (bounce message), если одно или несколько таких СПАМ-писем с обратным адресом Вашего почтового ящика были заблокированы серверами получателей.

Есть несколько технологий, которые помогут защитить Ваш почтовый домен от использования злоумышленниками: SPF, DKIM, DMARC

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

  • имя: @
  • тип: TXT
  • значение: v=spf1 include:_spf.masterhost.ru -all

Это правило заставит серверы получателей блокировать все СПАМ-письма, которые используют в качестве адресов отправителя Ваше доменное имя. Подробнее о технологии SPF.

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

DKIM

Для защиты от мошеннических действий от имени Вашего домена мы рекомендуем добавить DKIM-запись в DNS-зону. Если Вы используете нашу почту, добавить DKIM можно в Личном кабинете cp.masterhost.ru.

  • Exchange-почта:

    Древо услуг – почта (ms exchange) eXXXXX – DKIM (MS Exchange) – добавить

  • Почта, входящая в состав хостинга:

    Древо услуг – Ваш домен – DKIM – добавить

CAA-запись

С помощью этой записи вы можете указать удостоверяющие центры, имеющие право выпускать SSL/TLS-сертификаты для данного домена. Запись CAA позволяет избежать несанкционированной выдачи сертификатов по ошибке или с целью мошенничества.

Это только пример, точную информацию по содержанию поля "Значение" следует уточнять у Вашего удостоверяющего центра.

Изменение NS-серверов домена

Для изменения списка DNS-серверов следует:
  • Зайти в Личный кабинет;
  • Указать логин cXXXXX и пароль;
  • Открыть раздел «Общие услуги» и нажать «изменить» напротив нужного домена;
  • Нажать на ссылку «Изменить настройки делегирования»;
  • Чтобы указать сторонние серверы, выберите «Делегировать на сторонние серверы»;
  • Впишите адреса DNS серверов по одному на строке;
  • Для отмены предварительного тестирования DNS-серверов, отметьте свойство «Без тестирования»;
  • Нажмите кнопку «Сохранить».

Если логин cXXXXX и пароль доступа к Личному кабинету утеряны, то для восстановления реквизитов доступа Вы можете воспользоваться ссылкой «Напомнить».

Важно:
  1. Изменение списка DNS-серверов возможно только после завершения мобильной авторизации.
  2. С момента делегирования домена (изменения его списка NS-серверов) потребуется от 6 до 72  часов прежде чем он будет доступен в сети Интернет.

DNS ▷ Что такое Ресурсные записи DNS? DNS — SOA запись

Что такое DNS?

Доменная система имён (DNS) – собственно, система, привязывающая IP-адрес к символьному имени домена. Система DNS работает по принципу иерархии и использует произвольное количество частей (доменов), разделяемых точкой. Корневые домены или домены верхнего уровня в сети Internet управляются центром InterNIC (Public Information Regarding Internet Domain Name Registration Services).

Каждая страна имеет свои двухбуквенные домены, кроме того существуют домены и для типов организаций (.com — коммерческие организации; .edu — учебные заведения; .gov — правительственные учреждения; .mil — военные учреждения; .org — прочие организации; .net — сетевые ресурсы).

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

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

Пример файла зоны:

$TTL 1h
@ 86400 IN SOA ns.example.com. hostmaster.example.com.  (
2009092102 ; Serial 
10600 ; Refresh 
800 ; Retry 
3400000 ; Expire 
86400 ) ; TTL
)

;;; NS ;;;
	       NS	ns1.my-ns-server.com.
	       NS	ns.my-secondary-ns.com.

;;; MX ;;;
		MX 10	mx. example.com.

;;; A ;;;
	        A	192.168.0.1
www		CNAME	@
mx		A	192.168.0.1

Все директивы и ресурсные записи вводятся в отдельной строке, комментарии размещаются после точки с запятой (;).

Директивы начинаются со знака доллара ($), после которого вводится имя директивы. Зачастую директивы пишут в начале файла зоны.

Ниже приведены часто используемые директивы:

$ INCLUDE — Позволяет включить другой файл зоны в этот файл зоны в месте, где появляется директива. Это позволяет хранить дополнительные настройки файла зоны отдельно от основного файла зоны.

$ ORIGIN — Добавляет имя домена к относительному доменному имени. По умолчанию $ORIGIN принимает значение доменного имени, указанного в операторе zone.

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

Основные ресурсные записи DNS

Основополагающая запись DNS — SOA (start of authority record) или начальная запись зоны: запись, указывающая местоположение эталонной записи о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги кеширования зонной информации и данные о взаимодействиях DNS-серверов.

Пример записи SOA:

@     IN     SOA    <primary-name-server>     <hostmaster-email> (
                    <serial-number>
                    <time-to-refresh>
                    <time-to-retry>
                    <time-to-expire>
                    <minimum-TTL> )

Например:

@ 86400 IN SOA ua.example.com. hostmaster.example.com.  (
2009092102 ; Serial 
10600 ; Refresh 
800 ; Retry 
3400000 ; Expire 
86400 ) ; Minimum TTL

Где:

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

Refresh — значение времени в секундах. Показывает время, через которое вторичный сервер будет пытаться обновить данные зоны с первичного сервера (читая SOA первичного сервера). Рекомендуется устанавливать значения от 1200 до 43200 секунд. Низкое значение (1200) устанавливается при частой необходимости обновления данных. Высокое 43200 (12 часов), если такой необходимости нет.

Retry — значение времени в секундах. Определяет время между попытками, если вторичный сервер не может связаться с первичным сервером, когда время обновления истекло. Рекомендуемые значения от 180 (3 минуты) до 900 (15 минут) и выше.

Expire — значение времени в секундах. Значение срока. Если попытки обновления данных не привели к успеху, то по истечении срока вторичный сервер перестаёт отвечать на запросы для данного домена и стирает свою копию файла зоны. Если контакт установлен, значения срока и обновления сбрасываются, и цикл начинается снова. Рекомендуется устанавливать значения от 1209600 до 2419200 секунд (2-4 недели).

TTL – Время жизни. Время, на протяжении которого запись ресурса этой зоны действительна в кэше других серверов.

*Обратите внимание, что временные промежутки можно вводить не только в секундах. Возможны варианты ввода данных в других форматах, например: 2w14h(2 недели 14 часов), 1d2h(1 день 2 часа), 4h40m(4 часа 30 минут), 30m45s(30 минут 45секунд), или любые другие варианты при использовании соответствующих букв. Кроме записи SOA, существуют другие ресурсные записи. Мы рассмотрим основные:

Запись А – запись соответствия имени хоста его IP-адресу.

Запись AAAA — запись соответствия имени хоста его IP-адресу для протокола IPv6.

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

Запись MX (Mail Exchanger) – запись адреса почтового шлюза для домена. Управляет маршрутизацией почтовых сообщений для протокола SMTP. Запись критически важна для протокола SMTP.

Запись NS (Name Server) – запись адреса узла отвечающего за доменную зону. Указывает на сервера DNS, ответственные за конкретный домен и его поддомены.

Запись PTR (Domain name pointer) — используется для обратного разрешения IP-адресов в имена узлов в домене in-addr.arpa.

Запись SRV (Service Locator) — указатель на службу. Запись используется для поиска серверов, на которых функционируют определенные службы (Active Directory, Jabber).

DNSSEC – что это такое и почему эта технология так важна?

Интересуетесь протоколом DNSSEC (расширениями безопасности системы доменных имен)? Нажмите на изображение ниже, чтобы изучить нашу инфографику с описанием принципов работы DNSSEC и преимуществ его развертывания.

Краткое описание принципов работы DNS

Для понимания протокола DNSSEC (расширения безопасности системы доменных имен) важно иметь общее представление о системе доменных имен (DNS).

Надлежащее функционирование интернета напрямую зависит от DNS. Посещение веб-страниц, отправка сообщений по электронной почте, получение изображений из соцсетей — во всех этих формах взаимодействия для преобразования понятных человеку доменных имен (например, icann.org) в IP-адреса (например, 192.0.43.7 и 2001:500:88:200::7), необходимые серверам, маршрутизаторам и другим сетевым устройствам для придания трафику в интернете нужного направления, используется DNS.

Пользование интернетом на любом устройстве начинается с DNS. Представьте, например, момент ввода пользователем имени сайта в браузер на телефоне. Браузер при помощи stub-резолвера, являющегося частью операционной системы устройства, начинает преобразование доменного имени сайта в адрес интернет-протокола (IP-адрес). Stub-резолвер представляет собой простейший DNS-клиент, передающий запрос данных DNS более сложному DNS-клиенту, называемому рекурсивным резолвером. У многих сетевых операторов есть рекурсивные резолверы для обработки DNS-запросов — или просто запросов — отправляемых устройствами в их сети. (Менее крупные операторы и организации иногда пользуются рекурсивными резолверами других сетей, в том числе предоставляемыми открыто в качестве услуги, такими как Google Public DNS, OpenDNS и Quad9).

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

Сама по себе DNS не имеет системы защиты

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

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

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

Расширения безопасности DNS (DNSSEC)

Члены Инженерной проектной группы интернета (IETF) — организации, ответственной за стандарты протокола DNS — давно осознали проблему недостаточной надежности механизмов проверки подлинности в DNS. Работа над выработкой решения началась в 1990-х годах, и ее результатом стал протокол DNSSEC (расширения безопасности системы доменных имен).

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

У каждой зоны DNS есть пара открытых/закрытых ключей. Владелец зоны использует ее закрытый ключ для подписания данных DNS в этой зоне и генерирования цифровых подписей для этих данных. Как следует из названия «закрытый ключ», сведения о нем держатся владельцем зоны в секрете. А вот открытый ключ зоны публикуется в ней свободно, и получить его может каждый. Любой рекурсивный резолвер, производящий поиск данных в зоне, также получает открытый ключ этой зоны и использует его для проверки подлинности данных DNS. Резолвер проверяет подлинность цифровой подписи полученных им данных DNS. Если подлинность подтверждается, то данные DNS считаются настоящими и возвращаются пользователю. Если подпись не проходит проверку подлинности, то резолвер предполагает, что произошла атака, избавляется от данных и сообщает пользователю об ошибке.

Применение DNSSEC позволяет обеспечить две важные функции в DNS:

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

Доверие к ключам DNSSEC

Каждая зона публикует свой открытый ключ, и рекурсивный резолвер получает его для проверки подлинности данных в этой зоне. Но как резолверу проверить подлинность самого этого ключа? Как и все остальные данные в зоне, открытый ключ зоны тоже подписывается. Однако открытый ключ зоны подписывается не ее же закрытым ключом, а закрытым ключом ее родительской зоны. Например, открытый ключ зоны icann.org подписывается зоной org. Родительская зона DNS отвечает как за публикацию списка авторитативных DNS-серверов своей дочерней зоны, так и за подтверждение подлинности ее открытого ключа. Открытый ключ каждой зоны подписывается ее родительской зоной. Исключение составляет корневая зона — ее ключ подписывать некому.

Таким образом, открытый ключ корневой зоны является важной отправной точкой проверки подлинности данных DNS. Если резолвер доверяет открытому ключу корневой зоны, то он может доверять подписанным ее закрытым ключом открытым ключам зон верхнего уровня, например, открытому ключу зоны org. И поскольку резолвер может доверять открытому ключу зоны org, он может доверять открытым ключам, подписанным ее закрытым ключом, например, открытому ключу зоны icann.org. (На самом деле родительская зона не подписывает ключ дочерней зоны напрямую — реальный механизм более сложен, но конечный результат ничем не отличается от подписания дочернего ключа родительским.)

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

Проверка подлинности и подписание посредством DNSSEC

Для обеспечения в интернете повсеместной безопасности необходимо масштабное внедрение DNSSEC. DNSSEC не включается автоматически: в настоящее время сетевые операторы должны включать его вручную на своих рекурсивных резолверах, а владельцы доменных имен — на авторитативных серверах своих зон. Операторы резолверов и авторитативных серверов имеют разные причины для включения DNSSEC на своих системах, но когда они их включают, на получение подлинных ответов на свои запросы DNS может рассчитывать большее количество пользователей. Иными словами, пользователь может быть уверен, что попадет в интернете в то место, куда желает попасть.

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

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

Если говорить о внедрении DNSSEC владельцем зоны путем подписания ее данных, то для обеспечения максимальной эффективности DNSSEC требуется, чтобы родительская зона этой зоны тоже была подписана, как и следующая за ней, и так далее вплоть до корневой зоны. Благодаря непрерывной цепи подписанных зон, начинающейся с корневой зоны, резолвер может выстроить цепочку доверия от корневой зоны для проверки подлинности данных. Например, для эффективного внедрения DNSSEC в зоне icann.org необходимо, чтобы была подписана зона org, а также корневая зона. К счастью, корневая зона DNS подписана с 2010 года, и все gTLD и многие ccTLD тоже.

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

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

Дальнейшие действия, связанные с DNSSEC

По мере внедрения DNSSEC DNS может стать основой для других протоколов, предполагающих наличие надежного способа хранения данных. Разработаны новые протоколы, опирающиеся на DNSSEC и работающие только в подписанных зонах. Например, DANE (аутентификация именованных объектов на базе DNS) предусматривает публикацию в зонах ключей защиты транспортного уровня (TLS) для таких приложений как почта. DANE предоставляет возможность проверять подлинность открытых ключей, не зависящую от центров сертификации. Новые способы повышения уровня конфиденциальности DNS-запросов также будут предусматривать возможность использования DANE.

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

Как управлять файлами зоны DNS | Домены

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

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

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

  • Запись A. Главная запись DNS, связывающая ваш домен с IP-адресом, который приводит посетителей на ваш веб-сайт. Добавить / Изменить / Удалить
  • Поддомен. Любая запись DNS, используемая в качестве префикса вашего доменного имени, например blog.coolexample.com. Поддомен можно создать с помощью записи A, которая указывает на IP-адрес (самый распространенный вариант), записи CNAME, которая указывает на URL, или даже с помощью записи MX. Добавить / Изменить / Удалить
  • Запись CNAME. Эта запись также выступает префиксом доменного имени и иногда может считаться поддоменом. Запись CNAME не может указывать на IP-адрес, а только на другое доменное имя или URL. Например, вы можете создать запись CNAME для домена store.coolexample.com, которая указывает на другой URL, допустим на магазин, созданный на платформе Shopify. Добавить / Изменить / Удалить
  • Запись MX. Управляет вашим адресом электронной почты. Благодаря ей письма попадают в ваш почтовый ящик. Разные почтовые сервисы используют разные записи MX. В почте GoDaddy эти записи настраиваются автоматически. Добавить / Изменить / Удалить
  • Запись TXT. Позволяет подтвердить право собственности на домен и настроить правила для отправителей писем. Добавить / Изменить / Удалить
  • Запись SPF. Тип записи TXT, позволяющей настраивать правила для отправителей писем. Это дополнительный тип записи DNS. Добавить / Изменить / Удалить
  • Запись NS. Содержит сведения о ваших DNS-серверах. Используйте эти записи, чтобы понять, какие DNS-серверы вам нужно использовать, если ваш домен не зарегистрирован в GoDaddy, но вы хотите настраивать DNS у нас. Это дополнительный тип пользовательской записи DNS. Добавить / Изменить / Удалить

Статьи по теме

Новые возможности сервера DNS в Windows Server

Автор статьи - Андрей Каптелин, участник ИТ-сообщества

 
С выходом Windows Server Technical Preview 2 многие службы получили обновления. Не обошли обновления стороной и заслуженный сервер имен DNS. Помимо поддержки управления DNS-сервером из PowerShell, появилась новая возможность – DNS policy.

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

Принцип работы


Политики применяются к трем категориям запросов:

   - Запрос на разрешение записи. Все обычные запросы на разрешение имени в IP-адрес, или получение значений TXT-, MX- и SRV-записей.

   - Запрос на передачу зон. Запросы от ваших вторичных серверов на обновление информации о зоне. Если такой запрос будет выполнен для чужого сервера, он получит всё содержимое вашей зоны.

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

 
Область применения политики может быть, как на весь сервер, так и на конкретную зону, если эта зона не интегрирована в Active Directory.

 

Политики DNS-сервера позволяют реализовать следующие действия:

   - Создавать зону с различным набором записей.

   - Классифицировать клиента по его IP-адресу и использовать это в правилах применения политик.

   - Применять политики на весь сервер и на зоны, не интегрированные в АД.

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

   - Применять политики в зависимости от времени суток.

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

   - Отвечать на запросы данными из различных версий зоны в заданных пропорциях, похоже на управляемый Round Robin.

   - Применять политики для пересылки зон.

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

   - Располагать политики в нужном порядке обработки.


Все созданные политики сохраняются в реестре в следующих разделах:

Заданные подсети, используемые в правилах применения политик, хранятся в разделе реестра


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\ClientSubnets
Политики, применяемые на сервер, хранятся в разделе реестра


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Policies
Политики, применяемые к конкретной зоне, хранятся в разделе реестра


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\{имя зоны}\Policies
Зоны, используемые в правилах рекурсивных запросов, хранятся в разделе реестра


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ServerScopes
Значение о состоянии рекурсии для всего сервера (используется зона ". ") хранится в разделе


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
Ключ NoRecursion равен «0» - рекурсия включена, «1» - выключена. Переключение из включенного в выключенное состояние, требует перезапуска службы DNS-сервера.

Если для зоны создается альтернативное содержание (Add-DnsServerZoneScope), оно помещается в файле, размещенном в
C:\Windows\System32\dns\{имя зоны} 
А конфигурация записывается в реестр


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\{имя_зоны}\ZoneScopes\
При удалении альтернативной версии зоны, запись в реестре удаляется, а файл альтернативного содержания остаётся на месте.

Несмотря на обилие мест расположения настроек, для их изменений достаточно несколько команд PowerShell.

Для работы с политиками запросов разрешения записи и рекурсивных запросов:
Add-DnsServerQueryResolutionPolicy   
Get-DnsServerQueryResolutionPolicy   
Set-DnsServerQueryResolutionPolicy   
Remove-DnsServerQueryResolutionPolicy 

 
Для работы с запросами по передаче зон:
Add-DnsServerZoneTransferPolicy      
Get-DnsServerZoneTransferPolicy      
Set-DnsServerZoneTransferPolicy   
Remove-DnsServerZoneTransferPolicy 

 
Действия выполнения политик могут быть следующие:
-Action ALLOW – запрос выполняется сервером DNS
-Action DENY – сервер DNS отвечает отказом
-Action IGNORE – запрос не обрабатывается сервером DNS

Для понимания этапов обработки политик есть следующие схемы прохождения запроса.
  
Схема обработки запросов разрешения записи и рекурсивных запросов: 

Схема обработки запросов на передачу зон:

 

Примеры

Настройка ограничения выполнения рекурсивных запросов


Есть задача настроить DNS-сервер на выполнение рекурсивных запросов только для внутренних клиентов. Сервер имеет два сетевых интерфейса. У внешнего IP-адрес 1.1.1.1, у внутреннего интерфейса IP-адрес 10.0.0.39. Можно выполнить эту задачу, ограничив выполнение таких запросов только внутренним интерфейсом. Для этого необходимо запретить рекурсивные запросы на уровне сервера и разрешить только для запросов, полученных внутренним интерфейсом.


# Запрещаем рекурсию на область «.» - т.е. на уровне сервера
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
# Добавляем область для внутренних клиентов с разрешением выполнения рекурсивных запросов
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
# Создаём правило, разрешающее рекурсивные запросы
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10. 0.0.39" 

Разберём команду создания политики подробнее.
Add-DnsServerQueryResolutionPolicy – командлет создания политики обработки запросов на разрешение записей и рекурсивных запросов.
-Name "SplitBrainRecursionPolicy" – имя политики
-Action ALLOW – действие политики – выполнить запрос
-ApplyOnRecursion – политика обрабатывает только запросы, для которых нужно выполнить рекурсивный запрос
-RecursionScope "InternalClients – получает значение разрешения или запрета рекурсии заданной ранее области
-ServerInterfaceIP "EQ,10.0.0.39" – правило применения политики – только запрос, пришедший на интерфейс сервера с IPv4-адресом равным 10.0.0.39.

 

Модификация ответа на запрос разрешения имени


В компании есть отказоустойчивый веб-сервер, размещенный на двух площадках – в Европе и в Австралии. Скорость работы обоих площадок всегда одинакова, но в ночные часы стоимость аренды меньше. Компания решила задействовать площадки в зависимости от времени суток. Для этого принято решение распределять запросы клиентов в процентном отношении 80/20 на ночной и дневной датацентр.

# Создаём версии зоны для Европы и Австралии 
Add-DnsServerZoneScope -ZoneName "testzone.z" -Name "EuropeDC"
Add-DnsServerZoneScope -ZoneName "testzone.z" -Name "AustralianDC"

 

# Создаём запись для веб-сервера в новых зонах с указанием на разные датацентры 
Add-DnsServerResourceRecord -ZoneName "testzone.z" -A -Name "www" -IPv4Address "1.1.1.1" -ZoneScope "EuropeDC"
Add-DnsServerResourceRecord -ZoneName "testzne.oz" -A -Name "www" -IPv4Address "2.2.2.2" -ZoneScope "AustralianDC"

# Создаём политики обработки запросов по наших условиям
Add-DnsServerQueryResolutionPolicy -Name "www-6-18" -Action ALLOW -ZoneScope "AustralianDC,4;EuropeDC,1" –TimeOfDay “EQ,06:00-18:00” -ZoneName "testzone. z" –ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "www-0-6" -Action ALLOW -ZoneScope "AustralianDC,1;EuropeDC,4" –TimeOfDay “EQ,00:00-06:00” -ZoneName "testzone.z" –ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "www-18-24" -Action ALLOW -ZoneScope "AustralianDC,1;EuropeDC,4" –TimeOfDay “EQ,18:00-23:59” -ZoneName "testzone.z" –ProcessingOrder 3

Разберём команду создания политики подробнее.
Add-DnsServerQueryResolutionPolicy – командлет создания политики
-Name "www-6-18" – имя политики
-Action ALLOW – действие политики – выполнить запрос
-ZoneScope "AustralianDC,4;EuropeDC,1" – указывает политике, использовать две версии зоны в пропорциях 4 к 1, получая требуемое соотношение 80% к 20% в выдаче данных из версии зоны для Европы и Австралии
–TimeOfDay “EQ,06:00-18:00” – Время действия политики
-ZoneName "testzone.z" – имя зоны, для которой действует политика
–ProcessingOrder 1 – очередность применения политики, для политик этой зоны

 

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


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

# Создаём диапазоны адресов наших вторичных DNS-серверов
Add-DnsServerClientSubnet -Name "DNSsecondary1" -IPv4Subnet 4.4.4.4/32
Add-DnsServerClientSubnet -Name "DNSsecondary2" -IPv4Subnet 5.5.5.5/32
# Создаём политику обработки запросов на перенос зон
Add-DnsServerZoneTransferPolicy -Name "Allow secondary DNS" -ZoneName "testzone.z" -Action IGNORE -ClientSubnet "ne,DNSsecondary1,DNSsecondary2"

Разберём команду создания политики подробнее.
Add-DnsServerZoneTransferPolicy – командлет создания политики обработки запросов на перенос зон
-Name "Allow secondary DNS" – название политики
-ZoneName "testzone.z" – название зоны, для которой будет действовать политика
-Action IGNORE – действие политики
-ClientSubnet "ne,DNSsecondary1,DNSsecondary2" – условие применения для всех кроме наших серверов

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

Ссылки по теме


DNS Policies Overview
Статьи в блоге Windows Networking Team [MSFT]

DNS-зон объяснены

Что такое зона DNS?

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

Когда веб-обозревателю или другому сетевому устройству необходимо найти IP-адрес для имени хоста, например, «example.com », он выполняет поиск DNS - по сути, проверку зоны DNS - и передается на DNS-сервер, который управляет зоной DNS для этого имени хоста. Этот сервер называется официальным сервером имен для домена. Затем авторитетный сервер имен выполняет поиск в DNS, предоставляя IP-адрес или другие данные для запрошенного имени хоста.


Уровни зоны DNS

Система доменных имен (DNS) определяет пространство доменных имен, которое определяет домены верхнего уровня (например, «.com»), домены второго уровня (например, «acme.com ») и домены нижнего уровня, также называемые субдоменами (например,« support.acme.com »). Каждый из этих уровней может быть зоной DNS.

Например, корневой домен «acme.com» может быть делегирован корпорации Acme. Acme берет на себя ответственность за настройку авторитетного DNS-сервера, который содержит правильные DNS-записи для домена.

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


Корневая зона DNS

Корень системы DNS, представленный точкой в ​​конце имени домена, например www.example.com . - это основная зона DNS. С 2016 года за корневой зоной наблюдает Интернет-корпорация по присвоению имен и номеров (ICANN), которая делегирует управление дочерней компании, действующей в качестве Управления по присвоению номеров в Интернете (IANA).

Корневая зона DNS обслуживается 13 логическими серверами, управляемыми такими организациями, как Verisign, U.С. Исследовательские лаборатории армии и НАСА. Любой рекурсивный DNS-запрос (узнайте больше о типах DNS-запросов) начинается с обращения к одному из этих корневых серверов и запроса сведений для следующего уровня вниз по дереву - сервера домена верхнего уровня (TLD).


Зоны TLD

Существует зона DNS для каждого домена верхнего уровня, например «.com», «.org» или кода страны, например «.co.uk». в настоящее время существует более 1500 доменов верхнего уровня. Большинство доменов верхнего уровня управляется ICANN / IANA.


Доменные зоны

Домены второго уровня, такие как просматриваемый вами домен «ns1.com », определяются как отдельные зоны DNS, управляемые отдельными лицами или организациями. Организации могут запускать свои собственные DNS-серверы имен или делегировать управление внешнему провайдеру.

Если в домене есть поддомены, они могут быть частью одной зоны. В качестве альтернативы, если поддомен является независимым веб-сайтом и требует отдельного управления DNS, его можно определить как отдельную зону DNS. На приведенной выше диаграмме «blog.example.com» был настроен как зона DNS, тогда как «support.example.com» является частью «example.com »DNS-зона.


Вторичные зоны DNS

DNS-серверы

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


Все о файле зоны DNS

Файлы зоны DNS определены в RFC 1035 и RFC 1034. Файл зоны содержит сопоставления между доменными именами, IP-адресами и другими ресурсами, организованные в форме записей ресурсов (RR).

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

Типы зон DNS

Есть два типа файлов зон:

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

Записи зоны DNS

В файле зоны каждая строка представляет запись ресурса DNS (RR).Запись состоит из следующих полей:

имя

ttl

класс записи

тип записи

данные записи

  • Имя является буквенно-цифровым идентификатором записи DNS. Его можно оставить пустым и унаследовать свое значение от предыдущей записи.
  • TTL (время жизни) указывает, как долго запись должна храниться в локальном кэше DNS-клиента.Если не указано, используется глобальное значение TTL в верхней части файла зоны.
  • Класс записи указывает пространство имен - обычно IN, которое является пространством имен Internet.
  • Тип записи - это тип записи DNS - например, запись A сопоставляет имя хоста с адресом IPv4, а CNAME - это псевдоним, который указывает имя хоста на другое имя хоста.
  • Данные записи содержат один или несколько информационных элементов, в зависимости от типа записи, разделенных пробелом.Например, запись MX имеет два элемента - приоритет и доменное имя для почтового сервера.

Файловая структура зоны

Файлы зоны DNS начинаются с двух обязательных записей:

  • Глобальное время жизни (TTL) , который указывает, как записи должны храниться в локальном кэше DNS.
  • Запись начала полномочий (SOA) - указывает основной полномочный сервер имен для зоны DNS.

После этих двух записей файл зоны может содержать любое количество записей ресурсов, в том числе:

  • Записи сервера имен (NS) - указывает, что определенная зона DNS, например «example.com »делегируется определенному официальному серверу имен
  • Записи сопоставления адресов IPv4 (A) - имя хоста и его IPv4-адрес.
  • Записи IPv6-адреса (AAAA) - имя хоста и его IPv6-адрес.
  • Записи канонического имени (CNAME) - указывает имя хоста на псевдоним. Это еще одно имя хоста, которое DNS-клиент перенаправляется на
  • Запись почтового обменника (MX) - указывает почтовый сервер SMTP для домена.


Советы по файлам зон

  • При добавлении записи для имени хоста имя хоста должно заканчиваться точкой (. )
  • Имена хостов, которые не заканчиваются точкой, считаются относительно основного имени домена - например, при указании записи «www» или «ftp» точка не требуется.
  • Вы можете добавить комментарии в файл зоны, добавив точку с запятой (;) после записи ресурса.


Пример файла зоны DNS

 $ ORIGIN example.com. ; запуск файла зоны $ TTL 30млн; время истечения срока действия кеша по умолчанию для ресурса recordsexample.com. В SOA ns.example.com. root.example.com. (199

01; серийный номер этой зоны file1d; частота обновления вторичного DNS (d = день) 1d; частота обновления вторичного DNS в случае проблемы4w; время истечения срока действия вторичного DNS (w = неделя) 1h; минимальное время кэширования, если разрешение не удалось, пример. com. NS dns1.dnsprovider.com.; существуют два сервера имен, которые могут предоставлять услуги DNS, например, example.comexample.com. NS dns2.dnsprovider.com.example.com. MX 10 mx1.dnsprovider.com; mail serverexample. com . MX 10 mx2.dnsprovider.comexample.com. A 192.168.100.1; IP-адрес корневого домена www A 192.168.100.1; IP-адрес для субдомена www

Зоны DNS и службы DNS нового поколения

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

NS1 обеспечивает:

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

Что такое зона DNS и как она работает?

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

Зона DNS

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

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

Файл зоны DNS

Файл зоны DNS представляет собой зону DNS - это фактический файл, который содержит все записи для определенного домена. В файле зоны DNS каждая строка может содержать только одну запись, и каждый файл зоны DNS должен начинаться с TTL (Time to Live), который указывает, как долго записи должны храниться в кэше DNS-сервера. Другой обязательной записью для файла зоны DNS является запись SOA (Start of Authority) - она ​​указывает основной полномочный сервер имен для зоны DNS.

После того, как эти две записи указаны, могут быть добавлены дополнительные записи, такие как записи A или NS. При добавлении записи для имени хоста имя хоста должно заканчиваться точкой (.). Имена хостов, которые не заканчиваются точкой, считаются относительно основного доменного имени, для которого была создана зона DNS. Например, при указании записи «www» нет необходимости ставить после нее точку.

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

Пример файла зоны DNS:

$ ORIGIN example.com. ; обозначает начало этого файла зоны в пространстве имен
$ TTL 1h; Срок действия записи ресурса по умолчанию без собственного значения TTL
example.com. В SOA ns.example.com. root.example.com. (
2008120710; серийный номер файла этой зоны
1d; обновление ведомого (1 день)
1d; время повтора ведомого устройства в случае проблемы (1 день)
4w; время истечения срока действия ведомого ( 4 недели)
1 час; минимальное время кеширования в случае неудачных поисков (1 час)
)
пример.com. NS dns1.ntchosting.com. ; ns.example.com - это сервер имен для example.com
example.com. NS dns2.ntchosting.com. ; ns.somewhere.com - это резервный сервер имен для example.com
example.com. MX 10 mx1.ntchosting. com
example.com. MX 10 mx2.ntchosting.com; mail.example.com - это почтовый сервер для example.com
example.com. А 209.25.134.47; IP-адрес для example.com
www A 209.25.134.47

Управление зоной DNS

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

Как декодировать типы зон DNS

Время чтения: 4 минуты

Что такое зона DNS?

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

Что такое файл зоны DNS?

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

 ; g33k.fun файл зоны DNS
14400 долларов США
g33k.fun. 86400 В SOA ns1.domain.com. user.mail.com. (
2020081601; Серийный номер
3600; обновить
7200; повторить
1209600; срок действия истекает
86400; минимум
        )
g33k.fun. 86400 IN NS ns1.domain.com.
g33k.fun. 86400 IN NS ns2.domain.com.
g33k.fun. 14400 IN A 67.257.187.136
g33k.fun. 14400 IN MX 0 g33k.fun.
mail 14400 IN CNAME g33k.fun.
www 14400 В CNAME g33k.fun.
ftp 14400 IN A 67.257.187.136
g33k.fun. 14400 IN TXT "v = spf1 + a + mx + ip4: 67. 257.187.136 ~ all"
default._domainkey 14400 IN TXT "v = DKIM1; k = rsa; p = MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ;
g33k.fun. 14400 IN TXT google-site-verify = zxIkMo9ruPbMyGMy4KWbc0QkOoN9aF2iFPvDHc0o8Pg  

Типы записей

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

Начало полномочий (SOA)

Первая запись в любом файле зоны - это запись ресурса SOA. Эта запись является важной частью файла зоны DNS. Он указывает зону домена и основные свойства сервера доменных имен. Каждый файл зоны может содержать только одну запись SOA.

  Запись SOA:
Основной сервер имен: ns1.google.com
Адрес электронной почты Hostmaster: dns-admin.google.com
Серийный номер: 329472109
Обновить: 900
Повтор: 900
Срок действия: 1800 30 минут
TTL по умолчанию: 60  

Сервер имен (NS)

Записи

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

  g33k.fun. 86400 IN NS ns1.domain.com.
g33k.fun. 86400 IN NS ns2.domain.com.  

Примечание

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

Почтовый обмен (MX)

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

  g33k.fun. 14400 IN MX 0 g33k.fun.  

Адрес (A)

Запись A используется для поиска IP-адреса, связанного с доменным именем.Эта запись направляет информацию с сервера в веб-браузер клиента.

  g33k.fun. 14400 ИН А 67.257.187.136  

AAAA

Счетверенная запись A имеет ту же функцию, что и запись A, но используется специально для протокола IPv6.

  g33k.fun. 14400 В AAAA 2001: db8: 1 :: ab9: C0A8: 102  

Каноническое имя (CNAME)

Эта запись будет связывать имя одного сайта с другим. Затем поиск DNS направит запросы доменного имени на новое имя, содержащееся в записи A.Эти записи должны указывать на полное доменное имя (FQDN).

  ftp.g33k.fun. CNAME g33k.fun.  

Запись псевдонима (ALIAS)

Запись ALIAS функционально аналогична записи CNAME в том, что она используется для указания одного имени на другое. Запись ALIAS используется для ссылки на основной домен или домен Apex (example.com) на поддомен (host.example.com). Полномочные серверы имен для основного домена впоследствии будут разрешать IP-адрес имени хоста, чтобы направлять туда трафик.

  ТИП HOST TARGET TTL
НИКНЕЙМЫ (или ИМЯ) @ host.g33k.fun. 5  

Текст (TXT)

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

  g33k.fun. 14400 IN TXT "v = spf1 + a + mx + ip4: 67.257.187.136 ~ all"  

Сервисный локатор (SRV)

SRV-записи - это обобщенная запись о местоположении службы.Он используется для новых протоколов вместо создания специфичных для протокола записей, таких как MX. Этот тип записи хоть и полезен, но обычно не используется.

  ДОМЕННЫЙ TTL ТИП PRI WT PORT TARGET
sip.g33k.fun. 86400 IN SRV 0 5 5060 sipserver.g33k.fun.
  

Указатель (PTR)

Запись PTR указывает IP на каноническое имя и явно используется в обратных записях DNS. Важно отметить, что обратные записи DNS настраиваются на авторитетных серверах имен лицом, которому принадлежит IP, а не лицом, которому принадлежит каноническое имя.

  136.257.187.67.in-addr.arpa. В ПТР g33k.fun.  

Заключение

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

Мы гордимся тем, что являемся самыми полезными людьми в Hosting ™!

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

Если у вас есть какие-либо вопросы относительно этой информации, мы всегда готовы ответить на любые вопросы по вопросам, связанным с этой статьей, 24 часа в сутки, 7 дней в неделю, 365 дней в году.

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

Зоны DNS и объяснение файлов зон

DNS состоит из логически из доменов , но физически из зон.

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

В большинстве случаев у вас есть отношение 1 к 1 между доменом и зоной DNS, то есть домен mydomain. com будет храниться в файле зоны , называемом mydomain.com.txt.

Это руководство предназначено для начинающих, и вы узнаете:

  • Что такое зона DNS.
  • Что такое файл зоны
  • Как зоны DNS связаны с доменами
  • Различные типы зон
  • Как работает перенос зоны

Чтобы объяснить, какие зоны и файлы зон и как они работают, мы начнем с простой аналогии.

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

Команды A, B, C, и каждая команда состоит из 20 игроков.

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

Итак, вы можете создать бумажный список и написать в нем имена и номера телефонов. (По сути, это был подход с использованием файлов hosts.

Это работает, но становится проблемой, если лига расширяется и вы получаете, например, 10 команд.

Таким образом, альтернативой является создание трех списков : один для teamA, один для teamB и один для teamC.

Если добавляется другая команда, вы создаете еще один бумажный список для teamD.Итак, теперь у вас есть три списка, но кто ими управляет?
Ну, у каждой команды есть менеджер, так что вы позволяете менеджеру вести список за команду. Итак

  • Джон управляет командой A
  • Фред управляет командойB
  • Джейн управляет командойC

Теперь организатору лиги Биллу нужен телефонный номер Стива, который играет за TeamA. Как он это получил?

Ну, сначала ему нужно знать, у кого есть список игроков TeamA.

Итак, Bill нуждается в списке с именем и телефонными номерами всех менеджеров..

Не важно имя менеджера, важен только номер телефона.

Итак, если кто-то хочет узнать номер телефона Стива в команде A, он связывается с Биллом, который возвращает номер телефона менеджера команды A (Джон). Затем они связываются с Джоном, чтобы узнать номер телефона Стива. Как показано на схеме ниже: Если вы сравните это с IP-адресами и доменными именами

  • Steve = Веб-сервер, например
  • Номер телефона = IP-адрес
  • TeamA = доменное имя
  • Билл, Джон, Фред, Джейн - серверы имен .
  • Списки - это зона или файлы зон

Уведомление У Билла нет списка игроков, кроме менеджеров, т.е. он не содержит имена хостов (записи A), а имена менеджеров (записи сервера имен NS записи ).

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

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

.

Первичная и вторичная зоны и Перенос зоны

Что происходит, когда менеджер уезжает в отпуск?

Что ж, все, что им нужно сделать, это сделать ксерокопию их списка и передать его кому-нибудь (например, Барри) и сообщить Биллу контактный номер человека, чтобы Билл мог обновить свой список.

Уведомление : В DNS всегда есть два сервера имен для обеспечения устойчивости.

На схеме ниже я изменил список Bills, включив в него Барри.

Нам также необходимо добавить примечание в список Джонса, чтобы включить Барри, поскольку он должен отправить ему список и список обновлений.

Зона может быть первичной или вторичной зоной .

Примечание: Первичные зоны теперь называются главными зонами и вторичными зонами теперь называются подчиненными зонами .

Первичная зона - это основная запись, и именно она изменяется администратором.

Для простоты только Джон может обновлять список. У него есть мастер-копия (первичная зона).

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

В DNS эти изменения копируются во вторичные зоны в процессе, называемом передачей зоны .

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

В нашей иллюстрации Барри запросил список обновлений у Джона.

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

По сути, передача зоны - это просто копия файла.

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

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

По нашей аналогии, Джон мог бы получить копию списка TeamB на случай, если Фред уйдет в отпуск.

Следовательно, DNS-сервер может быть как первичным, так и вторичным сервером имен.

Первичный и вторичный серверы имен рассматриваются как авторитетный для домена.

Зоны и домены DNS

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

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

Для того, чтобы домены совместно использовали зону и, следовательно, файл зоны , домены должны быть смежными.

Администратор домена будет отвечать за создание зон и делегирование ответственности за эти зоны администратору и DNS-серверу.

Для иллюстрации мы обратимся к диаграмме ниже, которая показывает часть системы доменных имен, которая была разделена на 3 зоны.

Следует отметить, что вы не можете создать зону, включающую поддомен 1 Домена 1 и Домен 3 , поскольку они не являются смежными.

Хранилище файлов зоны

В нашем аналоге данные хранятся в бумажном списке и хранятся у менеджера группы.

Файл зоны представляет собой текстовый файл с форматом, определенным в RFC 1035 и 1034, и хранится на сервере DNS (сервер имен).

Файлы зоны

содержат данные IP и имени, записи MX и другие служебные записи.

Они также содержат данные склеивания , которые соединяют их с другими DNS-серверами.

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

  • Какие DNS-серверы имеют данные для домена 2.
  • Какие DNS-серверы имеют данные для поддомена1 домена 3 (т. Е. Зоны 3).
  • Список корневых серверов ( корневые ссылки )
  • Список серверов пересылки (при использовании пересылки)

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

Структура файла зоны и содержание записи

Файл зоны DNS состоит из директив и записей ресурсов.

Директивы начинаются с $. Есть три Директивы

  • $ TTL - время жизни для зоны.
  • $ ORIGIN - Определяет базовое имя, используемое при подстановке доменного имени
  • $ INCLUDE - Включить файл

Директива $ TTL должна располагаться вверху файла зоны перед записью SOA .

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

Пример записи показан ниже.

Подробнее см. В этой главе книги Pro Bind и DNS.

Зона делегирования

Когда администратор домена решает передать ответственность за дочерний домен кому-то другому, например поддомен 1 домена 3. тогда они делегируют зону.

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

Мы видели это с Биллом Необходимым, чтобы узнать, у кого был список команд A.B.C.

Кэширование и TTL

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

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

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

Проблема с кэшированием данных заключается в том, что происходит, если данные изменяются, но в кеше все еще хранятся старые данные?

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

Кэширование

значительно снижает нагрузку на корневые DNS-серверы .

Зоны обратного картирования

Зоны обратного сопоставления предоставляют данные для обратного просмотра i.e IP-адрес для имени.

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

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

Следовательно, без него некоторые приложения могут работать некорректно.

Обратное сопоставление использует домены IN-ADDR.ARPA для адресов IPv4 и IP6.ARPA для адресов IPv6.

Большинство инструментов администрирования DNS автоматически создают запись обратного сопоставления при создании записи хоста.
Для получения более подробной информации см. Главу 3 книги Pro DNS and Bind.

Ссылки и ресурсы:

Связанные руководства

Оцените? И используйте Комментарии, чтобы сообщить мне больше

[Всего: 15 Среднее: 4,5 / 5] Обзор

зон и записей DNS - Azure DNS

  • Читать 12 минут

В этой статье

На этой странице объясняются ключевые концепции доменов, зон DNS, записей и наборов записей DNS, а также способы их поддержки в Azure DNS.

Доменные имена

Система доменных имен - это иерархия доменов. Иерархия начинается с «корневого» домена, имя которого просто «». '. Ниже находятся домены верхнего уровня, такие как com, net, org, uk или jp. Ниже находятся домены второго уровня, такие как org.uk или co.jp. Домены в иерархии DNS распределены по всему миру и размещаются на серверах имен DNS по всему миру.

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

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

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

DNS зоны

Зона DNS используется для размещения записей DNS для определенного домена. Чтобы начать размещать свой домен в Azure DNS, вам необходимо создать зону DNS для этого доменного имени. Каждая запись DNS для вашего домена затем создается внутри этой зоны DNS.

Например, домен contoso.com может содержать несколько записей DNS, например mail.contoso.com (для почтового сервера) и www.contoso.com (для веб-сайта).

При создании зоны DNS в Azure DNS:

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

Примечание

Вам не обязательно владеть доменным именем для создания зоны DNS с этим доменным именем в Azure DNS. Однако вам необходимо владеть доменом, чтобы настроить серверы имен Azure DNS в качестве правильных серверов имен для доменного имени с регистратором доменных имен.

Дополнительные сведения см. В разделе Делегирование домена в Azure DNS.

DNS-записи

Имена записей

В Azure DNS записи указываются с использованием относительных имен. Полное доменное имя (FQDN) включает имя зоны, а относительное имя - нет. Например, относительное имя записи www в зоне contoso.com дает полное имя записи www.contoso.com .

Запись вершина - это запись DNS в корне (или вершина ) зоны DNS.Например, в зоне DNS contoso.com запись вершины также имеет полное имя contoso.com (это иногда называется голым доменом ). По соглашению относительное имя «@» используется для представления записей вершины.

Типы записей

У каждой записи DNS есть имя и тип. Записи разбиты на различные типы в зависимости от содержащихся в них данных. Самый распространенный тип - это запись «А», которая сопоставляет имя с IPv4-адресом. Другой распространенный тип - это запись MX, которая сопоставляет имя почтовому серверу.

Azure DNS поддерживает все распространенные типы записей DNS: A, AAAA, CAA, CNAME, MX, NS, PTR, SOA, SRV и TXT. Обратите внимание, что записи SPF представлены с использованием записей TXT.

Рекордные наборы

Иногда вам нужно создать более одной записи DNS с заданным именем и типом. Например, предположим, что веб-сайт www.contoso.com размещен на двух разных IP-адресах. Веб-сайт требует две разные записи A, по одной для каждого IP-адреса. Вот пример набора рекордов:

  www.contoso.com. 3600 IN A 134.170.185.46
www.contoso.com. 3600 IN A 134.170.188.221
  

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

Например, предположим, что вы уже создали запись A «www» в зоне «contoso.com», указывающую на IP-адрес «134.170.185.46» (первая запись выше). Чтобы создать вторую запись, вы должны добавить эту запись к существующему набору записей, а не создавать дополнительный набор записей.

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

Срок службы

Время жизни, или TTL, указывает, как долго каждая запись кэшируется клиентами перед запросом. В приведенном выше примере TTL составляет 3600 секунд или 1 час.

В Azure DNS TTL указывается для набора записей, а не для каждой записи, поэтому для всех записей в этом наборе записей используется одно и то же значение. Вы можете указать любое значение TTL от 1 до 2 147 483 647 секунд.

Записи с подстановочными знаками

Azure DNS поддерживает записи с подстановочными знаками. Записи с подстановочными знаками возвращаются в ответ на любой запрос с совпадающим именем (если нет более близкого совпадения из набора записей без подстановочных знаков). Azure DNS поддерживает наборы записей с подстановочными знаками для всех типов записей, кроме NS и SOA.

Чтобы создать набор записей с подстановочными знаками, используйте имя набора записей «*». Кроме того, вы также можете использовать имя с символом «*» в качестве крайней левой метки, например, «* .foo».

Записи CAA

Записи

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

  • Флаги : это целое число от 0 до 255, используемое для представления критического флага, имеющего особое значение в соответствии с RFC
  • .
  • Тег : строка ASCII, которая может быть одной из следующих:
    • проблема : используйте это, если вы хотите указать центры сертификации, которым разрешено выдавать сертификаты (все типы)
    • issueewild : используйте это, если хотите указать центры сертификации, которым разрешено выдавать сертификаты (только сертификаты с подстановочными знаками)
    • iodef : укажите адрес электронной почты или имя хоста, на которые центры сертификации могут отправлять уведомления о неавторизованных запросах на выдачу сертификатов
  • Value : значение для конкретного выбранного тега

Записи CNAME

Наборы записей

CNAME не могут сосуществовать с другими наборами записей с таким же именем. Например, вы не можете создать набор записей CNAME с относительным именем «www» и запись A с относительным именем «www» одновременно.

Поскольку вершина зоны (name = '@') всегда содержит наборы записей NS и SOA, которые были созданы при создании зоны, вы не можете создать набор записей CNAME на вершине зоны.

Эти ограничения вытекают из стандартов DNS и не являются ограничениями Azure DNS.

NS записи

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

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

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

Записи SOA

Набор записей SOA создается автоматически на вершине каждой зоны (name = '@') и автоматически удаляется при удалении зоны. Записи SOA нельзя создавать или удалять отдельно.

Вы можете изменить все свойства записи SOA, кроме свойства host, которое предварительно настроено для ссылки на имя основного сервера имен, предоставленное Azure DNS.

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

SPF записи

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

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

Записи SPF поддерживаются Azure DNS и должны быть созданы с использованием типа записи TXT. Устаревший тип записи SPF не поддерживается. При импорте файла зоны DNS все записи SPF, использующие тип записи SPF, преобразуются в тип записи TXT.

SRV записи

Записи

SRV используются различными службами для определения расположения серверов.При указании записи SRV в Azure DNS:

  • Служба и протокол должны быть указаны как часть имени набора записей с префиксом подчеркивания. Например, _sip._tcp.name. Для записи на вершине зоны нет необходимости указывать «@» в имени записи, просто используйте службу и протокол, например, «_sip. _tcp».
  • Приоритет , вес , порт и цель указаны как параметры каждой записи в наборе записей.

TXT записей

записей TXT используются для сопоставления доменных имен с произвольными текстовыми строками. Они используются во многих приложениях, в частности, связанных с конфигурацией электронной почты, таких как Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM).

Стандарты DNS позволяют одной записи TXT содержать несколько строк, каждая из которых может иметь длину до 254 символов. Если используется несколько строк, они объединяются клиентами и обрабатываются как одна строка.

При вызове REST API Azure DNS необходимо указать каждую строку TXT отдельно. При использовании портала Azure, PowerShell или интерфейсов CLI следует указать одну строку для каждой записи, которая при необходимости автоматически разделяется на сегменты по 254 символа.

Не следует путать несколько строк в записи DNS с несколькими записями TXT в наборе записей TXT. Набор записей TXT может содержать несколько записей, каждая из которых может содержать несколько строк.Azure DNS поддерживает общую длину строки до 1024 символов в каждом наборе записей TXT (для всех записей вместе).

Теги

Теги

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

Azure DNS поддерживает использование тегов Azure Resource Manager для ресурсов зоны DNS.Он не поддерживает теги в наборах записей DNS, хотя в качестве альтернативы «метаданные» поддерживаются в наборах записей DNS, как описано ниже.

Метаданные

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

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

Azure DNS использует Etags для безопасной обработки одновременных изменений одного и того же ресурса. Etags отделены от тегов Azure Resource Manager. Каждый ресурс DNS (зона или набор записей) имеет связанный с ним Etag. Каждый раз, когда извлекается ресурс, также извлекается его Etag. При обновлении ресурса вы можете выбрать возврат Etag, чтобы Azure DNS могла проверить соответствие Etag на сервере.Поскольку каждое обновление ресурса приводит к регенерации Etag, несоответствие Etag указывает на то, что произошло одновременное изменение. Etags также можно использовать при создании нового ресурса, чтобы убедиться, что ресурс еще не существует.

По умолчанию Azure DNS PowerShell использует Etags для блокировки одновременных изменений зон и наборов записей. Дополнительный переключатель -Overwrite может использоваться для подавления проверок Etag, и в этом случае любые одновременные изменения, которые произошли, перезаписываются.

На уровне Azure DNS REST API теги Etags указываются с помощью заголовков HTTP. Их поведение представлено в следующей таблице:

Заголовок Поведение
Нет PUT всегда успешно (без проверок Etag)
Если совпадение PUT выполняется успешно, только если ресурс существует и Etag соответствует
Если соответствует * PUT завершается успешно, только если ресурс существует
Если нет * PUT завершается успешно, только если ресурс не существует

Пределы

При использовании Azure DNS применяются следующие ограничения по умолчанию:

Публичные зоны DNS

Ресурс Предел
Общедоступных зон DNS на подписку 250 1
Наборы записей для общедоступной зоны DNS 10 000 1
Количество записей на одну запись в общедоступной зоне DNS 20
Количество записей псевдонима для одного ресурса Azure 20

1 Если вам нужно увеличить эти ограничения, обратитесь в службу поддержки Azure.

Частные зоны DNS

Ресурс Предел
Частные зоны DNS на подписку 1000
Наборы записей для частной зоны DNS 25000
Количество записей в наборе записей для частных зон DNS 20
Виртуальные сетевые ссылки на частную зону DNS 1000
Ссылки виртуальных сетей на частные зоны DNS с включенной автоматической регистрацией 100
Количество частных DNS-зон, к которым может быть подключена виртуальная сеть с включенной автоматической регистрацией 1
Количество частных DNS-зон, к которым виртуальная сеть может подключиться 1000
Количество DNS-запросов, которые виртуальная машина может отправить резольверу Azure DNS, в секунду 1000 1
Максимальное количество DNS-запросов в очереди (ожидающих ответа) на виртуальную машину 200 1

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

Следующие шаги

Windows Server DNS зоны объяснения

В этом руководстве я дам краткий обзор различных типов зон DNS для Windows Server и Active Directory.

Это поможет вам лучше понять DNS и Active Directory и управлять ими.

Зоны DNS хранят информацию о ресурсных записях DNS. Вот некоторые общие записи DNS:

  • A Запись: сопоставление имени и IP-адреса
  • CNAME: сопоставляет псевдоним каноническому имени
  • MX запись: используется для идентификации почтовых серверов
  • NS Record: определяет серверы имен для определенной зоны
  • SOA: начало авторитетных записей
  • TXT: позволяет вставлять любой текст в запись DNS

Существует гораздо больше типов записей, и без этих записей все было бы доступно по IP-адресу.

Зоны

DNS предоставляют нам возможность хранить эти записи на одном или нескольких серверах.

Давайте посмотрим на различные типы зон.

Интегрированные зоны Active Directory

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

Преимущества зон, интегрированных в Active Directory

  • Репликация быстрее, безопаснее и эффективнее.
  • Лучшее резервирование благодаря копированию данных зоны на все контроллеры домена
  • Повышенная безопасность, если включено безопасное динамическое обновление
  • Нет необходимости планировать или управлять переносами зон

Первичная зона

Это основная зона, в которой имеется копия данных зоны для чтения / записи. Все изменения в зоне вносятся в первичную зону и реплицируются во вторичные зоны.

Данные зоны хранятся в текстовом файле, расположенном в этой папке c: \ windows \ system32 \ DNS на сервере Windows, на котором работает DNS.

Дополнительная зона

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

Шлейфовая зона

Тупиковые зоны похожи на дополнительную зону, но хранят только частичные данные зоны.Эти зоны полезны для уменьшения передачи зон путем передачи запросов на авторитетные серверы. Эти зоны содержат только записи SOA, NS и A.

Зона прямого просмотра

Зона прямого просмотра обеспечивает преобразование имени хоста в IP-адрес.

При доступе к системе или веб-сайту по имени хоста, например mcirosoft. com, DNS проверяет зону прямого просмотра на наличие IP-информации, связанной с именем хоста.

Зона обратного просмотра

Зоны обратного просмотра преобразуют IP-адреса в имена хостов.

Например, при поиске IP-адреса 8.8.8.8 он преобразуется в google-public-dns-a.google.com. Для преобразования IP-адреса в имя хоста необходимо было создать обратную DNS-запись.

Зоны обратного просмотра не так распространены, как переадресация, и в большинстве случаев не нужны.

Перенос зон

Передача зон происходит, если они не интегрированы с Active Directory. При передаче зоны главные DNS-серверы передают данные зоны от главного к вторичному.

Передачи зон могут происходить во время любого из следующих

  • По истечении интервала обновления
  • Когда главный сервер уведомляет об изменении
  • После перезагрузки сервера или перезапуска службы DNS
  • Произошла передача вручную с консоли DNS

Связано: Как использовать NSLookup для проверки записей DNS

Рекомендуемый инструмент: SolarWinds Server & Application Monitor

Эта утилита была разработана для мониторинга Active Directory и других важных служб, таких как DNS и DHCP. Он быстро обнаруживает проблемы с контроллером домена, предотвращает сбои репликации, отслеживает неудачные попытки входа в систему и многое другое.

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

Загрузите бесплатную пробную версию здесь

DNS-записи и типы: Руководство по основам управления DNS

Эта статья является второй из серии, посвященной основам управления DNS, Типам записей DNS.Перед тем, как продолжить эту статью, рекомендуется прочитать первую запись в этой серии «Регистраторы и серверы имен».

Зоны и записи

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

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

  • A записи
  • CNAMES
  • Записи MX
  • TXT записей
  • Записи SPF

Каждой отдельной записи DNS назначается тип и информация, необходимая для этого типа записи.

Зона DNS подобна контейнеру всех записей DNS для определенного домена и только этого домена. Например: pressable-com-clone.mystagingwebsite.com, www.pressable-com-clone.mystagingwebsite.com, blog.pressable-com-clone.mystagingwebsite.com и mail.pressable-com-clone.mystagingwebsite.com являются четыре записи DNS в одной зоне DNS для pressable-com-clone.mystagingwebsite.com.

Поддержка WordPress 24/7

от настоящих экспертов WordPress

УЗНАТЬ БОЛЬШЕ

Рекордная композиция

Как правило, для каждой записи DNS требуется как минимум три части информации:

  • Имя записи
  • Запись значения / данных
  • Время жизни (TTL)
Это образец окна ввода / редактирования DNS из панели управления GoDaddy DNS. Здесь я установил для хоста / имени значение «блог», которое будет записью DNS для blog.iamrobertv.com. В полях TTL и данных / значений также указываются время и IP, которые должны быть установлены соответственно.

Имя записи

Имя записи DNS является дескриптором и эффективным поддоменом этой записи. Если бы вы добавляли блог в свой домен, вы бы создали запись DNS и присвоили ей имя «блог». Это будет означать, что всякий раз, когда запрос пытается использовать blog.pressable-com-clone.mystagingwebsite.com, в зоне DNS запрашивается информация о записи DNS с именем «блог». Хотя вы можете присвоить записи любое имя, есть несколько особых случаев, о которых вам следует знать.

Пустое имя - Запись, у которой ничего нет в слоте имени, используется для всех запросов, сделанных к базовой / голой форме домена. Чтобы обратиться к предыдущему примеру, pressable-com-clone.mystagingwebsite.com и www.pressable-com-clone.mystagingwebsite.com - это две разные записи DNS с разными значениями для их имени. DNS-запись www.pressable-com-clone.mystagingwebsite.com использует «www» в качестве имени записи, а pressable-com-clone.mystagingwebsite.com использует ничего / blank в качестве имени записи.

@ Symbol - Некоторые системы управления DNS используют символ @ в слоте «name» вместо пустого имени. Это важно, поскольку позволяет использовать @ как значение / данные другой записи, то есть другая запись будет ссылаться на значение базовой / голой формы домена, чтобы знать, куда указывать.

Допустим, вы всегда хотели, чтобы www.pressable-com-clone.mystagingwebsite.com указывал на то же место, что и presable.com. Вы можете просто настроить их индивидуально так, чтобы они указывали на одно и то же место, и управлять ими по отдельности, но поскольку символ @ представляет базовую / голую запись DNS, вы можете установить запись www DNS-записи так, чтобы она имела значение / данные @, и она всегда будет ссылаться и использовать значение записи @ name при запросе.

Это полезно, когда несколько поддоменов / записей должны указывать на то же место, что и базовый / голый домен. Конечно, это означает, что вы должны быть абсолютно уверены в том, что изменение значения @ named записи эффективно изменяет значение любой записи, которая ссылается на нее, поэтому вам нужно будет дважды проверить любые изменения, внесенные в эту запись, чтобы увидеть, как это может влияют на другие поддомены / записи.

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

Это пример списка зон из панели управления GoDaddy DNS. Запись базового / голого домена использует здесь символ @, а запись www ссылается на символ @ для информации.Вы также можете увидеть образец записи DNS с подстановочными знаками (*) и установить TTL для этих записей на 600 секунд.

Значение записи / данные

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

В записях MX информация о значении / данных указывает, на какие почтовые серверы следует направлять электронную почту. Записи SPF используют поле значения / данных, поэтому укажите, каким серверам разрешено законно использовать ваше доменное имя для отправки электронных писем.

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

Время жизни (TTL)

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

Самое важное, что нужно знать о TTL, - это то, что любые изменения, которые вы вносите в значение / данные записи DNS, подчиняются этому TTL в отношении того, сколько времени потребуется, чтобы эта запись начала действовать.Если я изменю запись www на pressable-com-clone.mystagingwebsite.com и значение / данные TTL равно 60, то я знаю, что запись DNS начнет действовать в течение 60 секунд. Если TTL установлен на 3600, то я знаю, что для вступления в силу новой информации может потребоваться до 1 часа.

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

Последние мысли

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

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

Теги: DNS, Советы профессионалов, wordpress

Веб-производительность

Время загрузки имеет значение! Вы знаете, насколько быстро работает ваш сайт?
Пройдите наш тест, чтобы узнать.

ПРОЙТИ ТЕСТ .

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *