Введение в DNS терминологию, компоненты и концепции


Оглавление: Компьютерные сети

1. Как работают компьютерные сети

2. IP адрес

3. IPv6 адрес

4. HTTP протокол

5. Транспортные протоколы TCP и UDP

6. Канальный уровень передачи данных

7. Маршрутизация данных

8. Служебный протокол ICMP

9. DNS

9.1 Введение

9.2 Доменная терминология

9.3 Как работает DNS

9.4 Зональные файлы (Zone Files)

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

9.6 Заключение

9.7 Продолжение и дополнительный материал

9.8 Источники

10. Настройка сетевых подключений в командной строке Linux

11. Определение проблем работы сети

12. Туннелизация



Введение

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

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

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

Доменная терминология

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

Начнём с простого:

Система доменных имён (domain name system)

Система доменных имён, более известная как «DNS», является сетевой системой, которая позволяет нам преобразовывать понятные для человека имена в уникальные адреса.

Доменное имя (Domain Name)

Доменное имя — это понятное человеку имя, которое мы привыкли ассоциировать с интернет-ресурсом. Например, «google.com» - это доменное имя. Некоторые люди скажут, что часть "google" является доменом, но говоря о доменах, мы обычно под этим подразумеваем объединённую форму («google.com») в качестве имени домена.

URL «google.com» связан с серверами, принадлежащими Google Inc. Система доменных имён позволяет нам обращаться к серверам Google, когда мы вводим «google.com» в наших браузерах.

IP адрес

IP-адрес — это то, что мы называем network addressable location, то есть сетевое расположение, к которому можно обратиться по адресу. Каждый IP-адрес должен быть уникальным в своей сети. Когда мы говорим о веб-сайтах, эта сеть представляет собой весь интернет.

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

Домен верхнего уровня (Top-Level Domain)

Домен верхнего уровня, или TLD, является наиболее общей частью домена. Домен верхнего уровня — это самая дальняя часть справа (отделённая точкой). Распространёнными доменами верхнего уровня являются «com», «net», «org», «gov», «edu» и «io».

Домены верхнего уровня находятся на вершине иерархии с точки зрения доменных имён. Некоторым сторонам ICANN (Internet Corporation for Assigned Names and Numbers — Интернет-корпорация по присвоению имён и номеров) предоставляет административный контроль над доменами верхнего уровня. Эти стороны могут затем распространять доменные имена в рамках TLD, обычно через регистратора доменов.

Хосты

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

Вы можете иметь другие установленные хосты в общем домене. Вы можете получить доступ к API через хост «api» (api.example.com) или получить доступ по ftp, определив хост с именем «ftp» или «files» (ftp.example.com или files.example.com). Имена хостов могут быть произвольными, если они уникальны для домена.

Субдомен (SubDomain)

Субдомены связаны с хостами.


DNS работает в иерархии. У доменов верхнего уровня может быть много доменов. Например, в домене «com» есть и «google.com», и «ubuntu.com». Термин «субдомен» относится к любому домену, который является частью более крупного домена. В этом случае «ubuntu.com» можно назвать поддоменом «com». Обычно это называется доменом, или часть «Ubuntu» называется SLD, что означает домен второго уровня (second level domain).

Аналогично, каждый домен может управлять субдоменами следующих уровней (третьего, четвёртого и т.д.), которые находятся под ним. Именно это мы подразумеваем под поддоменами. Например, у вас может быть поддомен для исторического факультета вашей школы по адресу «www.history.school.edu». Часть «history» является поддоменом.

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

Говоря о поддоменах или хостах, вы можете начать видеть, что самые левые части домена являются наиболее специфичными. Также работает и DNS: если смотреть слева направо, то от наиболее конкретного к наименее конкретному.

Полностью определённое имя домена (Fully Qualified Domain Name)

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

Это означает, что он указывает каждый родительский домен, включая TLD. Правильное полное доменное имя заканчивается точкой, обозначающей корень иерархии DNS. Примером полного доменного имени является «mail.google.com.». Иногда программное обеспечение, которое запрашивает полное доменное имя, не требует конечной точки, но конечная точка должна соответствовать стандартам ICANN.

Сервер имён (Name Server)

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

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

Файл зоны (Zone File)

