Что такое авторитетный неавторитетный компетентный dns сервер

Обновлено: 06.07.2024

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

DNS помещает домены в специально разделенные зоны, за которые отвечают уже независимые администраторы. В общем и целом, DNS служит для преобразование доменных имен в IP-адреса. В этом база DNS схожа с телефонным справочником, в котором каждому телефонному номеру присвоено имя владельца. Кроме того, DNS значительно упрощает людям работу в Интернете — ведь запомнить доменное имя гораздо проще, чем IP-адрес. Другое преимущество DNS состоит в том, что IP-адреса могут быть весьма небезопасно изменены различными web-серверами. Поскольку пользователи имеют дело непосредственно с доменным именем, IP-адрес остается скрытым. Поскольку к одному доменному имени может быть привязано несколько IP-адресов, можно также говорить о распределении нагрузки посредством DNS. С помощью DNS возможно также по IP-адресу получить соответствующее доменное имя. Здесь снова можно провести аналогию с телефонной книгой, где мы можем по имени пользователя найти его телефонный номер, что носит название “обратный поиск” в отрасли телекоммуникации.

База DNS была создана в 1983 году Паулем Мокапетрисом и описана в RFC (Request for Comments) 882 и 883, которые позже были признаны устаревшими и были заменены RFC 1034 и 1035, которые были дополнены новой информацией. Первоначальным заданием DNS было заменить текстовый файл hosts, который составлялся централизованно. Этот текстовый файл обновлялся на каждой из компьютеров сети вручную. В связи с развитием сети Интернет количество доменов постоянно увеличивалось, что требовало нового подхода к преобразованию доменных имен и IP-адресов. Поскольку база DNS обладала большей надежностью и была способна вместить большее количество доменных имен, все данные постепенно были интегрированы в нее, и таким образом система DNS была предоставлена в распоряжение всем пользователям сети Интернет.

Отличительные особенности DNS:

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

Компоненты DNS

Nameserver

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

Авторитетный Nameserver отвечает за одну зону. Поэтому его сведения об этой зоне считаются достоверными. Для каждой зоны существует минимум один авторитетный сервер, так называемый первичный nameserver. Он хранит данные в SOA Resource Record. По причинам избыточности и распределения нагрузки авторитетные nameserver’a почти всегда реализованы как кластер-сервера, где данные распределенно хранятся на нескольких подчиненных серверах.

Неавторитетный Nameserver принимает данные о зоне через другие серверы, так сказать, не из первых рук. Его сведения считаются недостоверными. Поскольку данные DNS очень редко подвергаются изменениям, неавторитетные серверы хранят полученную от резолвера запрошенную информацию в оперативной памяти, чтобы при новых запросах эта информация выдавалась быстрее. Эта техника носит название кэширование. Каждая из этих записей обладает определенным сроком годности (TTL, Time to live), по истечении которого она удаляется из кэша. TTL назначается для каждой записи авторитетным Nameserver’ом и определяется после совершенного изменения этой записи (часто подвергающиеся изменениям данные DNS обычно имеют низкий TTL). Однако при определенных обстоятельствах это означает, что Nameserver может предоставлять неверные сведения в то время, как эти данные были изменены.

Особым случаем считается Nameserver только для кэширования. В этом случае Nameserver не несет ответственности ни за какую зону и должен отправлять все запросы на следующие Nameserver’а. Для этого имеется несколько стратегий:

Делегирование

Части доменного имени часто располагаются на поддоменах со специально ответственными за это Nameserver’ами. Nameserver одного домена знает ответственные Nameserver’a этих поддоменов из его зоны данных и делегирует запросы об этой подчиненной части доменного имени на этот Nameserver.

Пересылка

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

Первичный сервер

В случае, когда ни один сервер не конфигурирует или не отвечает, запрос направляется на первичный сервер. Для этого имена и IP-адреса первичного сервера депонируются в форме статического файла. Существует 13 первичных серверов (сервер А-М). Первичные серверы обрабатывают запросы исключительно многократно (сервер пересылает запрос на другие Nameserver’ы), так как иначе они были бы перегружены большим количеством запросов.

