Как правильно записывать адреса с использованием dns

Обновлено: 04.07.2024

Система доменных имен (Domain Name System) или просто DNS — важнейшая часть механизма Всемирной сети. Именно она позволяет сопоставить доменные имена веб-ресурсов с IP-адресами физических устройств, на которых они расположены.

Эту распределенную базу данных можно назвать аналогом «телефонного справочника» всего Интернета. «Телефонные номера» в ней — это IP-адреса, а «ФИО абонентов» — соответствующие им доменные имена.

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

Об основных типах DNS-записей и их назначении расскажем в данной статье.

Из чего состоит DNS-запись

В состав DNS-записи входят следующие поля:

Name/ Hostname (Имя, хост, домен — имеет несколько названий). Определяет домен, к которому относится (привязана) данная ресурсная запись.
Type (Тип). Указывает на тип (назначение) данной ресурсной записи. Наиболее распространенные типы DNS-записей — A, AAAA, MX, CNAME и TXT.
Class (Класс). Здесь указывается тип рабочей сети. Теоретически, система может работать во всех ее типах. Но, TCP/IP сети — самые распространенные. Поэтому, поле редко используется.
TTL (Time To Live) — время жизни (хранения) DNS-записи.
RDATA (Resource Data) — значение данного поля ресурсной записи зависит от ее конкретного типа.
Priority (Приоритет) — задает приоритет (очередность) обработки конкретной DNS-записи.
Protocol (Протокол)— указывает на протокол, используемый TCP, UDP, TLS.
ServiceName (Имя сервиса) — его можно посмотреть в файле /etc/services. Например: pop3, telnet.
Weight (Вес) — задает вес хоста. Обработка запросов распределяется по весу хоста.
Address (Адрес) — IP-адрес, который автоматически конвертируется в in-addr.arpa формат.

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

Распространенные типы записей

Типы DNS-записей зависят от их функционального назначения.

A-запись (Address record)

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

Пример

Hostname	Тип записи	Значение записи
eternalhost.net.	A	194.61.0.6

AAAA-запись (Address record to IPv6)

AAAA запись DNS — аналог предыдущей А-записи. В значении указывается внешний IP-адрес в формате IPv6.

Пример

Hostname	Тип записи	Значение записи
eternalhost.net.	AAAA	212:14:2127:1:211:4eef:fe10:b17

CNAME-запись (Canonical name)

CNAME («каноническое имя») указывает на расположение хостов на одном сервере. С ее помощью, можно прописать несколько доменов и поддоменов в рамках одного сервера.

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

Перед ее заполнением, надо прописать A-запись. После, можно создавать псевдонимы (их количество не ограничено).

Пример

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

MX-запись (Mail exchanger)

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

Пример

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

Пример

Host name	Тип записи	Значение записи
eternalhost.net.	A	194.61.0.6

Например, для привязки почты для домена на серверы Яндекс почты, надо указать следующие записи:

Hostname	Тип записи	Значение	Приоритет	TTL
eternalhost.net.	MX	mx.yandex.net.	10	21600

NS-запись (Name Server)

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

Пример

TXT-запись (Text String)

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

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

Пример

Hostname	Тип записи	Значение записи
eternalhost.net.	TXT	Любая текстовая запись без кавычек.

SOA-запись (Start of Authority)

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

Пример

Hostname	Тип записи	Serial number	TTL	Refresh	Retry	Expire	Minimum TTL
Контактный адрес администратора файловой зоны	SOA	1812191123	3600	7200	540	604800	86400

SRV-запись (Service record)

Указывает расположение серверов (имя хоста, № порта) для определенных сервисов. Выполняет ассоциативную роль. Например, через него можно задать:

Пример

Host name	Service Name	Protocol	Priority	Weight
eternalhost.net.	_xmpp-server	_tcp	100	0

PTR-запись (Reverse DNS)

