IT-зоны для доменов — .tech / .digital / .dev / .app — Джино • Журнал

С недавних пор у всех, кто занимается и интересуется современными технологиями, появилось своё собственное интернет-пространство. Создано оно было с помощью новых тематических доменных зон, предназначенных для сайтов на тему технологий, инноваций, гаджетов и не только. К ним и относятся зоны .tech, .digital, .dev и .app.

TECHнологизация

Название зоны .tech взято из первых четырёх букв слова «technologies», которое многим понятно и без перевода. Мир технологий растёт и развивается уже несколько десятилетий, но только в марте 2015 года была выделена отдельная доменная зона для сайтов соответствующей тематики.

На данный момент в ней зарегистрировано более 280 тысяч доменных имён, что для узконаправленной зоны вполне неплохо. Зона .tech больше всего популярна в странах, где проживает и работает множество успешных специалистов из области IT: Китай, США, Индия, Великобритания, Россия, Франция, Украина.

Большие корпорации обычно не торопятся регистрировать сайты в новых доменных зонах, но к .tech это точно не относится. Например, странички в этой зоне завели такие гиганты рынка технологий, как Intel и Cisco.

Но, конечно же, молодая зона .tech особенно популярна у молодых компаний: по официальным данным, за всю её историю более 15 тысяч стартапов зарегистрировали в ней свой домен. Что, возможно, отчасти помогло 170 стартапам из этого числа стать весьма успешными и привлечь суммарно более двух миллиардов долларов США в качестве венчурного капитала.

Для кого конкретно подходит эта зона? Для разработчиков программного обеспечения, производителей высокотехнологичного оборудования, сообществ гиков, интернет-магазинов с уклоном в IT, блогов с новостями о технологиях, персональных страниц программистов — возможностей у зоны .tech вполне достаточно.

Любопытный факт: именно сайт с адресом в зоне .tech победил в SEO-конкурсе Wix SEO Hero Challenge, где участники соревновались в продвижении в поисковиках. Этот факт развенчивает миф о том, что домен в новой доменной зоне не очень эффективен с точки зрения поисковой оптимизации. К слову, в зоне .tech можно получить доменное имя не только на латинице, но и на кириллице.

DIGITALизация

Схожая по тематике доменная зона с .tech, но со своими особенностями. «Digital» переводится как «цифровой», но в нашу речь уже вошло и само слово «диджитал». Под ним обычно понимают диджитал-маркетинг — продвижение товаров и услуг с помощью интернета и других цифровых средств (телевидение, радио, телефонные звонки, SMS).

Поэтому лучшей зоны для диджитал-агентств и рекламных агентств просто не найти. Особенно если в названии агентства уже есть слово «digital»: вместо адреса agency-digital.ru можно использовать более короткий и привлекательный agency.digital.

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

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

Зоны Google

Существуют две доменные зоны для сайтов IT-проектов, которыми управляет корпорация Google — .dev и .app. Некоторое время компания использовала их для своих внутренних нужд, но недавно они были открыты для свободной регистрации. И во многом благодаря поддержке Google эти зоны обрели значительную популярность.

Зарегистрировать домен в зоне . dev стало возможным с 2019 года. Её название происходит от слова «development» — «разработка». Соответственно, предназначена она для сайтов специалистов или организаций, занимающихся созданием различных IT-продуктов и технологий. Свой домен в этой зоне завели многие признанные компании, в том числе и GitHub, а всего число доменов в ней всего за год достигло 190 тысяч.

Зона .app была открыта для всеобщего использования чуть раньше, в 2018 году. В её названии использованы первые три буквы слова «application» — «приложение». Поэтому тематика у зоны .app более узкая, чем у .dev: в этом случае регистрировать доменные имена здесь рекомендуют, в первую очередь, разработчикам любого рода приложений, мобильных, десктопных или других. Также она будет актуальна и для каталогов приложений.

.app входит в топ-10 самых популярных новых зон, по данным NameStat, а доменных имён в ней насчитывается уже почти 700 тысяч. Увы, кириллицу в адресе сайта в этой зоне, как и в . dev, использовать не получится.