Строение базы DNS

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

На каждом сервере хранится одна или несколько записей — так называемые зоны — которые содержат все релевантные данные. При этих данных речь идет о Resource Records. Очень большое значение имеют 7 типов записи:

С течением времени были выявлены новые типы записи, с помощью которых реализуется расширение базы DNS. Этот процесс еще не завершен.

Расширение DNS

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

Динамический DNS

В классическом DNS становится слишком дорого присоединять каждому новому домену свой IP-адрес. Принадлежащий файл зоны должен изменяться (в большинстве случаев вручную) и по-новому загружаться на Nameserver. Возможны временные задержки до нескольких дней. С помощью динамического DNS возможно отправление изменений посредством DNS-запроса в реальном времени.

Интернационализация

DNS в локальной сети

DNS не ограничен интернетом. DNS также может вносить локальные имена и соответствующие адреса в собственные зоны на Nameserver’e.

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

DNS-сервер BIND может работать совместно с DHCP и позволяет каждому клиенту сети работу с доменными именами.

Для пользователей Windows существует другая программа - WINS, которая обладает теми же возможностями, что и BIND, но использует другой протокол.

Соединение DNS-серверов

Безопасность DNS

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

Известны следующие методы:

При TSIG (Transaction Signatures) речь идет о простом основывающемся на симметричных ключах методе, при котором трафик между DNS-серверами и модернизированными версиями клиентов остается защищенным.

При DNSSEC (DNS Security) используется асимметричная криптосистема, которая выполняет почти все защитные требования DNS. Наряду со связью сервер-сервер также сохраняется связь клиент-сервер.

Формы атак

DDOS атаки на Nameserver

При DDOS атаке (Distributed-Denial-of-Service-Attack) DNS перегружаются большим потоком DNS-запросов, так что легитимные запросы не могут быть выполнены. В настоящее время не имеется надежной защиты против DDOS атак на Nameserver’ы. В качестве мер предосторожности можно попробовать установить размеры Nameserver’а или инсталлировать распределенную сеть многими серверами. В любом случае, данный вид атак требует огромных затрат, т.к. необходимо завладеть такой мощной системой, как сам сервер, что весьма трудно реализовать. При таких атаках часто используются боты.

Атака рекурсивными запросами (DNS Amplification Attack)

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

DNS-Spoofing

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

Cache Poisoning

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

Открытый DNS-сервер

Использующие авторитетный DNS-сервер для своих собственных доменов, разумеется, должны быть открыты для запросов с любых IP-адресов. Чтобы препятствовать использованию клиентами данного сервера в качестве общего Nameserver’a (к примеру, для атак на корневой сервер), он разрешает BIND ограничивать ответы о собственных доменах. Например, при опции allow-recursion рекурсивные запросы, т.е. запросы о других доменах, обрабатываются только для локального компьютера (localhost) и 172.16.1.4. Все другие IP-адреса получают ответ только на запросы о своих доменах.

Дополнительная мера предосторожности - разрешать для ввода информации извне только UDP. ICCP DP также может быть допущена. Тем не менее, это варьируется от свойств Proxy.

Открытый DNS-сервер может быть также ловушкой, если он посылает в ответ фальшивые IP-адреса.

Защита от спама

При опции “Черный список” DNS запрашивает, находится ли доменное имя или IP-адрес в этом списке.: пользователь отправляет DNS-запрос на RBL-сервер. Он отвечает ‘127.0.0.1’, если адрес не находится в списке, то с ‘1 270,0,x’, x> 1. Значение x может содержать дополнительные сведения о запрашиваемом IP-адресе. Так как зона 127.0.0.0/8 зарезервирована для локального хоста, ошибки и неправильные толкования невозможны.

Интернет-корпорация по присвоению имен и номеров (ICANN) управляет этими доменными именами.

Домен верхнего уровня TLD относится к его последней части. Наиболее распространенные TLD включают: com, net, org и .info. ДВУ с кодом страны представляют конкретные географические местоположения. Например, in представляет Индию. Вот еще несколько примеров:

