какие зоны dns бывают

Энциклопедия Windows

Все об использовании и настройке Windows

Типы зон DNS

Существует два типа зон DNS: зоны прямого преобразования и зоны обратного преобразования.

Зоны прямого преобразования предназначены для преобразования имен узлов в адреса IP. Зона обратного преобразования предназначены для преобразования адресов IP в имена узлов. Зоны прямого преобразования содержат записи A, а зоны обратного преобразования содержат записи PTR.

Кроме записей А в зонах прямого преобразования принято размещать записи CNAME, MX, NS, SOA, SRV и WINS. В зонах обратного преобразования кроме записей PTR можно встретить записи WINSR.

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

Конфигурирование зоны DNS

Особенности преобразования имен DNS

Leave a Reply Cancel reply

VsDesk: cистема управления заявками для управления бизнес процессами

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

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

Продвижение сайта по ключевым словам – это комплекс мероприятий, направленный на достижение web-ресурсом высоких позиций в

Что беспокоит детей при посещении интернета

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

Источник

Давайте уже разберемся в DNS

Внимательный читатель найдет на этой картинке IPv6

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

Что такое DNS

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

Базовые штуки

Давайте взглянем на маппинг между именем и адресом:

Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

Оставшаяся часть ответа описывает сам ответ:

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

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

Другие типы

Что не так с CNAME

Запросы к другим серверам

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

Типичные ситуации

Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

Редирект домена на www

Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com :

CNAME для Heroku или Github

Wildcards

Заключение

Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

Источник

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

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-адресами. Она содержит следующую информацию:

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

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

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

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

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

Оцените эту статью. Чтобы мы могли делать лучший контент! Напишите в комментариях, что вам понравилось и не понравилось!

Рейтинг статьи: 4.7 / 5. Кол-во оценок: 12

Пока нет голосов! Будьте первым, кто оценит эту статью.

Источник

Обзор зон и записей DNS

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

Имена доменов

Система доменных имен — это иерархия доменов. Иерархия начинается с корневого домена с именем ‘ . ‘. Ниже находятся домены верхнего уровня, такие как com, net, org, uk и jp. Под этими доменами верхнего уровня расположены домены второго уровня, например org.uk и co.jp. Эти домены в иерархии DNS глобально распределены на DNS-серверах по всему миру.

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 учитывайте следующее.

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

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

Записи DNS

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

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

Типы записей

У каждой записи DNS есть имя и тип. Записи разделяются на разные типы в зависимости от данных, которые они содержат. Наиболее распространенный тип — запись A, которая сопоставляет имя с IPv4-адресом. Другой распространенный тип — запись MX, которая сопоставляет имя с почтовым сервером.

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

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

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

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

Например, предположим, что вы уже создали в зоне contoso.com запись А www, указывающую на 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.

Записи авторизации ЦС

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

Записи CNAME

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

Так как вершина зоны (имя = @) будет всегда содержать наборы записей при создании зоны, невозможно создать набор записей CNAME на вершине зоны.

Это связано со стандартами DNS, а не ограничениями Azure DNS.

Записи NS

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

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

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

Записи SOA

Набор записей SOA автоматически создается на вершине каждой зоны (имя = @) и автоматически удаляется при удалении зоны. Записи 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

Записи типа TXT

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

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

При вызове REST API Azure DNS необходимо указать каждую строку TXT отдельно. Используя портал Azure, PowerShell или интерфейс командной строки, следует указать одну строку в записи, которая при необходимости автоматически разделяется на сегменты по 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.

Теги Etag

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

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

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

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

Ограничения

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

Общедоступные зоны DNS

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

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

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

Источник