Брать или не брать?

Сайт в доменной зоне .tech, .digital, .dev или .app поможет подчеркнуть открытость вас и вашей организации к инновациям. К тому же с помощью домена в одной из этих тематических зон можно показать, что вы пришли в выбранную вами область всерьёз и надолго, не планируя в ближайшем будущем переключиться на кардинально иное направление. А значит, вы сможете позиционировать себя как авторитетного эксперта в своей сфере и как надёжного партнёра.

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

  • Получить домен в зоне .tech

  • Получить домен в зоне .digital

  • Получить домен в зоне .dev

  • Получить домен в зоне .app

Что такое доменная зона, виды доменных зон (ccTLD, gTLD, New gTLD) — hostgid.net

Доменная зона — правая часть полного доменного имени, обычно состоит из 1 или 2 уровней, например в «hostgid.

net«, где «net» — это доменная зона. Это общедоступный домен, в котором производится регистрация доменных имен более низкого уровня, читайте более детально о принципах работы «системы DNS». Доменные зоны классифицируются как территориальные (ccTLD — Country Code Top Level Domain) и общего назначения (gTLD — Generic Top Level Domain). Такая классификация довольно условная, в большинстве случаев регистрация доменов свободная, за использованием доменов никто не следит и документы для регистрации не нужны. Если территориальные доменные зоны (ua, ru, by, kz) кое как выполняют свое предназначение, то у доменных зон общего назначения (com, net, org) это как то не сложилось. Изначально они создавались для обозначения направления деятельности. Планировалось, что доменные имена в зоне «
com» будут регистрировать коммерческие организации, в зоне «net» организации имеющие отношение к организации работы сети (например интернет-провайдеры), в зоне «info» информационные ресурсы, а в зоне «org» другие организаций. Возможно по началу все так и было, но по мере роста количества зарегистрированных доменов все стали на это дружно

ложить

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

Доменная зона «gov« — только государственные организации. 
Доменная зона «aero» — только для организации и физические лица занятые в авиации.
Доменная зона «mil» — только военные организации США.
Доменная зона «edu» — только учебные заведения.
Доменная зона «int» — только международные организации.
Доменная зона «museum» — только для организаций и частных лиц занятых в музейной деятельности.
Доменная зона «travel» — только для организаций связанных с индустрией туризма.
Это далеко не все ограниченные доменные зоны, перечислять все не имеет смысла.
На основании таких зон, могут быть созданы территориальные доменные зоны. Например «gov.ua» или «gov.ru«, предназначены для государственных организаций Украины и России. 
Контролем над пространством доменных имен ведут две организации, ICANN и IANA. ICANN руководит всем пространством доменных имен верхнего уровня общего назначения (com, net, org). А IANA руководит всеми национальными (территориальными) доменами верхнего уровня (ua, ru, by, kz).

New gTLD

New gTLD — это новые доменные зоны, открытая регистрация в некоторых зонах началась в 2014 году, а всего планируйется создать более 1000 новых доменных зон. Небольшой экскурс в историю.
До 2001 года, существовало всего три доменные зоны первого уровня общего назначения (com, net и org). В 2001 году, ICANN ввела новые gTLD доменные зоны, расширив список зон до 22. Но на сегодняшний день и этого недостаточно. Как известно, практически все красивые имена в старых доменных зонах уже зарегистрированы. В 2012 году, ICANN начал прием заявок на открытие новых gTLD доменных зон. Подать такую заявку мог любой желающий, готовый выложить $185 000 и удовлетворяющий списку условий. Несмотря на это, желающих иметь собственную доменную зону оказалось много, около 2000. Среди них есть названия совпадающие с общеупотребимыми названиями — BLOG, PHOTP, CLUB, MENU, GURU, LIFE, LINK, MEDIA и др., совпадающие с названиями мировых брендов — GOOGLE, YANDEX, CANON и др., совпадающие с названиями территорий — AFRICA, LONDON, МОСКВА и др.

​Новые доменные зоны дают возможность зарегистрировать красивое доменное имя.