com - коммерческий бизнес;
gov — государственные органы США;
edu - образовательные учреждения, такие как университеты;
org - организации (в основном некоммерческие);
mil – военные организации;
net - сетевые организации;
es - Европейский Союз.

Основная задача сервера доменных имен

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

Благодаря DNS не нужно иметь собственную адресную книгу IP-адресов.

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

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

Без DNS-серверов интернет очень быстро отключился бы, аналогичное происходит, когда DNS работает с ошибкой. Как правило, когда пользователь подключается к домашней сети, поставщику услуг интернета через Wi-Fi, модем или маршрутизатор назначает сетевой адрес ПК и отправляет важную информацию о конфигурации сети на компьютер или мобильное устройство. Она включает в себя один или несколько DNS-серверов, которые устройство должно использовать при преобразовании DNS-имен в IP-адрес.

Стандарт IPV4

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

Чтобы понять, как работает DNS-сервер с большим количеством ресурсов, рассматривают методы расширения эффективности Сети и интернет-протоколов. Частично это заключается в том, что каждый ПК в Сети имеет уникальный IP как в стандартах IPV4, так и в IPV6, управляемых в интернете (IANA). Вот несколько способов распознать IP:

В стандарте IPV4 он состоит из четырех чисел, разделенных тремя десятичными знаками, например: 70.74.251.42
IP-адрес в стандарте IPV6 имеет восемь шестнадцатеричных чисел (base-16), разделенных двоеточиями: 0cb8: 85a3: 0000: 0000: 8a2e: 0370: 7334.
Поскольку IPV6 - это новый стандарт, поэтому провайдеры пока в основном работают на более распространенном IPV4.
DNS работает как в первом, так и во втором стандарте.

Адреса и диапазоны IANA

Они определяют IANA, как зарезервированные IP-адреса, и значит, что выполняют определенную работу в IP. Например, IP-адрес 127.0.0.1 зарезервирован для идентификации компьютера, который используется в настоящее время.

Принцип, как работает DNS в настольном компьютере или ноутбуке: IP-адрес исходит от DHCP-сервера сети. Задача его — убедиться, что ПК имеет IP и сетевую конфигурацию, которая ему нужна, когда пользователь подключен к Сети. Если он «динамический», то IP будет время от времени меняться, например, когда выключают машину.

Веб-серверы и ПК, которым требуется постоянный контакт, используют статические IP, когда один и тот же IP-адрес всегда назначается сетевому интерфейсу системы, когда он подключен к Сети. Чтобы последний всегда получал один и тот же IP-адрес, он связывает его с MA для этого сетевого интерфейса. Каждый сетевой интерфейс, как проводной, так и беспроводной, имеет уникальный MAC от производителя.

Нахождение IP-адреса

Один из быстрых способов найти IP-адрес - открыть приложение командной строки в разделе «Стандартные» и ввести команду: ipconfig. После этого можно проанализировать, как работает DNS и до скольки увеличивается скорость обработки в браузере. Для Mac:

открывают «Системные настройки»;
нажимают «Сеть»;
убеждаются, что выбрано текущее сетевое соединение (с зеленой точкой рядом с ним);
нажимают «Дополнительно» и переходят на вкладку TCP/IP.

Linux или UNIX, если в процессе настройки еще нет командной строки, открывают приложение терминала, такое как XTERM или iTerm. В командной строке вводят: ifconfig.

Для смартфонов с использованием Wi-Fi просмотр настройки сети телефона будет варьироваться в зависимости от версии аппарата и его операционной системы. Обращают внимание на то, что если пользователи находятся в домашней или небольшой локальной сети, адрес, вероятно, будет иметь вид 192.168.xx, 172.16.xx или 10.xxx (где x - это число от 0 до 255). Это зарезервированные адреса, используемые в каждой локальной сети, с помощью которых маршрутизатор в этой сети подключает устройство к интернету.

Авторитетный сервер и рекурсивный распознаватель

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

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

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

