DNS сервер BIND (теория) / Habr
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе —
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
mail.k-max.name. | | | | | | | | | +-корневой домен | | | +---домен первого уровня | | +------точка, разделяющая домены/части FQDN | +---------домен второго уровня +---------------поддомен/домен третьего уровня, возможно - имя хоста
Различие между FQDN и обычным доменным (
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
- имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
- Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
- класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
- тип (TYPE) — тип записи синтаксис и назначение записи
- данные (DATA) — различная информация, формат и синтаксис которой определяется типом.
При этом, возможно использовать следующие символы:
- ; — Вводит комментарий
- # — Также вводит комментарии (только в версии BIND 4.9)
- @ — Имя текущего домена
- ( ) — Позволяют данным занимать несколько строк
- * — Метасимвол (только в поле имя)
Со всем набором ресурсных записей можно ознакомиться в wikipedia. Наиболее часто применяемые ресурсные записи следующими (далее, мы обязательно рассмотрим их на практике):
- A — (address record/запись адреса
k-max.name. 86400 IN A 81.177.139.65
- AAAA (IPv6 address record) аналогична записи A, но для IPv6.
- CNAME (canonical name record/каноническая запись имени (псевдоним)
ftp 86400 IN CNAME www.k-max.name.
- MX (mail exchange) — указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритет и через пробел — доменное имя хоста, ответственного за прием почты
k-max.name. 17790 IN MX 10 mx.k-max.name. k-max.name. 17790 IN MX 20 mx2.k-max.name.
- NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:
name. 5772 IN NS l6.nstld.com. name. 5772 IN NS m6.nstld.com. name. 5772 IN NS c6.nstld.com. name. 5772 IN NS j6.nstld.com. ......
зону k-max.name обслуживают:k-max.name. 1577 IN NS ns2.jino.ru. k-max.name. 1577 IN NS ns1.jino.ru.
- PTR (pointer) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).
- SOA (Start of Authority/начальная запись зоны) — описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. Поле Name содержит имя домена/зоны, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами: имя главного DNS (Primary Name Server), адрес администратора зоны, далее в скобках — серийный номер файла зоны (Serial number). При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — значения таймеров (Refresh — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry — время ожидания после неудачной попытки опроса, Expire — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL — минимальное время, в течение которого данные остаются в кэше вторичного сервера). Ниже в примере приведено 2 одинаковые записи SOA (хотя вторая и записана в несколько строк), но они одинаковы по значению и формат записи второй более понятен в силу его структурированности:
k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400 k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. ( 2011032003 ; serial (серийный номер) 28800 ; refresh (обновление) 7200 ; retry (повторная попытка) 604800 ; expire (срок годности) 86400) ; minimum TTL (минимум) - SRV (server selection) — указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например Jabber и Active Directory).
Давайте рассмотрим, что есть Делегирование. Делегирование (корректнее сказать делегирование ответственности) — это операция передачи ответственности за часть дерева доменных имен (зону) другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон. Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При этом, в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны. Например, на иллюстрации корневой домен делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 5 уровней.
Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
root@DNS:~# cat /etc/nsswitch.conf ...... hosts: files dns networks: files
Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:
root@DNS:~# cat /etc/resolv.conf nameserver 192.168.1.1 nameserver 192.168.1.2 domain examle.com
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
Обычно, провайдер выдает в локальной сети стоит DNS-сервер, обрабатывающий рекурсивные запросы, а так же, скорее всего, он настроен на кэширование запросов, что экономит трафик и снижает нагрузку на сеть. Схему взаимодействия клиента и DNS серверов можно представить следующей картинкой:
Давайте разберем, что тут нарисовано по шагам:
- Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
- Резолвер посылает запрос указанному серверу имен.
- Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
- Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
- Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
- пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
- и «вложенности» доменных имен.
- В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
- Сервер
провайдералокальной сети возвращает резолверу клиента запрошенные данные.
Обычно, количество шагов сокращено до минимума, т.к. на пути прохождения запросов встречается кэширующий сервер, который хранит необходимую информацию в кэше. В данной схеме может возникнуть вопрос: каким образом локальный DNS сервер, получивший рекурсивный запрос от резолвера, выбирает DNS-сервер из списка авторитативных? Существует множество корневых DNS-серверов в сети Интернет, какому из корневых серверов наш DNS-сервер отправит запрос?
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
Ответы DNS бывают следующего типа:
- Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
- Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
Ответ DNS обычно содержит следующую информацию:
- Запись заголовка — служебную информацию о запросе.
- Запись запроса — повторяет отправленный запрос.
- Запись ответа — собственно, сам ответ.
- Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
- Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Вышенаписанное наглядно подтверждается утилитой dig:
root@DNS:~# dig ya.ru ; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3 ;; QUESTION SECTION: (раздел запроса) ;ya.ru. IN A ;; ANSWER SECTION: (раздел ответа) ya.ru. 4813 IN A 87.250.250.203 ya.ru. 4813 IN A 87.250.251.3 ya.ru. 4813 IN A 93.158.134.3 ya.ru. 4813 IN A 93.158.134.203 ya.ru. 4813 IN A 213.180.204.3 ya.ru. 4813 IN A 77.88.21.3 ya.ru. 4813 IN A 87.250.250.3 ;; AUTHORITY SECTION: (авторитативные сервера) ya.ru. 4813 IN NS ns1.yandex.ru. ya.ru. 4813 IN NS ns5.yandex.ru. ;; ADDITIONAL SECTION: (дополнительная информация - адреса авторитативных name servers) ns5.yandex.ru. 345565 IN A 213.180.204.1 ns1.yandex.ru. 345565 IN A 213.180.193.1 ns1.yandex.ru. 3565 IN AAAA 2a02:6b8::1 ;; Query time: 7 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sat Jul 2 23:02:45 2011 ;; MSG SIZE rcvd: 238
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Наглядно приведенную схему можно представить командами:
[root@DNS~]# dig www.ru ... ;; QUESTION SECTION: ;www.ru IN A ;; ANSWER SECTION: www.ru 52119 IN A 194.87.0.50 ... [root@DNS~]# dig -x 194.87.0.50 ... ;; QUESTION SECTION: ;50.0.87.194.in-addr.arpa. IN PTR ;; ANSWER SECTION: 50.0.87.194.in-addr.arpa. 30385 IN PTR www.ru ....
При этом, команду dig -x 194.87.0.50 правильнее будет представить как dig 50.0.87.194.in-addr.arpa., то есть записи в поддоменах *.in-addr.arpa. представлены в так называемой обратной нотации (или reverse форме), то есть хосту с IP 194.87.0.50 будет соответствовать PTR-запись, имеющая FQDN 50.0.87.194.in-addr.arpa., которая в свою очередь указывает на домен www.ru Хочется отметить, что чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.
Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины www.ru. будет иметь такой вид:
50.0.87.194 IN PTR www.ru
Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно «www.ru». Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:
80 IN PTR www.ru
Регистрация доменных имен
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистрация доменов — это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:
- корневой домен
- все домены первого уровня (TLD)
- некоторые домены второго уровня (например, com.ru или co.uk)
Регистратором для корневого домена является организация ICANN. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs …), необходимо получить аккредитацию ICANN.
Правила регистрации в международных (gTLD — com., org, и др.) доменах устанавливаются ICANN. Правила регистрации в национальных (ccTLD — ru, us и др.) доменах устанавливаются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и.рф задаются Координационным центром национального домена сети Интернет. Для многих доменов (в том числе и для ru) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.
Услуга регистрации домена в большинстве случаев платная, цену и условия регистрации определяет регистратор. Для регистрации домена, необходимо выбрать свободное имя и отправить заявку на регистрацию у одного из регистраторов (например nic.ru), оплатить предоставление услуги. После подтверждения регистрации, необходимо в интерфейсе регистратора определить (делегировать) dns сервера, скорее всего это будут DNS вашего хостера.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Резюме
Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.
Что еще почитать:
man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname: http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: скачать.
RFC882, 1035, 1183
Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.
habr.com
Как работает DNS (domain name system)?
Что такое DNS
DNS (domain name system) — это система, обеспечивающая работу привычных нам доменных имен сайтов. Связь между устройствами в сети Интернет осуществляется по IP адресам, например: «192.64.147.209». Однако, запомнить IP адреса сложно, поэтому были придуманы удобные для человека доменные имена, например: «google.com».
Компьютер / сервер не хранит таблицу соответствия доменов и их IP адресов. Точнее, не хранит всю таблицу, а временно запоминает данные для часто используемых доменов. Когда в браузере вводится домен сайта, компьютер автоматически узнает его IP адрес, и отправляет по нему запрос. Этот процесс называется «разрешение адреса домена» (domain resolving).
Разберемся, из чего состоит система DNS, и как она работает.
Как работает DNS
Система доменных имен состоит из следующих компонентов:
Иерархическая структура доменных имен:
- Доменные зоны верхнего уровня (первого уровня) – например: «ru», «com», или «org». Они включают в себя все доменные имена, входящие в эту зону. В любую доменную зону может входить неограниченное количество доменов.
- Доменные имена (доменные зоны второго уровня) – например: «google.com» или «yandex.ru». Т.к. система доменных имен является иерархичной, то «yandex.ru» можно также назвать поддоменом вышестоящей зоны «ru». Поэтому, правильнее указывать именно уровень домена. Однако, на практике, доменную зону любого уровня называют просто «доменом».
- Поддомены (доменные зоны третьего уровня) – например: «api.google.com» или «mail.yandex.ru». Могут быть доменные зоны 4, 5 уровней и так далее.
Обратите внимание, что «www.gооgle.com» и «google.com» — это, фактически, разные домены. Надо не забывать указывать А-записи для каждого из них.
DNS сервер или NS (name server) сервер – поддерживает (обслуживает) доменные зоны, которые ему делегированы. Он непосредственно хранит данные о ресурсных записях для зоны. Например, что сервер, на котором находится сайт «example.ru», имеет IP адрес «1.1.1.1». DNS сервер отвечает на все запросы, касательной этих доменных зон. Если ему приходит запрос о домене, который ему не делегирован, то он спрашивает ответ у других DNS серверов.
DNS записи (ресурсные записи) – это набор записей о доменной зоне на NS сервере, которые хранят данные необходимые для работы DNS. На основании данных в этих записях, DNS сервер отвечает на запросы по домену. Список записей, и их значение, вы можете найти ниже.
Корневые DNS сервера (на данный момент их 13 во всем мире) хранят данные о том, какие DNS сервера обслуживают зоны верхнего уровня.
DNS сервера доменных зон верхнего уровня — хранят информацию, какие NS сервера обслуживают тот или иной домен.
Для того, чтобы узнать IP адрес, домена компьютер / сервер обращается к DNS-серверу, который указан у него в сетевых настройках. Обычно, это DNS сервер Интернет провайдера. DNS сервер проверяет делегирован домен ему или нет. Если да, то сразу отвечает на запрос. Если нет, то запрашивает информацию о DNS сервере, обслуживающем этот домен, у корневого сервера, и затем у сервера доменных зон верхнего уровня. После этого, непосредственно делает запрос на NS сервер, обслуживающий этот домен, и транслирует ответ вашему компьютеру / серверу.
Кэширование данных используется на всех устройствах (компьютерах, северах, DNS серверах). То есть, они запоминают ответы на последние пришедшие к ним запросы. И когда приходит аналогичный запрос, они просто отвечают то же самое, что и в предыдущий раз. Например, если вы в браузере открыли сайт google.com первый раз после включения, то компьютер сделает DNS запрос, а при последующих запросах будет брать данные, которые ему были присланы DNS сервером в первый раз. Таким образом, для популярных запросов не надо каждый раз проходить всю цепочку и генерировать запросы к NS серверам. Это значительно снижает нагрузку на них, и увеличивает скорость работы. Однако, как результат, обновление данных в системе DNS происходит не сразу. При изменении IP адреса домена, информацию об этом будет расходиться по сети Интернет от 1 до 24 часов.
Регистрация/выделение доменов
У каждой доменной зоны первого уровня есть своя организация, которая устанавливает правила выделения доменов и обеспечивает работу этой зоны. Например, для доменных зон RU, SU и РФ – это Координационный центр национального домена сети Интернет https://cctld.ru. Эти организации устанавливают правила работы и технические требования к регистраторам доменов.
Регистраторы доменов – это компании, которые непосредственно регистрируют новые домены в рамках доменной зоны первого уровня для конечных клиентов. Организуют техническое взаимодействие с реестром доменных имен. В их личном кабинете владелец домена настраивает, какой DNS сервер будет поддерживать домен.
Администратор домена (владелец) – лицо, которому непосредственно принадлежат права на доменное имя. Он может управлять доменом, от него регистратор принимает заявки на внесение изменений.
Делегирование домена – указание для него DNS серверов, которые будут его обслуживать.
Основные DNS записи
Существуют следующие основные DNS (ресурсные) записи:
А – содержит информацию об IPv4 адресе хоста (сервера) для домена. Например, 1.1.1.1.
ААА – содержит информацию об IPv6 адресе хоста (сервера) для домена. Например, 2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d.
MX – содержит данные о почтовом сервере домена. При этом указывается именно имя почтового сервера, например mail.example.com. Т.к. у домена может быть несколько почтовых серверов, то для каждого из них указывает приоритет. Приоритет задается числом от 0 до 65535. При этом «0» — это самый высокий приоритет. Принято по умолчанию для первого почтового сервера указывать приоритет «10».
TXT – дополнительная информация о домене в виде произвольного текста. Максимальная длина 255 символов.
SRV – содержит информацию об имени хоста и номере порта, для определенных служб / протоколов в соответствии с RFC 2782 http://www.rfc-editor.org/rfc/rfc2782.txt. Содержит следующие поля:
- _Service._Proto.Name ( Пример: _jabber._tcp.jabber ), где:
- Service: название службы (пример: ldap, kerberos, gc и другие).
- Proto: протокол, при помощи которого клиенты могут подключиться к данной службе (пример: tcp, udp).
- Name: имя домена, в котором размещена данная служба.
- Приоритет – также как для MX записи указывает приоритет для данного сервера. Задается числом от 0 до 65535. При этом «0» — это самый высокий приоритет.
- Вес – Относительный вес для распределения нагрузки между серверами с одинаковым приоритетом. Задается целым числом.
- Порт – номер порта, на котором располагается служба на данном сервере.
- Назначение — доменное имя сервера, предоставляющего данную службу.
NS – имя DNS сервера, поддерживающего данный домен.
CNAME (каноническое имя хоста / canonical name) – используется для перенаправления на другое доменное имя. Например, имя сервера изменилось с example.com на new.com. В таком случае в поле «Alies» для записи cname надо указать — example.com, а в поле «Canonical name» — new.com. Таким образом, все запросы на example.com автоматически будут перенаправлены на new.com.
SOA – базовая запись о домене. В ней хранится само имя домена и время жизни данных о домене — TTL. TTL (time-to-live) определяет какой период времени DNS сервер получив информацию о зоне будет хранить ее у себя в памяти (кэшировать). Рекомендуемое значение 86400 – 1 день. Значение указывается в секундах.
neoserver.ru
Что такое DNS-сервер и для чего он нужен?
480 auto
Если спросить среднего пользователя интернета, что такое сайт, скорее всего, он назовёт, например, yandex.ru, mail.ru, google.com, facebook.com, …
В практическом смысле этого вполне достаточно: нашёл интересный сайт, сообщил знакомым его доменное имя (или проще, «адрес»).
Однако настоящим адресом доменное имя не является. Ну это примерно так же, как отправить письмо с надписью на конверте: «город Екатеринбург, Петру Иванову». Здесь дело даже не в том, что Петров Ивановых в Екатеринбурге может быть несколько (представим, что человек с таким именем там единственный). Проблема в том, что адресат может перемещаться, минимум, по городу, и вручить ему письмо будет крайне проблематично.
Но письма-то доставляют и получают! — Да, конечно. Потому что они отправляют по почтовым адресам. Например, «город Ленинград, 3-я улица Строителей, дом 25, квартира 12».
Почтовым адресом в интернете является IP-адрес, состоящий из четырёх чисел от 0 до 255, например, 74.125.131.100. Это — один из IP-адресов сайта google.com. Если в адресной строке вашего браузера ввести эти числа, вы окажетесь на портале google.com, точнее, на google.ru, куда вас автоматически перенаправят.
Почему «один из адресов», и какого типа бывают IP-адреса, пока оставим в стороне.
В интернете IP-адрес задаёт, на какой компьютер нужно доставить данные.
Вам что-то напоминает IP-адрес? — Мне он напоминает длинный номер мобильного телефона.
Телефонная книга
К сожалению, запоминать длинные телефонные номера непросто. Мы их вносим в свои записные книжки («контакты», по-мобильнофонному) и добавляем к ним понятные имена, например,
Пётр Иванов, +7-343-123-45-67.
В дальнейшем нам не потребуется помнить сам телефонный номер Петра, достаточно того, что этот номер записан в нашу телефонную книгу. Когда нам будет нужно позвонить Петру, мы найдём его в списке наших контактов даже не взглянув на его номер.
В интернете роль телефонной книги играет система доменных имён (DNS, Domain Name System). В ней хранится связь между относительно легко запоминаемым названием сайта и его трудно запоминаемым числовым адресом.
Правда, есть одно существенное отличие этой «интернет-книги» от телефонной. — Её ведёт не каждый знакомый Петра Иванова в отдельности, а он сам.
В частной телефонной книге можно написать: «Петя», «Пётр», «Петруша», «Петруха», «Петруня», «любимый», …, а в «телефонной интернет-книге» записи ведут сами владельцы сайтов, например:
| Название домена | Адрес |
| pyotr-ivanov.ru | 123.123.123.123 |
Если кто-то пожелает посетить сайт Петра Иванова, в адресной строке браузера он наберёт: pyotr-ivanov.ru, а система доменных имён сообщит браузеру (точнее, компьютеру, на котором работает браузер), соответствующий IP-адрес, в нашем примере: 123.123.123.123. Компьютер, который находится по этому адресу, обработает запрос браузера и пришлёт ему данные, для отображения запрошенной страницы веб-сайта.
Теперь понятно, как используются доменные имена? — Однако ещё не рассказано, где хранятся записи о связях между доменными именами сайтов и IP-адресами компьютеров, на которых эти сайты размещены.
DNS-сервер
Он-то и служит телефонной книгой. Он хранит информацию о том, какому IP-адресу соответствует то или иное доменное имя. В интернете DNS-серверов очень много. У них двойная роль:
- главная — «телефонная интернет-книга»;
- дополнительная (но тоже важная) — кэширование записей других DNS-серверов.
Сначала несколько слов о кэшировании. Выяснять связь между названием сайта и его IP-адресом требуется при каждом обращении к этому веб-сайту. Если сайт, который вы хотите посетить, находится достаточно далеко, многочисленные запросы к далёкому первичному DNS-серверу могут отнять много времени и замедлить загрузку веб-страниц. Чтобы избежать задержек, ближайший к вашему компьютеру DNS-сервер (обычно находящийся у вашего интернет-провайдера), сохраняет сведения о ранее запрошенных IP-адресах, и при повторном обращении к тому же сайту он сообщит его адрес очень быстро, так как будет хранить его в своём кэше.
Но чтобы что-то кэшировать, нужно иметь источник кэшируемого. Таким источником служат первичные DNS-сервера, хранящие изначальные связи между доменами и их IP-адресами.
Для регистрации доменного имени достаточно его придумать. Но для того, чтобы оно начало «работать», вы должны сообщить регистратору доменное имя DNS-сервера, который будет хранить подробные данные о регистрируемом вами домене. Об этих данных будет сказано чуть позже.
Обычно используют два DNS-сервера: первичный и вторичный. Но их может быть и больше. Большее число DNS-серверов повышает надёжность доступа к вашему домену: если один окажется недоступен, ответит другой.
В реальном мире двух — вполне достаточно.
Многие регистраторы доменных имён и просто интернет-провайдеры предлагают использовать свои DNS-серверы в режиме платной услуги.
Хорошая новость: в облаке 1cloud услугу DNS-хостинга можно получить бесплатно! Достаточно быть клиентом этого публичного облака.
DNS-зона
Для дальнейшего понимания системы доменных имён нужно узнать, что такое DNS-зона.
Дело в том, что мы рассмотрели только один из вариантов связи между доменным именем и IP-адресом: один домен – один сайт – один адрес. Однако с конкретным доменным именем может быть связан не только веб-сайт, но и, например, почтовый сервер. И у них могут быть разные адреса.
Одному и тому же домену может соответствовать веб-сайт или почтовый сервер с несколькими IP-адресами, каждый. Их используют для повышения надёжности и производительности сайта или почтовой системы.
А ещё нужно вспомнить о возможных поддоменах, например,
mail.company.ru, ftp.company.ru, sklad.company.ru, …
Все необходимые связи между доменным именем и IP-адресами отражаются в специальном файле, расположенном на DNS-сервере. Содержимое этого файла называется описанием DNS-зоны, или просто DNS-зоной.
В ней могут присутствовать записи разных типов.
| Тип записи | Пояснение |
| A | Адрес «сайта» соответствующего доменного имени |
| MX | Адрес почтового сервера в соответствующем домене |
| CNAME | Синоним описываемого домена. Например, здесь можно указать, что доменное имя www.company.ru является синонимом доменного имени company.ru, и запросы по этому синониму будут перенаправляться на адрес основного доменного имени |
| NS | Здесь указывается доменные имена DNS-серверов, обслуживающих описываемый домен. Например, ns1.1cloud.ru и ns2.1cloud.ru |
| TXT | Любое текстовое примечание |
Это — не полный перечень возможных типов полей. Он был сокращён для упрощения ознакомительного изложения.
Дополнение
Как в любом деле, в правильном описании доменного имени есть свои детали и нюансы. В этой статье они опущены, чтобы не усложнять начальное знакомство с темой. Однако для общего кругозора уже сейчас следует добавить несколько важных фактов.
- Выше была описана адресация по стандарту IPv4. Адрес в нём состоит из четырёх чисел. Такая адресация имеет ограничение числа обслуживаемых компьютеров: 4 294 967 296. Это много, но при нынешнем числе устройств, подключенных к интернету адресов стало не хватать.
Для преодоления этого объективного лимита ввели новый стандарт: IPv6, по которому длина адреса увеличилась, и стало возможным адресовать намного, намного больше компьютеров. В DNS-зоне тип записи для такого адреса обозначается: AAAA. - Одному домену могут соответствовать несколько IP-адресов.
Обычно такое назначение делается для повышения надёжности или быстродействия. Порядок выдачи IP-адреса из списка на запрос по доменному имени зависит от настроек DNS-сервера. Чаще всего адрес выдаётся в случайном порядке. - Одному IP-адресу может соответствовать несколько доменов.
Строго говоря, это противоречит логике системы доменных имён, которая предполагает однозначную связь IP-адреса с соответствующим доменом. Однако, как было сказано ранее, 4-числовой IP-адрес стал дефицитным ресурсом, который уже достаточно давно стараются экономить.
На практике такая экономия может выглядеть следующим образом. На компьютере размещают несколько не очень больших веб-сайтов с разными доменными именами, которым присвоен одинаковый IP-адрес. Веб-сервер, работающий на этом компьютере и обслуживающий эти сайты, получив запрос, анализирует домен, в который он пришёл, и направляет его на правильный сайт.
Такая практика не позволяет обеспечить однозначность обратной связи IP-адреса с доменным именем, ведь в этом случае их несколько. Но позволяет экономить IP-адреса.
Заключение
Изложенный порядок на первый взгляд может показаться сложным. Однако он позволяет:
- пользоваться доменными именами, которые запоминаются легче, чем числовые адреса;
- повышать надёжность доступа к интернет-ресурсам путём использования для них нескольких компьютеров, разнесённых по сети;
- увеличивать производительность интернет-ресурсов за счёт распределения нагрузки внутри группы обеспечивающих компьютеров;
- перемещать прикладные компьютеры по интернету, не меняя их доменного адреса.
С учётом изложенного в этой статье, определим DNS кратко так.
DNS (Domain Name System) — это система доменных имён, которая связывает названия доменов с IP-адресами компьютеров, соответствующих этим доменам. Эта система включает в себя как регламентирующие документы, так множество DNS-серверов, работающих в интернете и сообщающих IP-адреса в ответ на запрос по доменным именам.
P.S. Еще немного материалов по теме DNS:
1cloud.ru
Давайте уже разберемся в DNS / Habr
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com, и получает в ответ 1.2.3.4.
Базовые штуки
Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net, который хостится на машине web01.bugsplat.info. Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, — прим. пер.).
Давайте взглянем на маппинг между именем и адресом:
$ dig web01.bugsplat.info
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
;; QUESTION SECTION:
;web01.bugsplat.info. IN A
dig по-умолчанию запрашивает A-записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4-адрес. Есть эквивалент для IPv6-адресов — AAAA. Давайте взглянем на ответ:
;; ANSWER SECTION:
web01.bugsplat.info. 300 IN A 192.241.250.244
Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A: 192.241.250.244. Число 300 это TTL, или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet. Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA’s DNS Parameters.
Оставшаяся часть ответа описывает сам ответ:
;; Query time: 20 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:01:16 2013
;; MSG SIZE rcvd: 56
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53, DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig‘у, если бы информация не был закэширована:
$ dig +trace web01.bugsplat.info
; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info
;; global options: +cmd
. 137375 IN NS l.root-servers.net.
. 137375 IN NS m.root-servers.net.
. 137375 IN NS a.root-servers.net.
. 137375 IN NS b.root-servers.net.
. 137375 IN NS c.root-servers.net.
. 137375 IN NS d.root-servers.net.
. 137375 IN NS e.root-servers.net.
. 137375 IN NS f.root-servers.net.
. 137375 IN NS g.root-servers.net.
. 137375 IN NS h.root-servers.net.
. 137375 IN NS i.root-servers.net.
. 137375 IN NS j.root-servers.net.
. 137375 IN NS k.root-servers.net.
;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms
info. 172800 IN NS c0.info.afilias-nst.info.
info. 172800 IN NS a2.info.afilias-nst.info.
info. 172800 IN NS d0.info.afilias-nst.org.
info. 172800 IN NS b2.info.afilias-nst.org.
info. 172800 IN NS b0.info.afilias-nst.org.
info. 172800 IN NS a0.info.afilias-nst.info.
;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms
bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org.
bugsplat.info. 86400 IN NS ns-212.awsdns-26.com.
bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk.
bugsplat.info. 86400 IN NS ns-911.awsdns-49.net.
;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms
web01.bugsplat.info. 300 IN A 192.241.250.244
bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org.
bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk.
bugsplat.info. 172800 IN NS ns-212.awsdns-26.com.
bugsplat.info. 172800 IN NS ns-911.awsdns-49.net.
;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms
Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info? Так вот, точка . это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS-записи. NS-запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS-записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A-запись для web01.bugsplat.info. Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!
$ dig -x 192.5.5.241
; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;241.5.5.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR, которая соединяет IP и хост, в данном случае — f.root-servers.net.
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS-серверов. Он отвечает за домен верхнего уровня info. dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info, и получает в ответ еще один набор NS-серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info.. И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com, net, org, и т.д. тоже обычно сильно закэшированы.
Другие типы
Есть еще несколько типов, о которых стоит знать. Первый это MX. Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:
$ dig petekeen.net mx
; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;petekeen.net. IN MX
;; ANSWER SECTION:
petekeen.net. 86400 IN MX 60 web01.bugsplat.info.
;; Query time: 272 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:33:43 2013
;; MSG SIZE rcvd: 93Заметьте, что MX-запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME. Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
$ dig www.petekeen.net
; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.petekeen.net. IN A
;; ANSWER SECTION:
www.petekeen.net. 86400 IN CNAME web01.bugsplat.info.
web01.bugsplat.info. 300 IN A 192.241.250.244
;; Query time: 63 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:36:58 2013
;; MSG SIZE rcvd: 86Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info. Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX, ни A, ни NS, ничего.
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME, также валидны для CNAME. В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net, потому что обычно там нужны другие записи, например, MX.
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
$ dig www.petekeen.net @8.8.8.8Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2.
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com. Регистраторы типа Namecheap или DNSimple называют это URL Redirect. Вот пример из админки Namecheap:
Символ @ означает корневой домен iskettlemanstillopen.com. Давайте посмотрим на запись A у этого домена:
$ dig iskettlemanstillopen.com
;; QUESTION SECTION:
;iskettlemanstillopen.com. IN A
;; ANSWER SECTION:
iskettlemanstillopen.com. 500 IN A 192.64.119.118
Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:
$ curl -I iskettlemanstillopen.com
curl -I iskettlemanstillopen.com
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 19 Jul 2013 23:53:21 GMT
Content-Type: text/html
Connection: keep-alive
Content-Length: 154
Location: http://www.iskettlemanstillopen.com/
CNAME для Heroku или Github
Взгляните на скриншот выше. На второй строке там CNAME. В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.
$ heroku domains
=== warm-journey-3906 Domain Names
warm-journey-3906.herokuapp.com
www.iskettlemanstillopen.com
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME. См. документацию.
Wildcards
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info. Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
$ dig randomapp.web01.bugsplat.info
;; QUESTION SECTION:
;randomapp.web01.bugsplat.info. IN A
;; ANSWER SECTION:
randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info.
web01.bugsplat.info. 15 IN A 192.241.250.244
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
habr.com
Введение в терминологию, элементы и понятия DNS – База знаний Timeweb Community
Введение
DNS, или система доменных имен, зачастую очень трудная часть изучения настройки веб-сайтов и серверов. Понимание того, как работает DNS, поможет вам диагностировать проблемы с настройкой доступа к вашим веб-сайтам и позволит расширить понимание того, что происходит за кадром.
В этом руководстве мы обсудим некоторые фундаментальные понятия системы доменных имен, которые помогут вам разобраться с настройкой вашей DNS. После знакомства с этим руководством вы научитесь настраивать собственное доменное имя или свой собственный DNS-сервер.
Прежде чем мы приступим к настройке серверов для преобразования вашего домена или настройке наших доменов в панели управления, давайте познакомимся с некоторыми основными понятиями о работе DNS.
Терминология доменов
Мы должны начать с определения терминов. Хотя некоторые из этих тем могут быть вам знакомы из других сфер, есть много других терминов, используемых в разговоре о доменных именах и DNS, которые не слишком часто используются в других компьютерных областях. Давайте начнем с простого:
Система доменных имен
Система доменных имен, более известная как «DNS», является сетевой системой, которая позволяет нам преобразовать удобные для человека имена (обычно буквенные) в уникальные адреса.
Доменное имя
Доменное имя это удобная для человека форма имени, которую мы привыкли ассоциировать с интернет-ресурсом. Например, «google.com» является доменным именем. Некоторые скажут, что часть «Google» является доменом, но в целом мы можем считать эту комбинированную форму доменным именем.
URL-адрес «google.com» соединен с сервером, находящимся в собственности Google Inc. Система доменных имен позволяет нам соединиться с сервером Google при вводе «google.com» в браузере.
IP-адрес
IP-адресом мы называем сетевой адрес узла. Каждый IP-адрес должен быть уникальным в пределах своей сети. Когда мы говорим о веб-сайтах, этой сетью является весь интернет.
IPv4, наиболее распространенная форма адресов, записывается в виде четырех наборов цифр, каждый набор содержит до трех цифр, разделенных точкой. Например, «111.222.111.222» может считаться правильным IPv4 IP-адресом. С помощью DNS мы соединяем имя с этим адресом и избавляем себя от необходимости запоминать сложный набор цифр для каждого места посещения в сети.
Домен верхнего уровня
Домен верхнего уровня, или TLD, это самая общая часть домена. Является последней частью доменного имени справа (отделен точкой). Распространенными доменами верхнего уровня считаются «com», «net», «org», «gov», «edu» и «io».
Домены верхнего уровня находятся на вершине иерархии доменных имен. Некоторым компаниям предоставлен контроль над управлением доменами верхнего уровня структурой ICANN (Корпорация по управлению доменными именами и IP-адресами). Эти компании также могут распространять доменные имена под TLD, как правило, через доменного регистратора.
Узел
В пределах домена его владелец может определять собственные узлы, которые ссылаются на отдельные компьютеры или услуги, доступные через домен. Например, большинство владельцев доменов делают свой веб-сервер доступным через корневой домен (example.com), а также через «узел», определенный как «www» (www.example.com).
У вас могут быть другие определения узлов под общим доменом. Вы можете иметь API доступ через «api» узел (api.example.com) или FTP доступ, обозначив узел «FTP» или «files» (ftp.example.com или files.example.com). Имена узлов могут быть произвольными, при условии, что они являются уникальными для данного домена.
Поддомен
Объект, связанный с узлами, называется поддомен.
DNS работает в иерархии. Домены верхнего уровня могут иметь множество доменов под ними. Например, домен верхнего уровня «com» включает в себя «google.com» и «ubuntu.com». Поддомен это домен, который является частью домена более высокого уровня. В этом случае можно сказать, что «ubuntu.com» явлется поддоменом «com». Как правило, он называется просто доменом или часть «Ubuntu» называется SLD, что означает домен второго уровня.
Точно так же каждый домен может контролировать «поддомены», которые находятся под ним. Например, у вас мог бы быть поддомен для отдела истории в вашей школе по адресу «www.history.school.edu». В этом случае часть «history» считается поддоменом.
Разница между именем узла и поддомена в том, что узел указывает на компьютер или ресурс, в то время как поддомен расширяет родительский домен.
Читая о поддоменах или узлах, вы можете заметить, что самый левые части доменов наиболее конкретные. Это объясняет работу DNS: от наиболее конкретного к наименее конкретному, так как вы читаете слева направо.
Полностью определенное имя домена
Полностью определенное имя домена часто называют FQDN, или полное имя домена. Домены в системе DNS могут быть определены по отношению друг к другу и, по существу, неоднозначны. FQDN является полным именем, которое указывает его место в отношении к абсолютному корню системы доменных имен.
Это означает, что он указывает на каждый родительский домен, включая TLD. Правильный FQDN заканчивается точкой, указывая на корень иерархии DNS. Примером FQDN является «mail.google.com.». Иногда программное обеспечение, которое запрашивает FQDN, не нуждается в точке на конце, но завершающая точка требуется для соответствия стандартам ICANN.
DNS-сервер
DNS-сервер это компьютер, предназначенный для перевода доменных имен в IP-адреса. Эти серверы проделывают основную часть работы в системе доменных имен. Так как общее число доменных переводов слишком велико для любого сервера, каждый сервер может перенаправить запрос на другие DNS-сервера или делегировать ответственность за подмножество поддоменов, которое находится под их ответственностью.
DNS-сервера могут быть «авторитетными», что означает, что они предоставляют ответы на запросы о доменах под своим контролем. В противном случае они могут указать на другие серверы или предоставить кэшированные копии данных других DNS-cерверов.
Файл зоны
Файл зоны представляет собой простой текстовый файл, который содержит соединение между доменными именами и IP-адресами. С помощью него DNS выясняет, с каким IP-адресом необходимо связаться, когда пользователь запрашивает определенное доменное имя.
Файлы зоны находятся на DNS-серверах и в общем определяют ресурсы, доступные под конкретным доменом, или место, в котором можно запросить данную информацию.
Ресурсные записи
Записи хранятся в пределах файла зоны. В своей простейшей форме запись это простое соединение между ресурсом и именем. Эти записи могут соединять имя домена с IP-адресом, определять DNS-серверы и почтовые серверы для домена и т.д.
Как работает DNS
Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, возникает вопрос, как действительно работает система?
Система очень проста, если смотреть в общем, но очень сложна, если вы углубитесь в детали. В целом, это очень надежная инфраструктура, которая была необходима для адаптации интернета таким, каким мы знаем его сегодня.
Корневые серверы DNS
Как уже говорилось выше, DNS, по сути, является иерархической системой. В верхней части этой системы находится то, что мы называем корневым сервером DNS. Эти серверы находятся под контролем различных организаций, действующих по согласию с ICANN (Корпорация по управлению доменными именами и IP-адресами).
В настоящее время 13 корневых серверов находятся в эксплуатации. Тем не менее, так как каждую минуту появляется немыслимое количество имен для преобразования, каждый из этих серверов имеет зеркало. Интересно, что все зеркала для одного корневого сервера делят один IP-адрес. Когда выполняется запрос к определенному серверу, он будет перенаправлен к ближайшему зеркалу этого корневого сервера.
Что делают эти корневые серверы? Они обрабатывают запросы на информацию о доменах верхнего уровня. Поэтому если приходит запрос о чем-то, что DNS-сервер не может преобразовать, то запрос перенаправляется в корневой DNS-сервер.
Корневые серверы на самом деле не обладают информацией о том, где размещен домен. Они, однако, в состоянии направить запрашивающего к DNS-серверу, который обрабатывает нужный домен верхнего уровня.
Таким образом, если запрос «www.wikipedia.org» производится в корневой сервер, то он ответит, что не может найти результат в своих записях. Он проверит свои файлы зоны на наличие соответствий «www.wikipedia.org». И также не найдет их.
Вместо этого он найдет запись для домена верхнего уровня «org» и предоставит запрашивающему адрес DNS-сервера, отвечающего за адреса «org».
TLD Серверы
После этого запрашивающий отправит новый запрос на IP-адрес (предоставленный ему корневым сервером), который отвечает за необходимый домен верхнего уровня.
Продолжая наш пример, запрос был бы отправлен на DNS-сервер, отвечающий за информацию о домене «org», чтобы проверить, есть ли у него информация о том, где находится «www.wikipedia.org».
Опять же запрашивающий будет искать «www.wikipedia.org” в своих файлах зоны. И не найдет эту запись в своих файлах
Тем не менее он найдет запись с упоминанием IP-адреса DNS-сервера, ответственного за «wikipedia.org». И это приближает нас гораздо ближе к результату.
DNS-сервер на уровне домена
На этом этапе у запрашивающего есть IP-адрес DNS-сервера, который хранит информацию о фактическом IP-адресе ресурса. Он отправляет новый запрос на DNS-сервер с уточнением, может ли он предоставить «www.wikipedia.org».
DNS-сервер проверяет свои файлы зоны и обнаруживает, что у него есть файл зоны, соотносящийся с «wikipedia.org». Внутри этого файла находится запись для «WWW» узла. Эта запись указывает IP-адресу, где находится этот узел. DNS-сервер возвращает окончательный ответ на запрос.
Что такое публичный DNS-сервер?
В приведенном выше сценарии мы ссылались на «запрашивающего”. Что же это может значить?
Почти во всех случаях запрашивающим будет являться то, что мы называем «публичный DNS-сервер». Этот сервер настроен на отправку запросов другим серверам. По сути, это посредник для пользователя, который кэширует предыдущие результаты запроса для повышения скорости и знает адреса корневых серверов, способных преобразовать запросы, сделанные для данных, информацией о которых он уже не владеет.
Как правило, пользователь будет иметь несколько публичных DNS-серверов, настроенных на их компьютерной системе. Публичные DNS-серверы обычно предоставляются ISP или другими организациями. Например, Google предоставляет публичные DNS-сервера, которые вы можете запросить. Они могут быть настроены на вашем компьютере автоматически или вручную.
При вводе URL в адресной строке браузера ваш компьютер прежде всего проверяет, может ли он найти, где находится ресурс, на локальном уровне. Он проверяет «узлы» файлов на компьютере и других местах. Затем он отправляет запрос на публичный DNS-сервер и ожидает получить обратно IP-адрес ресурса.
Затем публичный DNS-сервер проверяет свой кэш на наличие ответа. Если он не найдет то, что необходимо, он проделает шаги, указанные выше.
Публичные DNS-серверы по сути сжимают процесс отправки запроса для конечного пользователя. Клиенты просто должны не забывать спрашивать публичный DNS-сервер, где находится ресурс, и быть уверенными, что они найдут окончательный ответ.
Файлы зоны
Мы уже упоминали в перечисленных выше процессах «файлы зоны» и «записи».
Файлы зоны это способ, с помощью которого DNS-сервер хранит информацию о доменах, которые он знает. Каждый домен, информация о котором есть у DNS-сервера, хранится в файле зоны. Если DNS-сервер настроен для работы c рекурсивные запросами, как публичный DNS-сервер, он найдет ответ и предоставит его. В противном случае он укажет пользователю, где искать дальше. Чем больше у сервера файлов зоны, тем больше ответов на запросы он сможет предоставить.
Файл зоны описывает DNS «зону», которая, по существу, является подмножеством всей системы DNS. Как правило, она используется для настройки только одного домена. Она может содержать некоторое количество записей, которые указывают, где находятся ресурсы для запрашиваемого домена.
Параметр зоны $ORIGIN эквивалентен высшему уровню полномочий в зоне по умолчанию.
Таким образом, если файл зоны используется для настройки домена «example.com.», то параметр $ORIGIN также будет установлен для этого домена.
Это настраивается на верхнем уровне файла зоны или может быть указано в настройках файла DNS-сервера, который ссылается на файл зоны. В любом случае этот параметр описывает то, за что зона будет ответственна.
Точно так же $TTL настраивает «время жизни» информации, которую он предоставляет. По сути, это таймер. Кэширующий DNS-сервер может использовать ранее запрошенные результаты для ответа на вопросы, пока заданное значение TTL не истечет.
Типы записи
В файле зоны может быть множество различных типов записей. Мы рассмотрим некоторые из наиболее распространенных видов (или обязательных) ниже.
Записи SOA
Начальная запись зоны или SOA (Start of Authority) — обязательная запись для всех файлов зоны. Она должна быть первой записью в файле (хотя $ORIGIN или $TTL могут появиться выше). Она также является одной из самых сложных для понимания.
Начальная запись зоны выглядит примерно так:
domain.com. In SOA ns1.domain.com. admin.domain.com. (
12083 ; serial number
3h ; refresh interval
30m ; retry interval
3w ; exiry period
1h ; negative TTL
)Поясним, что означает каждая часть:
- domain.com.: Это корень зоны. Он указывает, что файл зоны относится к домену domain.com.domain. Часто вы будете видеть, что он заменен на “@”, что является только заполнителем, который замещает содержимое переменной $ORIGIN, о которой мы узнали выше.
- In SOA: Часть «In» означает Интернет (и будет присутствовать во многих записях). SOA является показателем того, что это начальная запись зоны.
- ns1.domain.com.: Эта часть определяет мастер-сервер для этого домена. DNS-сервер может быть либо мастером, то есть первичным, либо слейв, или вторичным.
- admin.domain.com.: Это электронный адрес администратора этой зоны. Символ «@» заменяется точкой в адресе электронной почты. Если в части имени email адреса обычно стоит точка, это означает замену символа «\» в этой части ([email protected] становится your\name.domain.com).
- 12083: Это серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, необходимо увеличивать это число. Слейв серверы проверят, если серийный номер мастер сервера для зоны больше, чем тот, который находится у них в системе. Если это так, то сервер запросит новый файл зоны, а если нет, то он продолжит обслуживать исходный файл.
- 3h: Это интервал обновления для зоны. Это количество времени, которое слейв сервер будет ждать прежде, чем запросит у мастер сервера изменение файла зоны.
- 30m: Это интервал повтора для этой зоны. Если слейв сервер не может подключиться к мастеру, когда наступает период обновления, он будет ждать данное количество времени, а после повторит запрос мастер серверу.
- 3w: Это период истечения. Если слейв DNS-сервер не смог связаться с мастер сервером в течение этого периода времени, он больше не будет возвращать запросы к авторитетному источнику этой зоны.
- 1h: Это количество времени, которое DNS-сервер будет кэшировать ошибку, если не сможет найти запрашиваемое имя в файле.
А и AAAA записи
Обе эти записи соединяют узел с IP-адресом. «А» запись используется для соединения узла с IPv4 IP-адреса, в то время как запись “AAAA» используется для соединения хоста для адреса IPv6.
Общий формат этих записей выглядит следующим образом:
host IN IPv4_address
host IN AAAA IPv6_address
Таким образом, если SOA запись обращается к основному мастер серверу в «ns1.domain.com», мы должны соединить этот адрес с IP-адресом, так как «ns1.domain.com» находится в зоне domain.com, которую определяет этот файл.
Запись может выглядеть примерно так:
ns1 IN A 111.222.111.222
Обратите внимание, что нет необходимости указывать полное имя. Мы можем просто указать узел (без FQDN), и DNS-сервер заполнит остальное согласно значению $ORIGIN. Тем не менее мы могли бы так же легко использовать FQDN:
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-адресов.
Запись CNAME
CNAME записи указывает псевдоним для канонического имени вашего сервера (который определен А или AAAA записью).
Например, у нас может быть A запись, определяющая узел «server1», а затем мы можем использовать «WWW» в качестве псевдонима для данного узла:
server1 IN A 111.111.111.111
www IN CNAME server1
Знайте, что эти псевдонимы сопровождаются некоторыми потерями производительности, потому что они требуют дополнительного запроса к серверу. В большинстве случае те же результаты могут быть достигнуты с помощью дополнительных A или AAAA записей.
CNAME рекомендуется использовать, когда необходимо предоставить псевдоним ресурсу за пределами текущей зоны.
Запись 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 записи
Этот тип записи указывает на DNS-сервера, используемые для этой зоны.
Вы можете спросить: “Почему файлу зоны, находящемуся на DNS-сервере, необходимо ссылаться на себя самого?” DNS-сервер настолько удобен, потому что имеет несколько уровней кэширования. Одной из причин для указания DNS-серверов в файле зоны служит то, что файл зоны может быть фактически обслужен с кэшированной копии на другом DNS-сервере. Есть и другие причины, объясняющие необходимость DNS-серверов ссылаться на сами DNS-сервера, но мы не будем вдаваться в эти подробности.
Как MX записи, NS записи являются параметрами всей зоны, так что они также не соединяют узлы. Выглядят они так:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
Вы должны иметь по крайней мере два DNS-сервера, указанные в каждом файле зоны для того, чтобы правильно действовать, если есть проблема с одним из серверов.
Большая часть программного обеспечения DNS-серверов считает файл зоны недействительным, если указан только один 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
Есть немало других типов записей, которые можно использовать, но это, вероятно, наиболее распространенные типы, которые вы встретите.
Вывод
Теперь у вас должно сформироваться достаточно хорошее представление о том, как работает DNS. В то время как идея, в общем, довольно проста для понимания, если вы знакомы с основными принципами, некоторые детали все еще могут быть непонятны для неопытных администраторов в процессе практики.
timeweb.com
Domain Name System — Сайт и блог программиста
DNS (Domain Name System – система доменных имен) – иерархическая система имен, основанная на распределенной системе базы данных, служащая для разрешения символьных имен в IP-адреса.
Служба DNS применятся для облегчения обмена данными между компьютерами в сети, связывая имена компьютеров с их IP-адресами.
Становление DNS
На заре становления Интернета (тогда еще он назывался ARPANET), проблема разрешения (трансляции) доменных имен в IP-адреса решалась ведением длинных списков, в которых символьное имя соответствовало IP-адресу. Пережиток этого метода мы можем наблюдать в файле «hosts», который расположен в папке %SystemRoot%\system32\drivers\etc.
Со временем, сопровождать такие списки имен становилось все труднее и труднее. Такие файлы требовалось часто синхронизировать, не говоря уже об их внушительных размерах.
В итоге, в 1983 году Джоном Постелом (Jon Postel) и Полом Мокапетрисом (Paul Mockapetris) была разработана система доменных имен (Domain Name System). Актуальную на данный момент спецификацию DNS можно найти в документах RFC 1034 и RFC 1035, которые датируются 1987 годом.
Терминологический минимум
Домен (Domain – область) – именованная область пространства иерархических имен.
Различают домены первого, второго, третьего и далее уровней, однако корневым доменом всей иерархии является точка «.», которая ставится в конце DNS имени. После корневого домена следует домен первого уровня, который может быть организован географически, по типу организации или по своему назначению. Затем следует домен второго уровня, третьего и т.д.
Домен нулевого уровня находится в основе DNS-иерархии и зачастую называется корневым доменом.
Следует помнить, что уровни домена считаются справа налево.
Поддомен (Subdomain) – дочерний домен, являющийся частью родительского домена.
Допускается деление поддоменов на 127 уровней, при этом каждая DNS метка не должна превышать 63 символа. Такое деление на поддомены возможно до тех пор, пока полное имя домена не будет превышать длину в 255 символов.
Resolver – это набор программного обеспечения, используемое для разрешения доменных имен.
Функционирование DNS
В качестве примера рассмотрим домен www.volokh.info.
Отметим, что в конце символьного имени ставится точка, которую зачастую опускают, но иногда она требуется в описаниях DNS.
При запросе адреса www.volokh.info., браузер обращается к локальному DNS-серверу, IP-адрес которого зачастую прописан в свойствах подключения Интернет сети. У DNS-сервера запрашивается информация о соответствии символьного имени домена www.volokh.info. IP-адресу. Получив запрос, DNS-сервер проверяет локальный кэш и, в случае отсутствия данных о требуемом домене, сообщает клиенту IP-адрес корневого домена, например 198.41.0.4.
В случае если у корневого DNS-сервера не имеется требуемой информации по домену info., то корневой DNS-сервер сообщает IP-адрес DNS-сервера, ответственного за домен первого уровня. Таким образом, запрос начинает спускаться вниз по иерархии уровней доменов, до тех пор, пока не будет найден DNS-сервер, ответственной за домен www.volokh.info.
Найденный DNS-сервер сообщает клиенту IP-адрес требуемого домена, и клиент подключается к серверу по IP-адресу 50.6.23.170.
Рекурсивный и итеративный запрос
DNS-запрос может быть рекурсивным и итеративным.
Рекурсивный запрос – это такой DNS-запрос, при котором DNS-сервер выступает в качестве клиента, от имени которого запрашиваются данные, и опрашивает другие сервера в поиске IP-адреса для определенного домена.
Рекурсивный метод запроса справедлив том случае, когда браузер запрашивает у DNS-сервера IP-адрес домена «www.volokh.info.»
1. DNS-сервер, не найдя записей в локальном кэше, обращается к корневому домену «.»;
2. Корневой домен, в свою очередь, сообщает IP-адрес DNS-сервера, ответственного за домен «info.» и DNS-сервер опрашивает уже его;
3. Ответственный сервер за домен «info.» сообщает DNS-серверу IP-адрес сервера, который может сообщить IP-адрес для домена «volokh.info»;
4. DNS-сервер, запросивший IP-адрес домена, опрашивает сервер, ответственный за домен «www.volokh.info.», который, в свою очередь, возвращает нужный IP-адрес;
5. DNS-сервер возвращает IP-адрес клиенту, после чего происходит подключение к серверу по имени 50.6.23.170.
Итеративный метод запроса – это такой DNS-запрос, при котором DNS-клиент самостоятельно отслеживает отсылки к другим DNS-серверам и самостоятельно опрашивает их в поиске IP-адреса для определенного домена.
Для наглядности, на рис. 1 приведены оба метода запросов:
Итеративный метод запроса справедлив том случае, когда:
1. Resolver, для разрешения символьного имени «www.volokh.info.», посылает запрос на свой DNS-сервер;
2. DNS-сервер, получив запрос, отсылает в ответ IP-адрес корневого домена;
3. Resolver посылает запрос разрешения имени корневому DNS-серверу и получает в ответ адрес сервера, ответственного за зону «info.»;
4. Получив адрес DNS-сервера, ответственного за зону «info.», resolver отправляет DNS-запрос этому серверу;
5. DNS-сервер, получив запрос разрешения имени, сообщает адрес сервера, ответственного за домен «volokh.info.»;
6. Resolver посылает запрос серверу, ответственному за домен «www.volokh.info.», который, в свою очередь, возвращает нужный IP-адрес;
7. Resolver, получив IP-адрес для домена «www.volokh.info.», осуществляет подключение к серверу по имени 50.6.23.170.
В случае рекурсивного запроса, DNS-сервер может не опрашивать другие DNS-сервера при условии, если у него в кэше есть информация о требуемом домене.
Зарезервированные доменные имена
Спецификация DNS предусматривает список зарезервированных доменов первого уровня, которые можно использовать в качестве примеров в документации или для тестирования локальных DNS-серверов.
Список зарезервированных доменов верхнего уровня (top-level domain) состоит из четырех имен: «.test», «.example», «.invalid» и «.localhost».
Помимо перечисленных выше доменов верхнего уровня, зарезервированы доменные имена второго уровня: «example.com», «example.net» и «example.org».
Использование зарезервированных доменных имен позволит избежать конфликтов с существующими доменными именами.
Технические детали DNS
Существует несколько основных реализаций DNS-серверов: BIND, Microsoft DNS Server , PowerDNS и NSD.
BIND (Berkeley Internet Name Domain) – является самой распространенной реализацией DNS-сервера и используется практически всеми корневыми DNS-серверами.
Другие реализации серверов менее распространенны и в основном используются внутри крупных предприятий.
Для ответов на запросы, протокол DNS использует 53 порт протокола UDP (User Datagram Protocol). TCP (Transmission Control Protocol) используется в том случае, когда размер получаемых данных от DNS-сервера превышает 512 байт. При этом, данные также передаются через 53 порт протокола TCP.
Выводы
DNS (Domain Name System) – является признанным механизмом разрешения имен. Ключевым фактором в работе DNS является возможность разбиения разрешения имен по доменам, что позволяет обеспечить общедоступность каждого сервера в отдельности. В случае сбоя одного из DNS-серверов, функционирование всей иерархии системы имен не прерывается, так как в работу включается резервный сервер. Это позволяет обеспечивать сохранность данных и продолжение работы системы доменных имен в случае выхода из строя одного из узлов системы.
Вся структура Domain Name System является иерархической. Существуют домены первого, второго, третьего и т.д. уровней.
Для повышения эффективности работы DNS, DNS-серверы кэшируют полученные DNS-ответы.
Таким образом, DNS выполняет ключевую роль в функционировании сети Интернет.
2011-07-16 18:49
Понравился сайт? Расскажи о нем друзьям:
Comments to Notes: 0
volokh.info
Система DNS. Немного истории и принципы построения иерархии имен.
Когда при деловом общении представители двух фирм обмениваются визитками, то в них (визитках) обязательно будут указаны адрес электронной почты и имя корпоративного Web-узла компании. При этом можно также услышать, как собеседники обмениваются «интернет-адресами» («электронными адресами») компаний. Во всех выше перечисленных случаях так или иначе речь идет об использовании доменных имен.
В адресе электронной почты формально доменным именем можно считать то, что написано после символа коммерческого ат — «@». Например, в [email protected] доменное имя почтового узла — test.ru.
Имя Web-узла — это доменное имя этого узла. Например, Web-узел компании Microsoft имеет доменное имя Microsoft.com.
В большинстве случаев при поиске информации в Сети мы перебираем доменные имена или следуем по ссылкам, в нотации которых опять же используются доменные имена.
Довольно часто наряду со словосочетанием «интернет-адрес» употребляют «доменный адрес». Вообще говоря, ни того, ни другого понятий в сетях TCP/IP не существует. Есть числовая адресация, которая опирается на IP-адреса, (группа из 4-ех чисел, разделенных символом «.») и Internet-сервис службы доменных имен (Domain Name System — DNS).
Числовая адресация удобна для компьютерной обработки таблиц маршрутов, но совершенно (здесь мы несколько утрируем) не приемлема для использования ее человеком. Запомнить наборы цифр гораздо труднее, чем мнемонические осмысленные имена.
Тем не менее, установка соединений для обмена информацией в Интернет осуществляется по IP-адресам. Символьные имена системы доменных имен — суть сервис, который помогает найти необходимые для установки соединения IP-адреса узлов сети.
Тем не менее, для многих пользователей именно доменное имя выступает в роли адреса информационного ресурса. В практике администрирования локальных сетей нередки ситуации, когда пользователи жалуются администратору сети на недоступность того или иного сайта или долгую загрузку страниц. Причина может крыться не в том, что сегмент сети потерял связь с остальной сетью, а в плохой работе DNS — нет IP-адреса, нет и соединения.
DNS существовала не с момента рождения TCP/IP сетей. Поначалу для облегчения взаимодействия с удаленными информационными ресурсами в Интернет стали использовать таблицы соответствия числовых адресов именам машин.
Авторство создания этих таблиц принадлежит доктору Постелю (Dr. Jon Postel — автор многих RFC — Request For Comments). Именно он первым поддерживал файл hosts.txt, который можно было получить по FTP.
Современные операционные системы тоже поддерживают таблицы соответствия IP-адреса и имени машины (точнее хоста) — это файлы с именем hosts. Если речь идет о системе типа Unix, то этот файл расположен в директории /etc и имеет следующий вид:
127.0.0.1 localhost
144.206.130.137 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.32 polyn Polyn polyn.net.kiae.su polyn.kiae.su
144.206.160.40 apollo Apollo www.polyn.kiae.su
Пользователь для обращения к машине может использовать как IP-адрес машины, так и ее имя или синоним (alias). Как видно из примера, синонимов может быть много, и, кроме того, для разных IP-адресов может быть указано одно и то же имя.
Напомним еще раз, что по самому мнемоническому имени никакого доступа к ресурсу получить нельзя. Процедура использования имени заключается в следующем:
- сначала по имени в файле hosts находят IP-адрес,
- затем по IP-адресу устанавливают соединение с удаленным информационным ресурсом.
Обращения, приведенные ниже аналогичны по своему результату — инициированию сеанса telnet с машиной Apollo:
telnet 144.206.160.40
или
telnet Apollo
или
telnet www.polyn.kiae.su
В локальных сетях файлы hosts используются достаточно успешно до сих пор. Практически все операционные системы от различных клонов Unix до Windows последних версий поддерживают эту систему соответствия IP-адресов именам хостов.
Однако такой способ использования символьных имен был хорош до тех пор, пока Интернет был маленьким. По мере роста Сети стало затруднительным держать большие согласованные списки имен на каждом компьютере. Главной проблемой стал даже не размер списка соответствий, сколько синхронизация его содержимого. Для того, что бы решить эту проблему, была придумана DNS.
DNS была описана Полом Мокапетрисом (Paul Mockapetris ) в 1984. Это два документа: RFC-882 и RFC-883 (Позже эти документы были заменены на RFC-1034 и RFC-1035). Пол Мокапетрис написал и реализацию DNS — программу JEEVES для ОС Tops-20. Именно на нее в RFC-1031 предлагается перейти администраторам машин с ОС Tops-20 сети MILNET. Не будем подробно излагать содержание RFC-1034 и RFC-1035. Ограничимся только основными понятиями.
Роль имени (доменного имени) в процессе установки соединения осталось прежним. Это значит, что главное, для чего оно нужно, — получение IP адреса. Соответственно этой роли, любая реализация DNS является прикладным процессом, который работает над стеком протоколов межсетевого обмена TCP/IP. Таким образом, базовым элементом адресации в сетях TCP/IP остался IP-адрес, а доменное именование (система доменных имен) выполняет роль вспомогательного сервиса.
Система доменных имен строится по иерархическому принципу. Точнее по принципу вложенных друг в друга множеств. Корень системы называется «root» (дословно переводится как «корень») и никак не обозначается (имеет пустое имя согласно RFC-1034).
Часто пишут, что обозначение корневого домена — символ «.», но это не так, точка — разделитель компонентов доменного имени, а т.к. у корневого домена нет обозначения, то полное доменное имя кончается точкой. Тем не менее символ «.» достаточно прочно закрепился в литературе в качестве обозначения корневого домена. От части это вызвано тем, что в файлах конфигурации серверов DNS именно этот символ указывается в поле имени домена (поле NAME согласно RFC-1035) в записях описания ресурсов, когда речь идет о корневом домене.
Корень — это все множество хостов Интернет. Данное множество подразделяется на домены первого или верхнего уровня (top-level или TLD). Домен ru, например, соответствует множеству хостов российской части Интернет. Домены верхнего уровня дробятся на более мелкие домены, например, корпоративные.
В 80-е годы были определены первые домены первого уровня (top-level): gov, mil, edu, com, net. Позднее, когда сеть перешагнула национальные границы США появились национальные домены типа: uk, jp, au, ch, и т.п. Для СССР также был выделен домен su. После 1991 года, когда республики Союза стали суверенными, многие из них получили свои собственные домены: ua, ru, la, li, и т.п.
Однако Интернет не СССР, и просто так выбросить домен su из системы доменных имен нельзя. На основе доменных имен строятся адреса электронной почты и доступ ко многим другим информационным ресурсам Интернет. Поэтому гораздо проще оказалось ввести новый домен к существующему, чем заменить его.
Если быть более точным, то новых имен с расширением su в настоящее время ни один провайдер не выделяет (делегирует). Однако у многих существует желание возобновить процесс делегирования доменов в зоне SU.
Со списком доменов первого уровня (top-level) и их типами можно ознакомиться, например, в материале «Общая информация о системе доменных имен» по адресу https://info.nic.ru/domains/review.html.
Как уже было сказано, вслед за доменами первого уровня(top-level) следуют домены, определяющие либо регионы (msk), либо организации (kiae). В настоящее время практически любая организация может получить свой собственный домен второго уровня. Для этого надо направить заявку провайдеру и получить уведомление о регистрации (см. «Как получить домен»).
Далее идут следующие уровни иерархии, которые могут быть закреплены либо за небольшими организациями, либо за подразделениями больших организаций.
Часть дерева доменного именования можно представить следующим образом:
Рис.1. Пример части дерева доменных имен.
Корень дерева не имеет имени метки. Поэтому его обозначают как «». Остальные узлы дерева метки имеют. Каждый из узлов соответствует либо домену, либо хосту. Под хостом в этом дереве понимают лист, т.е. такой узел ниже которого нет других узлов.
Именовать хост можно либо частичным именем, либо полным именем. Полное имя хоста — это имя, в котором перечисляются слева направо имена всех промежуточных узлов между листом и корнем дерева доменного именования, при этом начинают с имени листа, а кончают корнем, например:
polyn.net.kiae.su.
Частичное имя — это имя, в котором перечислены не все, а только часть имен узлов, например:
polyn
apollo.polyn
quest.polyn.kiae
Обратите внимание на то, что в частичных (неполных именах) символ точки в конце имени не ставится. В реальной жизни программное обеспечение системы доменных имен расширяет неполные имена до полных прежде, чем обратиться к серверам доменных мен за IP-адресом.
Слово «Хост» не является в полном смысле синонимом имени компьютера, как это часто упрощенно представляется. Во-первых, у компьютера может быть множество IP-адресов, каждому из которых можно поставить в соответствие одно или несколько доменных имен. Во-вторых, одному доменному имени можно поставить в соответствие несколько разных IP-адресов, которые, в свою очередь могут быть закреплены за разными компьютерами.
Еще раз обратим внимание на то, что именование идет слева направо, от минимального имени хоста (от листа) к имени корневого домена. Разберем, например, полное доменное имя demin.polyn.kiae.su. Имя хоста — demin, имя домена, в который данный хост входит, — polyn, имя домена, который охватывает домен polyn, т.е. является более широким по отношению к polyn, — kiae, в свою очередь последний (kiae) входит в состав домена su.
Имя polyn.kiae.su — это уже имя домена. Под ним понимают имя множества хостов, у которых в их имени присутствует polyn.kiae.su. Вообще говоря, за именем polyn.kiae.su может быть закреплен и конкретный IP-адрес. В этом случае кроме имени домена данное имя будет обозначать и имя хоста. Такой прием довольно часто используется для обеспечения коротких и выразительных адресов в системе электронной почты.
Имена хоста и доменов отделяются друг от друга в этой нотации символом «.». Полное доменное имя должно оканчиваться символом «.», т.к. последняя точка отделяет пустое имя корневого домена от имени домена верхнего уровня. Часто в литературе и в приложениях эту точку при записи доменного имени опускают, используя нотацию неполного доменного имени даже в том случае, когда перечисляют все имена узлов от листа до корня доменного именования.
Следует иметь в виду, что доменные имена в реальной жизни достаточно причудливо отображаются на IP-адреса, а тем более на реальные физические объекты (компьютеры, маршрутизаторы, коммутаторы, принтеры и т.п.), которые подключены к сети.
Компьютер, физически установленный и подключенный к Сети в далекой Америке, может совершенно спокойно иметь имя из российского корпоративного домена, например, chalajva.ru, и наоборот, компьютер или маршрутизатор российского сегмента может иметь имя из домена com. Последнее, к слову сказать, встречается гораздо чаще.
Более того, один и тот же компьютер может иметь несколько доменных имен. Возможен вариант, когда за одним доменным именем может быть закреплено несколько IP-адресов, которые реально назначены различным серверам, обслуживающим однотипные запросы.
Таким образом, соответствие между доменными именами и IP-адресами в рамках системы доменных имен не является взаимно однозначным, а строится по схеме «многие к многим».
Несколько последних замечаний были призваны обратить внимание читателя на тот факт, что иерархия системы доменных имен строго соблюдается только в самих именах и отображает только вложенность именования и зоны ответственности администраторов соответствующих доменов.
Следует также упомянуть о канонических доменных именах. Это понятие встречается в контексте описания конфигураций поддоменов и зон ответственности отдельных серверов доменных имен. С точки зрения дерева доменных имена не разделяют на канонические и неканонические, но с точки зрения администраторов, серверов и систем электронной почты такое разделение является существенным. Каноническое имя — это имя, которому в соответствие явно поставлен IP-адрес, и которое само явно поставлено в соответствие IP-адресу. Неканоническое имя — это синоним канонического имени. Более подробно см. «настройка BIND».
Наиболее популярной реализацией системы доменных имен является Berkeley Internet Name Domain (BIND). Но эта реализация не единственная. Так в системе Windows NT 4.0 есть свой сервер доменных имен, который поддерживает спецификацию DNS.
Тем не менее, даже администраторам Windows желательно знать принципы функционирования и правила настройки BIND, т.к. именно это программное обеспечение обслуживает систему доменных имен от корня до TLD (Top Level Domain).
Рекомендованная литература:
- P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
- P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
- W.Lazear. RFC-1031. MILNET NAME DOMAIN TRANSITION. 1987. (http://www.ietf.org/rfc/rfc1031.txt?number=1031)
- Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
Полезные ссылки:
- http://www.dns.net/dnsrd/docs/ — коллекция ссылок на документы о системе доменных имен.
- http://www.internic.net/faqs/authoritative-dns.html — коротенькое описание назначения системы доменных имен.
- http://www.icann.org/ — сайт организации, которая в ответе за именование в Интернет.
- http://www.ispras.ru/~grn/dns/index.html — Г.В. Ключников. Служба доменных имен (Domain Name System). 1999. На самом деле, это отличная компиляция приведенных в конце книжки первоисточников. Примеры взяты из этих же первоисточников. Очень качественный перевод и грамотно скомпонованный текст.
- http://www.ibb.ru/articles/stat_3.phtml — из серии «DNS за пять минут» J, но в качестве введения в тему данный материал может пригодиться.
- http://www.pi2.ru:8100/prof/techsupp/dns.htm — своеобразное описание системы доменных имен. Во всяком случае, самобытное. Но некоторые аспекты освещены довольно необычно.
info.nic.ru