Обратная запись DNS служит для связывания отдельного IP-адреса с доменным именем. В основном, запись используется для отправки почты с домена. Если PTR-запись совпадет с именем почтового сервера из параметра HELO (EHLO), повысится шанс миновать спам-фильтры почтовых серверов на стороне получателя письма.

Пример

Host name	Тип записи	Address
mail.eternalhost.net.	PTR	194.61.06.in-addr.arpa

DNAME-запись (Domain Name)

Запись используется для создания алиасов (псевдонимов) для всего дерева поддоменов, не затрагивая основной домен. В этом заключается отличие DNAME от CNAME-записи, которая создает псевдонимы только для одного домена, без его поддоменов.

CAA-запись (Certification Authority Authorization)

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

HINFO-запись (Host Information)

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

WKS-запись (Well Known Service)

Ассоциация hostname с конкретным портом и протоколом. Может задавать хост для обработки почты клиентов. На практике, почтовые сервисы почти никогда не запрашивают этих данных.

RP-запись (Responsible person)

Здесь прописаны реквизиты ответственных за домен. Указать можно как одного человека, так группу людей. Поле «Text Record Name» хранит Ф.И.О. ответственного работника, а поле «E-mail Address» — его электронную почту.

LOC-запись (Location information)

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

Где редактируются DNS-записи

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

Например, в ISPmanager это делается в разделе «Доменные имена». Для редактирования нужно войти в панель управления, выделить курсором нужный домен и нажать кнопку «Записи» в верхнем меню.

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

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

Имя/Хост/Псевдоним; Тип записи; Значение/Ответ/Назначение/Адрес.

Во всех вариантах «Тип записи» остается неизменным.

Имя записи

Имя записи, оно же хост/псевдоним это доменное имя, к которому принадлежит или привязана создаваемая запись.

DNS записи- типы

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

Тип записи А

Тип записи: А (address record) или (адрес Internet 4). Этот тип записи привязывает конкретное доменное имя на определенный, точный IP-адрес.

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

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

Тип записи АААА

Тип записи: AAАA (address record для IPv6) или (адрес Internet 6). Тоже. Что и тип записи А, но IP адрес имеет внешний вид по протоколу IPv6. Например: IPv6-2a03:4900:0:3::99:155

Тип записи CNAME

CNAME (каноническое имя -canonical name record). Запись типа CNAME позволяет иметь и использовать на сервере более одного имени домена (хоста).

Сначала создается одна запись типа А, для одного IP адреса. Имя домена в записи типа А, называется каноническим именем. Другие домены называют мнемонические. Мнемонические имена могут быть псевдонимами (произвольными именами) или субдоменами. Здесь пример CNAME записи:

Сервер может иметь любое количество псевдонимов. Для каждого псевдонима нужно создать запись типа CNAME.

Еще пример записи CNAME:

hosting-1 IN A 8.8.8.8

www IN CNAME hosting-1

ftp IN CNAME hosting-1

Покупаем второй IP и на второй IP переводим поддомен ftp:

hosting-1 IN A 8.8.8.8

hosting-2 IN A 8.8.8.9

www IN CNAME hosting-a

ftp IN CNAME hosting-b , переносим на второй хостинг FTP –сервер.

Еще пример записи CNAME:

hosting-1 IN A 8.8.8.8

peter IN CNAME hosting-1

oleg IN CNAME hosting-1

Следующими записями CNAME привязываем псевдонимы:

Еще пример переадресация (редирект) с помощью записи типа CNAME

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

Тип записи MX

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

В качестве почтового сервиса можно использовать сторонние почтовые сервера. Для этого вам нужно привязать свой домен к стороннему почтовому серверу. На нем вам создадут, автоматом, MX запись. Если не создадут, то дадут адрес почтового сервера. После этого вам нужно создать записи типа CNAME и MX на своем сервере.

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

Тип записи NS

Тип записи NS (сервер имён). Это, пожалуй, самый важный тип записи. Он определяет домены (адреса) DNS серверов, обслуживающих этот домен.

Тип записи TXT

TXT (текстовая запись). Это информационная запись. Она не несет функциональной нагрузки.