Существует ключевая разница между многими службами DNS и той, что предоставляет Cloudflare. Различные рекурсивные преобразователи DNS, такие как Google DNS, OpenDNS, и провайдеры, такие как Comcast, поддерживают установку рекурсивных преобразователей DNS в центрах обработки данных. Эти средства распознавания позволяют быстро и легко выполнять запросы через кластеры оптимизированных DNS компьютерных систем, но они принципиально отличаются от серверов имен, размещенных в Cloudflare, которая поддерживает сервера имен на уровне инфраструктуры, являющейся неотъемлемой частью функционирования интернета.

Алгоритм поиска

В большинстве случаев DNS касается преобразования доменного имени в соответствующий IP-адрес.

Чтобы узнать, как работает этот процесс, полезно проследить путь поиска DNS, когда он перемещается из веб-браузера и обратно.

Перечень шагов в поиске DNS:

Три типа DNS-запросов

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

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

Кэширование браузера

DNS-преобразователь уровня операционной системы — это вторая и последняя локальная остановка перед тем, как DNS-запрос покидает компьютер. Процесс в ОС, предназначенный для обработки этого запроса, обычно называется «решателем заглушки» или DNS-клиентом. Когда он получает запрос от приложения, то сначала проверяет собственный кэш, чтобы увидеть, есть ли у него запись. Если это не так, то он отправляет запрос DNS с установленным рекурсивным флагом за пределы локальной сети рекурсивному преобразователю DNS внутри поставщика услуг интернета (ISP).

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

Распространенные причины сбоев

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

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

Проблемы, связанные с браузером, имеют несколько простых способов исправлений:

Иногда все проблемы с ИТ уходят после включения/выключения.
Выполнение очистки кэша веб-браузера. Если обновление или сброс веб-браузера не работает, можно попробовать вручную очистить его через настройки.
Возможно, DNS-сервер работает исправно, но есть проблемы с браузером. Для устранения сбоя пробуют другой, например, Safari или Mozilla Firefox. Если другие браузеры работают, то сбой может быть связан с обновлением текущего. Попробуют удалить и переустановить его, чтобы решить эту проблему.
Если браузер работает хорошо, возможно, нужно обратить внимание на настройки маршрутизатора или компьютера.
Если были изменены настройки для использования, например, такой службы, как OpenDNS, то они могли сбиться. Рекомендуется узнать у провайдера или администратора Сети, какими они должны быть, или проверить сайт OpenDNS на предмет настроек сервера.
Отключают брандмауэр и антивирусные программы.
Перезагружают роутер. Это обновит кэш роутера и поможет решить проблему.
Изменяют свой DNS-сервер, возможно, рабочий DNS-сервер недоступен, так как он перегружен или работает неправильно.

Инструменты устранения неполадок

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

Почему не работает DNS, легко определить, используя средства устранения неполадок, такие как nslookup работают, как проверка конфигурации DNS-серверов. Слово nslookup является сокращением от «поиск сервера имен». Это инструмент запросов, который работает как в Windows, так и в Linux.

Самый простой способ использовать nslookup - это набрать команду с именем домена. Например, запись командной строки и результаты будут выглядеть примерно так:

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

Также можно перейти в интерактивный режим, введя nslookup в командной строке. Подсказка изменится на «>». Здесь можно ввести доменное имя напрямую. Если не работает DNS, а что делать пользователь не знает и его не устраивает поиск и устранение неисправностей в командной строке, есть и другие доступные варианты. Сайт DNSStuff предлагает много информации, если просто набрать доменное имя. Здесь предоставляется бесплатный инструментарий, который предлагает множество возможностей для анализа. Его отчет DNS, например, дает оценку прохождения/неудачи для различных тестов.

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

Основная цель 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, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Ресурсные записи

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

Запись ресурса состоит из следующих полей:

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом 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. Вот фрагмент файла, который нас интересует:

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в 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:

Директива 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 не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
Резолверпосылает запрос указанному серверу имен.
Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
и «вложенности» доменных имен.
В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

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

Ответы DNS сервера

Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).

Запись заголовка — служебную информацию о запросе.
Запись запроса — повторяет отправленный запрос.
Запись ответа — собственно, сам ответ.
Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
Дополнительную информацию — дополнительные записи, например адреса NS-серверов.

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

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 сессии.