Файл зоны — это простой текстовый файл, который содержит сопоставления между доменными именами и IP-адресами. В конечном счёте именно так система DNS выясняет, какой IP-адрес следует вернуть в ответе, когда пользователь запрашивает определённое доменное имя.

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

Записи (Records)

Внутри файла зоны хранятся записи. В своей простейшей форме запись это, по сути, одно сопоставление между ресурсом и именем. Они могут сопоставить доменное имя с IP-адресом, определить серверы имён для домена, определить почтовые серверы для домена и т. д.

Как работает DNS

Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, пришло время ответить на вопрос: как на самом деле работает DNS система?

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

Корневые серверы (Root Servers)

Как мы уже говорили выше, DNS по своей сути является иерархической системой. В верхней части этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и делегируемыми полномочиями от ICANN (Интернет-корпорация по присвоению имён и номеров).

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


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

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

Таким образом, если запрос к «www.suip.biz» будет отправлен на корневой сервер, корневой сервер не найдёт результат в своих записях. Он проверит файлы своей зоны на наличие списка, который соответствует «www.suip.biz», но не найдёт ни одного.

Вместо этого он найдёт запись для TLD «biz» и даст запрашивающей организации адрес сервера имён, ответственного за адреса «biz».

TLD-серверы

Затем запрашивающая сторона отправляет новый запрос на IP-адрес (предоставленный ему корневым сервером) TLD-сервера, который отвечает за домен верхнего уровня для данного запроса.

Итак, чтобы продолжить наш пример, он отправил бы запрос серверу имён, ответственному за хранение информации о «biz», чтобы узнать, не известно ли ему, где находится «www.suip.biz».

DNS сервер TLD также будет искать «www.suip.biz» в своих файлах зоны, но не найдёт эту запись в своих файлах.

Тем не менее он найдёт запись с указанием IP-адреса сервера имён, ответственного за «suip.biz». В этом момент мы становится намного ближе к ответу, который нам нужен.

Серверы имён на уровне домена

На этом этапе запрашивающая сторона имеет IP-адрес сервера имён, который отвечает за знание фактического IP-адреса ресурса. Он отправляет новый запрос на сервер имён, снова спрашивая, может ли он разрешить (преобразовать в IP) "www.suip.biz".

Сервер имен проверяет свои файлы зон и обнаруживает, что у него есть файл зоны, связанный с "suip.biz". Внутри этого файла есть запись для хоста "www". Эта запись сообщает IP-адрес, где находится этот хост. Сервер имён возвращает окончательный ответ запрашивающей стороне.

Иллюстрация вышеописанной цепочки DNS запросов

Проиллюстрируем вышесказанное реальными запросами к DNS серверам.

Первой командой мы отправляем запрос корневому серверу d.root-servers.net об A записи доменного имени suip.biz

dig www.suip.biz @d.root-servers.net

Полученный результат:

Сервер ничего не прислал о самом доменном имени www.suip.biz, но в разделе AUTHORITY SECTION перечислены DNS сервера, которые должны знать о доменной зоне biz (доменах верхнего уровня biz):

;; AUTHORITY SECTION:
biz.			172800	IN	NS	a.gtld.biz.
biz.			172800	IN	NS	b.gtld.biz.
biz.			172800	IN	NS	c.gtld.biz.
biz.			172800	IN	NS	e.gtld.biz.
biz.			172800	IN	NS	f.gtld.biz.
biz.			172800	IN	NS	k.gtld.biz.

В дополнительном разделе присланы A записи о перечисленных выше DNS серверах:

;; ADDITIONAL SECTION:
a.gtld.biz.		172800	IN	A	156.154.124.65
b.gtld.biz.		172800	IN	A	156.154.125.65
c.gtld.biz.		172800	IN	A	156.154.127.65
e.gtld.biz.		172800	IN	A	156.154.126.65
f.gtld.biz.		172800	IN	A	209.173.58.66
k.gtld.biz.		172800	IN	A	156.154.128.65
a.gtld.biz.		172800	IN	AAAA	2001:502:ad09::30
f.gtld.biz.		172800	IN	AAAA	2001:500:3682::12
k.gtld.biz.		172800	IN	AAAA	2001:503:e239::3:2

То есть DNS сервера *.gtld.biz отвечают за домены верхнего уровня .biz. Обратимся к любому из них с запросом информации об интересующем нас домене suip.biz:

dig www.suip.biz @a.gtld.biz

Вновь мы не получили A запись для домена suip.biz, но раздел AUTHORITY SECTION содержит имена сервером имён ns1.marosnet.ru и ns2.marosnet.ru, которые указаны как сервера имён для домена suip.biz, то есть они должны уже знать IP этого сайта:

;; AUTHORITY SECTION:
suip.biz.		7200	IN	NS	ns1.marosnet.ru.
suip.biz.		7200	IN	NS	ns2.marosnet.ru.

Обращаемся с DNS запросом к любому из присланных нам серверов имён:

dig www.suip.biz @ns1.marosnet.ru

И только теперь мы действительно получили A запись с IP интересующего сайта:

Что такое разрешающий сервер имён (Resolving Name Server)?

В приведённом выше сценарии мы употребили слово «запрашивающий/запросчик». Что является «запросчиком» в этой ситуации?

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

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

Когда вы вводите URL-адрес в адресной строке вашего браузера, ваш компьютер сначала проверяет, может ли он определить локально, где находится ресурс. Он проверяет файл «hosts» на компьютере и в нескольких других местах. Затем он отправляет запрос на разрешающий сервер имён и ожидает получения IP-адреса ресурса.

Затем разрешающий сервер имён проверяет свой кеш для ответа. Если он не находит его, он проходит шаги, описанные выше.

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

Зональные файлы (Zone Files)

В упомянутом выше процессе мы упомянули идею «файлов зон» (zone files) и «записей» (records).

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

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

Чем больше файлов зон будет у сервера имён, тем на большее число запросов он сможет авторитативно ответить.

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

$ORIGIN зоны — это параметр, равный максимальному уровню полномочий (authority) зоны по умолчанию, который выражается как домен определённого уровня. То есть если для настройки домена «example.com» используется файл зоны, то $ORIGIN будет установлен на example.com..

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

Аналогично, $TTL настраивает «время жизни» предоставляемой информации. В принципе это таймер. Сервер имён кэширования может использовать ранее запрошенные результаты для ответа на вопросы, пока не истечёт значение TTL.

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

В файле зоны у нас может быть много разных типов записей. Мы рассмотрим здесь некоторые из наиболее распространённых (или обязательных типов).

Запись SOA

Запись Start of Authority (начало полномочий) или SOA, является обязательной записью во всех файлах зоны. Это должна быть первая реальная запись в файле (хотя спецификации $ORIGIN или $TTL могут отображаться выше). Она является также одной из самых сложных для понимания.

Начало SOA записи выглядит примерно так:

domain.com.  IN SOA ns1.domain.com. admin.domain.com. (
                                            12083   ; серийный номер
                                            3h      ; интервал обновления
                                            30m     ; интервал повторной попытки
                                            3w      ; период истечения
                                            1h      ; обратный TTL
)

Давайте объясним, для чего каждая часть:

  • domain.com.: это корень зоны. Он указывает, что файл зоны предназначен для домена domain.com. Часто вместо него можно увидеть @, который является просто заполнителем, который заменяется на значение переменной $ORIGIN, о которой мы узнали выше.
  • IN SOA: часть «IN» означает Интернет (и будет присутствовать во многих записях). SOA является индикатором того, что это запись Start of Authority.
  • ns1.domain.com.: определяет основной главный сервер имён для этого домена. Серверы имён могут быть как главными (master), так и подчинёнными (slaves), и если настроен динамический DNS, один сервер должен быть основным (primary master), что здесь и показано. Если вы не настроили динамический DNS, то это всего лишь один из ваших главных серверов имён.
  • admin.domain.com.: Это адрес электронной почты администратора этой зоны. В адресе электронной почты «@» заменена на точку. Если часть имени в адресе электронной почты содержит обычную точку, то в этой части она заменяется на «\» (your.name@domain.com становится your\name.domain.com).
  • 12083: это серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, вы должны увеличивать это число для правильного распространения файла зоны. Подчинённые (slave) серверы проверят, больше ли серийный номер главного сервера для зоны, чем тот, который имеется в их системе. Если это так, он запрашивает новый файл зоны, если нет, он продолжает обслуживать исходный файл.
  • 3h: Это интервал обновления для зоны. Это время, которое ведомое (slave) устройство будет ожидать перед опросом мастера на предмет изменений файла зоны.
  • 30m: Это интервал повторных попыток для этой зоны. Если ведомый (slave) не может подключиться к ведущему (master) устройству, когда период обновления истёк, он будет ждать это количество времени и повторять попытку опроса главного устройства.
  • 3w: Это срок действия. Если slave сервер имён не мог связаться с ведущим устройством в течение этого времени, он больше не возвращает ответы в качестве уполномоченного (authoritative) источника для этой зоны.
  • 1h: Это время, в течение которого сервер имён будет кэшировать ошибку имени, если он не сможет найти запрошенное имя в этом файле.