Запись типа SOA (Start Of Authority)

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

Далее в записи SOA указываются:

Произвольный серийный номер версии данных (Serial). При запросе вторичного сервера на обновление данных, он, прежде всего, проверяет серийный номер;
Периодичность запроса для обновления данных со стороны вторичного (Secondary) сервера (Refresh), в секундах;
Период повторного запроса вторичного сервера при первичной неудаче (Retry);
Срок действия (годности) данных (Expire), иначе истечение времени, через которое вторичный сервер перестанет обслуживать запросы, если ему не получиться восстановить связь с первичным сервером, в секундах;
И последнее, время жизни данных зоны DNS в кэше сервера (TTL), запросившего их, в секундах.

Приведу пример записи SOA, для Microsoft DNS

Как редактировать DNS записи в панели ISPManager

В панели ISPManager DNS записи редактируются на вкладке: Доменные имена→ «Клик» по домену.

Как редактировать DNS записи в панели DirectAdmin

В панели DirectAdmin DNS записи редактируются на вкладке: Управление DNS.

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

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

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

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

Зоны DNS

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

При создании зоны DNS в Azure DNS учитывайте следующее.

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

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

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

Записи DNS

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

Типы записей

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

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

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

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

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

Срок жизни

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

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

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

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

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

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

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

Flags. Это поле является целым числом от 0 до 255, которое представляет критический флаг с особым значением для каждого RFC.

Tag. Строка ASCII, которая может иметь одно из следующих значений:

issue — если необходимо указать ЦС, которые могут выпускать сертификаты (всех типов);
issuewild — если необходимо указать ЦС, которые могут выпускать сертификаты (только шаблоны);
iodef — адрес электронной почты или имя узла, по которым ЦС может отправлять уведомления о запросах на несанкционированную выдачу сертификатов.

Записи CNAME

Так как вершина зоны (имя = @) будет всегда содержать наборы записей при создании зоны, невозможно создать набор записей 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

