Что такое DNS сервер, просто о сложном

Обновлено 04.04.2022

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

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

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

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

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

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

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

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

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

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

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

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

• Домен (англ. domain — область) — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованнаяветвь или поддерево в дереве имен. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости): вначале корневой домен (не имеющий идентификатора), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго wikipedia, третьего ru). На практике точку перед корневым доменом часто опускают ("ru.wikipedia.org" вместо"ru.wikipedia.org."), но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).
• Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — доменаwikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.
• Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определенному Доменному имени, узлу в дереве имен), тип и поле данных, формат и содержание которого зависит от типа.
• Зона — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имен (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже). Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации. Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имен DNS как структуру из зон, а не отдельных узлов/имен, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчиненных. На практике, большинство зон 0-го и 1-го уровня ('.', ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчиненных уровней без выделения их в дочерние зоны.
• Делегирование — операция передачи ответственности за часть дерева доменных имен другому лицу или организации. За счет делегирования в DNS обеспечивается распределенность администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.
• DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
• DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
• Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
• DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).
• Root-Hint — Well-known сервера отвечающие  за  корневой  домен «.» (точка)
• DNS-резолвер - это сервер, который провайдеры применяют для поиска в их БД нужного узла, к которому обращается пользователь. Когда эти данные получены, то пользователя перенаправляют на соответствующий IP-адрес. Основная задача DNS-резолвера, это за кэшировать информацию, но тут есть и большие минусы в этом. Приведу пример, маленькие местные провайдеры могут настроить время обновления кэша слишком большое, и получиться ситуация, что при смене IP-адреса неким сайтом, данные об этом могут обновиться на ряде таких резолверов очень не скоро, как следствие отсутствие доступа к такому ресурсу. Самый популярный наверное резолвер, это 8.8.8.8 от Google.

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

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

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

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDPдатаграммы. TCP используется когда размер данных ответа превышает 512 байт и для AXFR-запросов.

Виды DNS зон

Существует пять типов зон DNS:

• Основная зона (Primary или Master)
• Вторичная зона (Secondary или Slave)
• Зона, интегрированная с Active Directory
• Заглушка (Stub-Zone)
• Зона обратного просмотра (Reverse Lookup)

Что такое Основная зона (Primary или Master) ?

Главный DNS-сервер также известен как первичный DNS-сервер. Он считывает данные, относящиеся к доменной зоне, по сути это ауторитативный DNS (Авторитетный/Authoritative). Основная зона содержит локальную копию данных зоны для чтения и записи, и эта информация хранится в текстовом файле. Он также взаимодействует с подчиненными серверами. Администратор сервера инструктирует серверы о том, как взаимодействовать с другими веб-серверами. Связь главного сервера с подчиненным сервером называется передачей зоны. Все остальные серверы только копируют информацию с master-сервера.

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

Зона интегрированная с Active Directory

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

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

Что такое Вторичная зона (Secondary или Slave) ?

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

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

Напоминаю, что время согласования между slave-сервером и master-сервером настраивается со стороны администратора master-сервера, например на DNS серверах Active Directory настройка выглядит вот так.

Slave-сервер после истечения данного интервала времени будет опрашивать master-сервер, появились ли у него изменения в зоне или нет.

Типы DNS серверов

Корневой DNS-сервер

Корневой DNS-сервер (Root Hints) - Это DNS-сервер, который хранит в себе адреса всех TLD-серверов (TLD — top-level domain, домен верхнего уровня), по сути это список авторитетных серверов имен для корневых DNS-имен в Интернете. Так же это последнее средство для разрешения имен. DNS-сервер свяжется с корневыми ссылками только в том случае, если серверы пересылки недоступны или серверы пересылки не могут разрешить запрос. Это делает процесс разрешения имен с использованием корневых серверов более длительным. Это связано с тем, что при использовании Root Hints необходимо дождаться результата от другого процесса. Не говоря уже о задержке в подключении, поскольку корневой сервер глобально используются практически каждым DNS-сервером в Интернете. В его существует 13 корневых DNS серверов. Например при настройке DNS-сервера Windows их можно посмотреть на соответствующей вкладке.

TLD-серверы

TLD-серверы (TLD — top-level domain) - Данные сервера содержат список хостов о доменах верхнего уровня, например com, ru, net и так далее. Предположим, вы запрашиваете информацию по хосту pyatilistnik.org, в итоге запрос пойдет к TLD-серверу, который держит зону .org, и далее пока не будет найден адрес авторитативного DNS-сервера.

Рекурсия (Рекурсивный преобразователь DNS)

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

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

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

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

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

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

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

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

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

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

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

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

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

Авторитетный DNS-сервер

Проще говоря, авторитетный DNS-сервер - это сервер, который фактически содержит записи ресурсов DNS и отвечает за них.. Это сервер в нижней части цепочки поиска DNS, который ответит запрошенной записью ресурса, что в конечном итоге позволит веб-браузеру, делающему запрос, получить IP-адрес, необходимый для доступа к веб-сайту или другим веб-ресурсам. Авторитетный сервер имен может удовлетворять запросы из своих собственных данных, не обращаясь к другому источнику, поскольку он является окончательным источником достоверности для определенных записей 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-записей:

• Запись A (address record) или запись адреса связывает имя хоста с адресом протокола IPv4. Например, запрос A-записи на имя referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.
• Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.
• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) используется для перенаправления на другое имя.
• Запись MX (mail exchange) или почтовый обменник указывает сервер(ы) обмена почтой для данного домена.
• Запись NS (name server) указывает на DNS-сервер для данного домена.
• Запись PTR (pointer) или запись указателя связывает IP-адрес хоста с его каноническим именем. Запрос в домене in-addr.arpa на IP-адрес хоста в reverse форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например, (на момент написания) для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.
• Запись SOA (Start of Authority) или начальная запись зоны указывает, на каком сервере хранится эталонная информация о данном домене, содержит контактную информацию лица, ответственного за данную зону, тайминги (параметры времени) кеширования зонной информации и взаимодействия DNS-серверов.
• SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.
• DNAME-запись, используется в ситуациях, когда вам нужно перенаправлять все запросы для домена А в домен Б, но не путать с редиректом, так как в домене Б, обязательно должны быть те записи к которым обращаются из домена А, в противном случае, запросивший получит ошибку, что узел не удалось обнаружить.

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

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

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

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

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

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

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

c:\>ipconfig /displaydns

Windows IP Configuration

api.wordpress.org

----------------------------------------

Record Name . . . . . : api.wordpress.org

Record Type . . . . . : 1

Time To Live  . . . . : 158

Data Length . . . . . : 4

Section . . . . . . . : Answer

A (Host) Record . . . : 72.233.56.138

Record Name . . . . . : ns1.mobiusltd.com

Record Type . . . . . : 1

Time To Live  . . . . : 158

Data Length . . . . . : 4

Section . . . . . . . : Additional

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

Приведу пример использования утилиты NSLookup. Допустим нам надо узнать MX и NS записи  для  домена mail.ru

C:\>nslookup

Default Server:  china-lo-oldnbn.ti.ru

Address:  212.1.224.53

> set type=mx

> mail.ru

Server:  china-lo-oldnbn.ti.ru

Address:  212.1.224.53

Non-authoritative answer:

mail.ru MX preference = 10, mail exchanger = mxs.mail.ru

mail.ru nameserver = ns.mail.ru

mail.ru nameserver = ns1.mail.ru

mail.ru nameserver = ns3.mail.ru

mail.ru nameserver = ns4.mail.ru

mail.ru nameserver = ns5.mail.ru

mail.ru nameserver = ns2.mail.ru

mxs.mail.ru     internet address = 94.100.176.20 n

s4.mail.ru     internet address = 94.100.178.64

ns.mail.ru      internet address = 94.100.178.70

ns1.mail.ru     internet address = 94.100.179.159

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

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

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

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

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

Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.

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

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