A и AAAA записи

Обе эти записи связывают хост и IP-адрес. Запись «A» используется для сопоставления хоста с IP-адресом IPv4, а записи «AAAA» используются для сопоставления хоста с адресом IPv6.


Общий формат этих записей таков:

host     IN      A       IPv4_адрес
host     IN      AAAA    IPv6_адрес

Так как наша SOA-запись вызывает основной главный сервер по адресу «ns1.domain.com», нам нужно также сопоставить его с IP-адресом, поскольку «ns1.domain.com» находится в зоне «domain.com», которая этот файл определяет.

Запись может выглядеть примерно так:

ns1     IN  A       111.222.111.222

Обратите внимание, что нам не нужно давать полное имя. Мы можем просто указать хост без полного доменного имени, а DNS-сервер заполнит остальное значением $ORIGIN. Тем не менее мы могли бы так же легко использовать полное доменное имя, если захотим быть семантическими:

ns1.domain.com.     IN  A       111.222.111.222

В большинстве случаев именно здесь вы определяете свой веб-сервер как «www»:

www     IN  A       222.222.222.222

Мы также должны указать, где разрешается базовый домен. Мы можем сделать это так:

domain.com.     IN  A       222.222.222.222

Мы могли бы использовать «@» для ссылки на базовый домен:

@       IN  A       222.222.222.222

Также у нас есть возможность использовать подстановочный символ "*", чтобы резолвить всё, что находится под управлением этого домена и что не задано явно:

*       IN  A       222.222.222.222

Все это работает так же с записями AAAA для адресов IPv6.

Записи MX

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

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

        IN  MX  10   mail.domain.com.

Обратите внимание, что в начале нет имени хоста.

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

Запись MX, как правило, должна указывать на хост, определённый с помощью записи A или AAAA, а не на хост, определённый в CNAME.

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

        IN  MX  10  mail1.domain.com.
        IN  MX  50  mail2.domain.com.
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

В этом примере хост «mail1» является предпочтительным сервером обмена электронной почтой.

Мы могли бы также написать это так:

        IN  MX  10  mail1
        IN  MX  50  mail2
mail1   IN  A       111.111.111.111
mail2   IN  A       222.222.222.222

Записи NS

Этот тип записи определяет серверы имён (name servers, NS), которые используются для этой зоны.

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

Как и записи MX, это параметры всей зоны, поэтому они также не принимают хосты. В общем, они выглядят так:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.

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

Как всегда, включите сопоставление для хостов записями A или AAAA:

        IN  NS     ns1.domain.com.
        IN  NS     ns2.domain.com.
ns1     IN  A      111.222.111.111
ns2     IN  A      123.211.111.233

Записи PTR

Используемые записи PTR определяют имя, связанное с IP-адресом. Записи PTR являются инверсией записи A или AAAA. Записи PTR уникальны тем, что они начинаются с корня .arpa и делегируются владельцам IP-адресов. Региональные интернет-реестры (Regional Internet Registries — RIR) управляют делегированием IP-адресов организациям и поставщикам услуг. Региональные интернет-реестры включают APNIC, ARIN, RIPE NCC, LACNIC и AFRINIC.

Вот пример записи PTR для 111.222.33.4:

4.33.222.111.in-addr.arpa.   33692   IN  PTR host.example.com.

В этом примере записи PTR для адреса IPv6 показан формат отрывка обратного IPv6 DNS-сервера Google 2001:4860:4860::8888.

8.8.8.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpa. 86400IN PTR google-public-dns-a.google.com.

Инструмент командной строки dig с флагом -x можно использовать для поиска обратного DNS-имени IP-адреса. Вот пример команды dig. Опция +short добавлена для сокращения вывода, который будет ограничен обратным DNS-именем.