Наглядно приведенную схему можно представить командами:

Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:

В двух словах хотел бы затронуть вопрос регистрации доменных имен.

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

В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.

Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Резюме

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

Что еще почитать:

Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.

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

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

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

Начиная с 2010 года, в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.

Ключевые характеристики DNS

DNS обладает следующими характеристиками:

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Дополнительные возможности

поддержка динамических обновлений
защита данных (DNSSEC) и транзакций (TSIG)
поддержка различных типов информации

Терминология и принципы работы

Ключевыми понятиями DNS являются:

Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.

Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов(это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются. [1]

Рекурсия

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

DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.

Аналогично, DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.

При ответе на нерекурсивный запрос, а также при неумении или запрете выполнять рекурсивные запросы, DNS-сервер либо возвращает данные о зоне, за которую он ответствен, либо возвращает ошибку. Настройки нерекурсивного сервера, когда при ответе выдаются адреса серверов, которые обладают большим объёмом информации о запрошенной зоне, чем отвечающий сервер (чаще всего — адреса корневых серверов), являются некорректными и такой сервер может быть использован для организации DoS-атак.

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

Рассмотрим на примере работу всей системы.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).

Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.

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

Обратный DNS-запрос

DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.

Записи DNS

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:

имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше не ответственногоDNS-сервера,
тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети [2] ,
длина поля данных (RDLEN),
поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

Порядок разрешения имен и поправки связанные с кэшированием

При запросе имени происходит несколько важных процедур, которые необходимо учитывать. Во первых это данные о связке имя — IP адрес может храниться в нескольких местах ( Hosts, DNS Cash, Lmhosts, DNS Server и др). Для того что бы полностью понимать принцип работы — нужно знать порядок в котором Windows пытается разрешить любое имя.

При разрешении имени сверяется с локальным именем компьютера.
Если локальное имя не совпадает с запрашиваемым, то выполнятся поиск в DNS Cash. ВАЖНО: в DNS кэш динамически загружаются данные из файла HOSTS ( поэтому поиск по файлу hosts не происходит, его данные всегда в памяти ПК, что ускоряет обработку ). Файл Hosts расположен в%systemroot%\System32\Drivers\Etc
Если имя не разрешилось в IP адрес, то пересылается на DNS сервер, который задан в сетевых настройках.
Если имя сервера плоское ( к примеру: server1 ) и не может быть разрешено с помощью DNS, то имя конвертируется в NetBIOS имя и ищется в локальном кэше
Если имя не может разрешиться, то ищется на WINS серверах
Если имя не может быть определено и на WINS сервере, то ищется с помощью BROADCAST запроса в локальной подсети
Если имя не определилось, то ищется в файле LMHOSTS

На данном рисунке показывается все пункты:

Порядок разрешения имен и поправки связанные с кэшированием

Поиск по всем 7-ми шагам прекращается как только находится первое вхождение, удовлетворяющие условиям.

Примечание:
-Посмотреть DNS кэш можно по команде c:\>ipconfig /displaydns

Windows IP Configuration

Record Type . . . . . : 1

Time To Live . . . . : 158

Data Length . . . . . : 4

A (Host) Record . . . : 72.233.56.138

Record Type . . . . . : 1

Time To Live . . . . : 158

Data Length . . . . . : 4

A (Host) Record . . . : 67.19.16.228

-Очистить DNS кэш можно по команде ipconfig /flushdns
c:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Как можно самому посмотреть ответы на запросы?

Отличной утилитой для диагностики DNS является NSLookup.exe
На какие ключи я бы обратил внимание:

LServer — Можно принудительно подключиться к определенному DNS серверу
set type=** для выбора параметров, которые мы хотим получить, к примеру set type=mx

Состав UDP пакета

DNS сервера использую 53-й UDP порт для запросов. Обычно отвечают одной дейтаграммой. Состав UDP датаграммы содержащей DNS запрос

Состав UDP пакета-01

Состав UDP пакета-02

Зарезервированные доменные имена

Интернациональные доменные имена

Доменное имя может состоять только из ограниченного набора ASCII символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.

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