Объяснение

зон 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, Исследовательские лаборатории армии США и НАСА. Любой рекурсивный DNS-запрос (узнайте больше о типах DNS-запросов) начинается с обращения к одному из этих корневых серверов и запроса сведений для следующего уровня вниз по дереву — сервера домена верхнего уровня (TLD).


Зоны TLD

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


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

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

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


Вторичные зоны 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). A record is made up of the following fields:

name

ttl

record class

record type

record data

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

Структура файла зоны

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

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

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

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


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


    Пример файла зоны DNS
     $ORIGIN example.com. ; начало файла зоны $TTL 30m ; время истечения срока действия кэша по умолчанию для ресурса recordsexample.com. В SOA ns.example.com. root.example.com. ( 1999120701 ; серийный номер этой зоны file1d ; частота обновления вторичного DNS (d=day)1d ; частота обновления вторичного DNS в случае problem4w ; срок действия вторичного DNS (w=week)1h ; минимальное время кэширования, если разрешение failedexample.com. NS dns1.dnsprovider.com. ; есть два сервера имен, которые могут предоставлять услуги DNS, например, example. comexample.com. NS dns2.dnsprovider.com.example.com. MX 10 mx1.dnsprovider.com ; почтовый серверexample.com. MX 10 mx2.dnsprovider.comexample.com. А 192.168.100.1 ; IP-адрес для корневого домена www A 192.168.100.1 ; IP-адрес для субдомена www

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

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

    NS1 Предоставляет:
    • Управляемый DNS — служба DNS на основе высокопроизводительной глобальной сети DNS с произвольным вещанием и расширенными функциями управления трафиком.
    • Выделенный DNS — полностью управляемое развертывание DNS локально или в облаке с расширенным управлением трафиком по принципу «укажи и щелкни». технологии генерации DNS.


      Обзор

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

      • Статья
      • 12 минут на чтение

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

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

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

      Регистратор доменных имен — это организация, которая позволяет вам приобрести доменное имя, например contoso. com . Покупка доменного имени дает вам право управлять иерархией DNS под этим именем, например, позволяя вам управлять именем 9.0207 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 .

      An вершина запись — это 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-адреса. Вот пример набора записей:

       www.contoso.com. 3600 В А 134.170.185.46
www.contoso.com. 3600 В А 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, которая может быть одной из следующих:
        • проблема : если вы хотите указать центры сертификации, которым разрешено выдавать сертификаты (всех типов)
        • issuewild : если вы хотите указать ЦС, которым разрешено выдавать сертификаты (только сертификаты с подстановочными знаками)
        • iodef : укажите адрес электронной почты или имя хоста, на которые центры сертификации могут уведомлять о несанкционированных запросах на выпуск сертификатов
      • Значение : значение для выбранного тега

      Записи CNAME

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

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

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

      Записи NS

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

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

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

      Записи SOA

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

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

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

      Записи SPF

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

      В DNS RFC изначально был введен новый тип записи 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 содержать несколько строк, каждая из которых может иметь длину до 255 символов. Если используется несколько строк, они объединяются клиентами и обрабатываются как одна строка.

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

      Несколько строк в записи 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.

      Etags

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

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

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

      На уровне REST API Azure DNS 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-запросов, которое виртуальная машина может отправить на сопоставитель DNS Azure, в секунду 1000 1
      Максимальное количество DNS-запросов в очереди (ожидающих ответа) на виртуальную машину 200 1

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

      Частный преобразователь DNS 1

      Ресурс Ограничение
      Частные преобразователи DNS на подписку 15
      Входящие конечные точки на частный преобразователь DNS 5
      Исходящие конечные точки на частный преобразователь DNS 5
      Правила переадресации в соответствии с набором правил переадресации DNS 1000
      Виртуальные сетевые ссылки на набор правил переадресации DNS 500
      Исходящие конечные точки на набор правил переадресации DNS 2
      Наборы правил переадресации DNS для каждой исходящей конечной точки 2
      Целевые DNS-серверы по правилу переадресации 6
      запросов в секунду на конечную точку 10 000

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