dig -x 8.8.4.4 +short

Выходными данными для приведённой выше команды dig будет имя домена в записи PTR для IP-адреса:

google-public-dns-b.google.com.

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

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

Обычно сетевые маршрутизаторы в Интернете получают записи PTR, которые соответствуют их физическому местоположению. Например, вы можете увидеть ссылки на «NYC» или «CHI» для маршрутизатора в Нью-Йорке или Чикаго. Это полезно при запуске traceroute или mtr при анализе пути интернет-трафика.

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

Примечание. Важно, чтобы полное доменное имя в записи PTR имело соответствующую и совпадающую прямую запись A. Пример: 111.222.333.444 имеет PTR server.example.com, а server.example.com является записью A, указывающей на 111.222.333.444.

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

Записи CAA

Записи CAA используются для указания, каким центрам сертификации (CA) разрешено выдавать сертификаты SSL/TLS для вашего домена. По состоянию на 8 сентября 2017 года все центры сертификации должны проверить эти записи перед выдачей сертификата. Если запись отсутствует, любой центр сертификации может выдать сертификат. В противном случае только указанные центры сертификации могут выдавать сертификаты. Записи CAA могут применяться к отдельным хостам или целым доменам.

Ниже приведён пример записи CAA:

example.com.    IN  CAA 0 issue "letsencrypt.org"

Хост, IN и тип записи (CAA) являются общими полями DNS. Приведённая выше специфическая информация о CAA — это часть 0 issue "letsencrypt.org". Она состоит из трёх частей: флаги (0), теги (issue) и значения ("letsencrypt.org").

  • Флаги — это целое число, которое указывает, как CA должен обрабатывать теги, которые он не понимает. Если флаг равен 0, запись будет игнорироваться. Если 1, CA должен отказать в выдаче сертификата.
  • Теги — это строки, обозначающие цель записи CAA. Они могут быть следующими: issue для авторизации CA на создание сертификатов для определённого имени хоста; issuewild для авторизации сертификатов с подстановочными символами; iodef для определения URL, по которому CA может сообщать о нарушениях политики.
  • Значения — это строка, связанная с записью тэга. Для issue и issuewild это, как правило, домен CA, которому вы предоставляете разрешение. Для iodef это может быть URL-адрес контактной формы или ссылка mailto: для обратной связи по электронной почте.

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

dig example.com type257

Записи TXT

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

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

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

В 1993 RFC 1464 предложил простой подход к хранению атрибутов и их значений в этих текстовых полях. Этот тип записей сейчас широко используется в:

В качестве неструктурированного текста организации могут использовать строку TXT любым способом, который они определяют, например:

example.com   IN   TXT   "This domain name is reserved for use in documentation"

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

host.widgets.com   IN   TXT   "printer=lpr5"
sam.widgets.com    IN   TXT   "favorite drink=orange juice"

На практике сервисы, использующие записи TXT, часто не следуют этому RFC, а вместо этого имеют свой собственный специфический формат.

Пример использования DNS записи TXT - строка символов из записи TXT, используемой для SPF:

"v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"

Пример использования для DMARC:

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

Использовать для проверки сайта:

"google-site-verification=6P08Ow5E-8Q0m6vQ7FMAqAYIDprkVV8fUf_7hZ4Qvc8"

Пример Amazon's Simple Email Service:

_amazonses.example.com   IN   TXT   "pmBGN/7MjnfhTKUZ06Enqq1PeGUaOkw8lGhcfwefcHU="

Записи SRV

Запись Service (SRV) — это спецификация данных в системе доменных имён, определяющая местоположение, то есть имя хоста и номер порта, серверов для указанных служб. Он определён в RFC 2782, а его код типа - 33. Некоторые интернет-протоколы, такие как протокол инициации сеанса (SIP) и расширяемый протокол обмена сообщениями и присутствия (XMPP), часто требуют поддержки SRV сетевыми элементами.

Запись SRV имеет вид:

_служба._протокол.имя. TTL класс SRV приоритет вес порт цель.
  • услуга: символическое название желаемой услуги.
  • протокол: транспортный протокол желаемой услуги; обычно это TCP или UDP.
  • имя: доменное имя, для которого эта запись действительна, заканчивается точкой.
  • TTL: стандартное время время жизни для DNS.
  • класс: стандартное поле класса DNS (это всегда IN).
  • приоритет: приоритет целевого хоста, более низкое значение означает более предпочтительный.
  • вес: относительный вес для записей с одинаковым приоритетом, более высокое значение означает более высокий шанс быть выбранным.
  • порт: порт TCP или UDP, на котором находится служба.
  • цель: каноническое имя хоста машины, предоставляющей сервис, оканчивающееся точкой.

Пример записи SRV в текстовой форме, которая может быть найдена в файле зоны:

_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.

Это указывает на сервер с именем sipserver.example.com, прослушивающий TCP-порт 5060 для служб протокола SIP. Приоритет здесь равен 0, а вес равен 5.

Как и в MX-записях, хост в SRV-записи должен указывать на адрес (A- или AAAA-запись). Hostname-псевдоним (CNAME-запись) не может быть использован как допустимый параметр.

Записи CNAME

Запись канонического имени (Canonical Name, сокращенно CNAME) — это тип записи ресурса в системе доменных имён (DNS), которая отсылает одно доменное имя (псевдоним) на другое (каноническое имя). Записи CNAME определяют псевдоним канонического имени для вашего сервера (определённый с помощью записи A или AAAA).

Например, мы могли бы иметь запись имени A, определяющую хост «server1», а затем использовать «www» в качестве псевдонима для этого хоста:

server1     IN  A       111.111.111.111
www         IN  CNAME   server1

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

Одним из случаев, когда рекомендуется CNAME, является предоставление псевдонима для ресурса за пределами текущей зоны.

Это может оказаться удобным при запуске нескольких служб (например, FTP-сервер и веб-сервер, каждый из которых работает на разных портах) с одного IP-адреса. Можно, например, указать ftp.example.com и www.example.com на запись DNS для example.com, которая в свою очередь имеет запись A, которая указывает на IP-адрес. Затем, если IP-адрес когда-либо изменится, нужно только записать изменение в одном месте в сети: в записи DNS A для example.com.

Записи CNAME всегда должны указывать на другое доменное имя, а не на IP-адрес.

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

Например, если есть следующая зона DNS:

ИМЯ                    ТИП   ЗНАЧЕНИЕ
--------------------------------------------------
bar.example.com.        CNAME  foo.example.com.
foo.example.com.        A      192.0.2.23

когда выполняется поиск записи A для bar.example.com, распознаватель увидит запись CNAME и перезапустит проверку на foo.example.com, а затем вернет 192.0.2.23.

Записи DNAME

Запись DNAME или Delegation Name (запись имени делегирования). Запись DNAME создает псевдоним для всего поддерева дерева доменных имён. В отличие от этого, запись CNAME создаёт псевдоним для одного имени, а не его поддоменов. Как и запись CNAME, поиск DNS будет продолжен путём повторной попытки поиска с новым именем. Сервер имён синтезирует запись CNAME, чтобы фактически применить запись DNAME к запрошенному имени — CNAME для каждого узла в поддереве имеют тот же эффект, что и DNAME для всего поддерева.

Например, если есть следующая зона DNS:

foo.example.com.        DNAME  bar.example.com.
bar.example.com.        A      192.0.2.23
xyzzy.bar.example.com.  A      192.0.2.24
*.bar.example.com.      A      192.0.2.25

Поиск записи A для foo.example.com не вернёт никаких данных, поскольку DNAME не является CNAME и нет записи A непосредственно в foo.

Однако поиск для xyzzy.foo.example.com будет сопоставлен DNAME и вернёт запись A для xyzzy.bar.example.com, то есть 192.0.2.24; если запись DNAME была бы записью CNAME, этот запрос вернул бы имя не найдено.

Наконец, запрос для foobar.foo.example.com будет сопоставлен DNAME и вернёт 192.0.2.25.

Записи DS

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

RRSIG

Подпись для набора записей, защищённого DNSSEC. Использует тот же формат, что и запись SIG.

NSEC

Часть DNSSEC — используется для доказательства того, что имя не существует. Использует тот же формат, что и (устаревшая) запись NXT.

Заключение

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

Продолжение и дополнительный материал

Для продолжения знакомства с DNS рекомендуются следующие статьи:

[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]

Источники

Данный раздел написан/переведён преимущественно на основе:


Рекомендуется Вам:

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

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