Могут ли ответы вспомогательных dns серверов быть авторитетными

Обновлено: 02.07.2024

и для дополнительного кредита-можно ли найти происхождение конфликтующих записей DNS?

вам понадобится запись SOA (Start of Authority) для данного доменного имени, и вот как вы это сделаете, используя универсально доступный команда nslookup инструмент командной строки:

в конце вывода все авторитетные серверы, включая резервное копирование перечислены серверы для данного домена.

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

если вы не имеете в виду" основной сервер имен", а не"авторитетный сервер имен". Вторичные серверы имен are авторитетный.

чтобы узнать серверы имен домена на Unix:

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

здесь два авторитетных сервера имен имеют одинаковый серийный номер. Хороший.

У меня есть инструмент распространения DNS предназначен для ответа на такие вопросы.

источник освобождается под AGPLv3.

(да, интерфейс на данный момент довольно простой :))

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

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

на Linux или Mac, вы можете использовать команды whois , dig , host , nslookup или несколько других. nslookup может также работать в Windows.

Что касается дополнительного кредита: Да, это возможно.

aryeh определенно ошибается, так как его предложение обычно дает вам только IP-адрес для имени хоста. Если вы используете dig , у вас есть для поиска записей NS, например:

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

Я обнаружил, что лучший способ добавить всегда параметр + trace:

Он также работает с рекурсивным CNAME, размещенным в другом провайдере. + трассировка трассировка подразумевает + norecurse, поэтому результат только для указанного домена.

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

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

вы получите следующий ответ.

. текст удален здесь.

вы можете использовать nslookup или копать, чтобы выяснить дополнительные сведения о записях для данного домена. Это может помочь вам разрешить описанные конфликты.

к сожалению, большинство этих инструментов возвращают только запись NS, предоставленную самим сервером имен. Чтобы быть более точным в определении того, какие серверы имен фактически отвечают за домен, вам придется либо использовать "whois" и проверять перечисленные там Домены, либо использовать "dig [domain] NS @[root name server]" и запускать это рекурсивно, пока вы не получите списки серверов имен.

Я хотел бы, чтобы была простая командная строка, которую вы могли бы запустить, чтобы получить этот результат надежно и в согласованном формате, а не только результат, который дается от самого сервера имен. Цель этого для меня - иметь возможность запрашивать около 330 доменных имен, которыми я управляю, чтобы я мог точно определить, на какой сервер имен указывает каждый домен (согласно их настройкам регистратора).

кто-нибудь знает команду, использующую "dig" или "host" или что-то еще на *nix?

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

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

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

(информация о том, какой сервер является авторитетным, для которого TLD может быть запрошен с корневых серверов имен).

когда у вас есть достоверная информация о SOA с сервера TLD authoritative, вы можете запросить сам основной сервер имен authoritative (тот, который находится в записи SOA на сервере имен gTLD!) для любых других записей NS, а затем продолжить проверку всех серверов имен, которые вы получили от запроса записей NS, чтобы увидеть, если есть какие-либо несоответствия для любой другой конкретной записи, на любом из этих серверов.

все это работает намного лучше / надежно с linux и dig, чем с nslookup / windows.

Зонный файл

Зонный файл содержит информацию о различных ресурсах в данной зоне. Информация о каждом ресурсе представлена в записи, называемой Resource Record (RR). Так как зона может содержать несколько доменов и несколько типов ресурсов внутри каждого домена, формат каждой RR содержит поля для указания этой информации. В частности, ресурсная запись состоит из следующих основных полей:

Owner name : имя домена или имя ресурса;
TTL : время жизни в секундах;
Class : существует только один класс IN, обозначающий Интернет;
RRType : тип ресурса;
RData : информация о ресурсе (зависит от RRType);

Некоторые наиболее часто используемые типы ресурсов:

A : адрес. Ресурсная запись данного типа предоставляет IP-адрес имени хоста;
MX : Mail Exchanger. Ресурсная запись данного типа указывает имя хоста почтового сервера для домена;
NS : Name Server. Ресурсная запись данного типа указывает имя хоста name-сервера для домена.

В RFC 1035 приведен полный формат допустимых RRType в DNS. Множество ресурсных записей с одним и тем же именем собственника, TTL, классом и RRType называется RRSet. Следовательно, логически зонный файл можно представить состоящим из нескольких RRSets.

Name-серверы

Авторитетные name-серверы

Кэширующие name-серверы

Кэширующий name-сервер обычно является локальным name-сервером, выполняющим функции разрешения имен для различных клиентов. Кэширующий name-сервер также является рекурсивным name-сервером. Функция разрешения имен выполняется кэширующим name-сервером в ответ на запросы от stub resolver’а. Процесс поиска, выполняемый при разрешении имен, означает либо поиск в своем собственном кэше, либо последовательность запросов к различным авторитетным серверам.

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

Resolver’ы

Такое ПО, как web-браузеры и e-mail клиенты, которые требуют доступа к ресурсам Интернета, используют DNS-клиент, называемый client resolver или stub resolver. Stub resolver формулирует запрос на разрешение имени для ресурса, который отыскивается в Интернете, и посылает этот запрос кэширующему name-серверу. Как правило, stub resolver сконфигурирован таким образом, чтобы иметь список кэширующих name-серверов для обеспечения большей надежности данной операции. Stub resolver обычно называется просто resolver’ом. Кэширующий name-сервер, который получил запрос от stub resolver’а, также формирует запросы для посылки их авторитетным name-серверам (если он не может ответить на запрос из своего кэша), и, следовательно, также иногда указывается как resolver, потому что он имеет рекурсивную компоненту и компоненту кэширования.

Интернет-корпорация по присвоению имен и номеров (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 серверов: рекурсивные резолверы, корневые серверы DNS, серверы имен TLD, авторитетные серверы имен. Что такое? Принцип работы

Все DNS-серверы делятся на четыре категории:

Что такое рекурсивный резолвер DNS?

Рекурсивный резолвер (также известный как DNS-рекурсор) является первой остановкой в DNS-запросе. Рекурсивный резолвер действует как посредник между клиентом и DNS-сервером.

После получения DNS-запроса от веб-клиента рекурсивный резолвер либо ответит кэшированными данными, либо отправит запрос корневому серверу имен, за которым последует еще один запрос серверу имен TLD, а затем последний запрос авторитетному серверу имен.

После получения ответа от авторитетного сервера, содержащего запрошенный IP-адрес, рекурсивный резолвер отправляет ответ клиенту.

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

Большинство пользователей интернета используют рекурсивный резолвер, предоставляемый их провайдером (DNS от BYFLY для Беларуси), но есть и другие варианты, например, Cloudflare 1.1.1.1.

Что такое корневой DNS-сервер имен

Что такое сервер имен TLD?

DNS-сервер TLD

Управление серверами имен доменов верхнего уровня осуществляется органом по назначенным номерам интернета (IANA), который является филиалом ICANN. IANA разбивает серверы TLD на две основные группы:

Существует третья категория доменов, но она почти никогда не используется. Эта категория была создана для .arpa, который был переходным доменом, используемым при создании современных DNS. Его значение сегодня в основном историческое.

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