В 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 используются для сопоставления доменных имен с произвольными текстовыми строками. Они используются в разных приложениях, в частности в тех, которые относятся к конфигурации электронной почты, например инфраструктура политики отправителей (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. В этом случае все одновременные изменения перезаписываются.

Заголовок	Поведение
None	PUT всегда завершается успешно (без проверки Etag)
If-match <etag>	PUT завершается успешно, только если ресурс существует и Etag соответствует
If-match *	PUT завершается успешно, только если ресурс существует
If-none-match*	PUT завершается успешно, только если ресурс не существует

Ограничения

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

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

Ресурс	Ограничение
Количество общедоступных зон DNS на подписку	250 1
Количество наборов записей на общедоступную зону DNS	10 000 1
Количество записей в наборе записей в общедоступной зоне DNS	20
Number of Alias records for a single Azure resource	20

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

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

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

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

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

Серверы имен

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

Серверы имен размещают информацию о домене DNS в текстовом файле, который называется файлом зоны . Они также известны как записи Start of Authority (SOA). Вы можете разместить свою информацию DNS на серверах имен в одном из нескольких мест:

Регистратор домена;
Ваш собственный DNS-сервер;
Сторонний DNS-хостинг.

DNS-записи и файлы зон

Записи DNS сопоставляют доменные имена с IP-адресами. Затем DNS-записи автоматически объединяются в файл зоны, что позволяет подключенным устройствам искать правильный IP-адрес домена. Если вы решите использовать серверы имен Linode, диспетчер DNS поможет создать файл зоны. Он содержит следующие записи:

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

Разрешение DNS

Вот как работает процесс поиска DNS:

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

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

Типы DNS-записей

A и AAAA

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

Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:

Запись AXFR используется для репликации DNS. Хотя существуют более современные способы.

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

DNS Certification Authority Authorization (CAA) использует DNS, чтобы владелец домена мог указать, каким центрам сертификации разрешено выдавать сертификаты для этого домена.

CNAME

Запись CNAME ( запись канонического имени) соответствует домену или поддомену. При записи CNAME используются разрешения DNS целевого домена в качестве разрешения псевдонима. Например:

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

Записи MX не могут ссылаться на имена хостов, определенные CNAME. Целевой домен для записи CNAME также должен иметь нормальное разрешение A-записи.

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

Запись MX устанавливает адресат доставки почты для домена или субдомена. Типичная MX-запись выглядит следующим образом:

Приоритет является еще одним компонентом MX-записей. Это число, записанное между типом записи и целевым сервером. В примере, приведенном выше, использован приоритет 10.

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

NS-записи устанавливают серверы имен для домена. Они задаются для домена у регистратора и в файле зоны. Типичные записи сервера имен выглядят следующим образом:

Серверы имен, которые вы назначаете у своего регистратора, содержат файл зоны для домена.

Также можно настроить различные серверы имен для любого из поддоменов. Они задаются в файле зоны вашего основного домена:

Запись PTR или запись указателя сопоставляет IP-адрес с доменом или поддоменом, позволяя функционировать обратным DNS-запросам. Она работает противоположно записи A, в том смысле, что позволяет искать домен, связанный с конкретным IP-адресом, а не наоборот.

Записи PTR обычно устанавливаются на хостинге. Они не являются частью файла зоны домена.

Для добавления записи PTR необходимо создать действительную запись A или AAAA, которая указывает IP-адрес для нужного домена.

Можно использовать разные IP-адреса (включая адреса IPv4 и IPv6), на которых один и тот же домен установлен для обратного DNS. Для этого необходимо настроить несколько записей A или AAAA для этого домена, которые указывают на различные IP-адреса.

Запись SOA обозначает файл зоны с именем хоста, на котором он был создан. Далее в нем указывается контактный адрес электронной почты администратора домена. Типичная запись SOA:

Адрес электронной почты администратора пишется с точкой ( . ) вместо символа @ .

Вот что означают эти цифры:

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

Сервер имен, упомянутый в записи SOA, считается основным для динамического DNS. На нем изменения файла зоны производятся до того, как они распространяются на другие серверы имен.

З апись Sender Policy Framework (SPF) содержит список почтовых серверов, назначенных для домена или субдомена. Это помогает подтвердить легитимность почтового сервера и снижает вероятность подделки заголовков писем. Спамеры часто пытаются сделать это, чтобы обойти фильтры.

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

В SPF-записи необходимо перечислить почтовые серверы, с которых вы отправляете почту, а затем исключить остальные. Ваша SPF- запись будет содержать домен или поддомен, тип (TXT или SPF, если ваш сервер имен поддерживает его) и текст (который начинается с «v = spf1» и содержит настройки SPF- записи).

Убедитесь, что SPF- записи не слишком строгие. Если вы случайно исключите легитимный почтовый сервер, полученные от него письма могут быть помечены как спам.

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

Описание элементов, которые используются в SRV-записи:

Служба : названию службы должно предшествовать подчеркивание ( _ ) и точка ( . ). Служба может быть чем-то вроде _xmpp.
Протокол : имя протокола должно начинаться с подчеркивания ( _ ) и заканчиваться точкой ( . ). Протокол может быть чем-то вроде _tcp.
Домен : имя домена, который будет получать исходный трафик для службы.
Приоритет : первое число ( 10 в приведенном выше примере) позволяет установить приоритет для целевого сервера. Можно установить цели с разными приоритетами, что позволит иметь резервный сервер (или серверы) для этой службы. Меньшие числа имеют более высокий приоритет.
Вес : Если две записи имеют одинаковый приоритет, вместо него учитывается вес.
Порт : порт TCP или UDP, на котором работает служба.
Цель : целевой домен или поддомен. Он должен иметь запись A или AAAA, которая разрешается в IP-адресе.

Примером использования SRV-записей является настройка федеративной VoIP .

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

Пожалуйста, оставляйте ваши мнения по текущей теме материала. За комментарии, дизлайки, лайки, подписки, отклики низкий вам поклон!

Читайте также: