Authoritative dns server что это
Продолжение и дополнительный материал
Для продолжения знакомства с DNS рекомендуются следующие статьи:
[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]
Перенаправляющие (Forwarding) DNS-сервера
Альтернативный подход к накоплению кеша для клиентских машин — использование перенаправляющего DNS-сервера. Этот подход добавляет ещё одно звено в цепочку разрешения DNS, которым является Forwarding сервер, который просто передаёт все запросы другому DNS-серверу с рекурсивными возможностями (например, кеширующему DNS-серверу).
Преимущество этой системы состоит в том, что она может дать вам преимущество локально доступного кэша, не выполняя рекурсивную работу (что может привести к дополнительному сетевому трафику и может занять значительные ресурсы на серверах с высоким трафиком). Это также может привести к некоторой интересной гибкости в разделении вашего частного и публичного трафика путём пересылки на разные серверы.
Перенаправляющий (Forwarding) DNS-сервер имеет следующие свойства:
- Способность обрабатывать рекурсивные запросы без выполнения самой рекурсии. Наиболее фундаментальным свойством сервера пересылки DNS является то, что он передаёт запросы другому агенту для разрешения. Сервер пересылки может иметь минимальные ресурсы и при этом эффективно использовать свою кеш-память.
- Предоставлять локальный кеш в ближайшем сетевом расположении. В частности, если вы не хотите создавать, поддерживать и защищать полноценное рекурсивное DNS-решение, сервер пересылки может использовать общедоступные рекурсивные DNS-серверы. Он может использовать эти серверы, перемещая основное место кэширования очень близко к клиентским машинам. Это может уменьшить время ответа.
- Увеличивает гибкость в определении локального доменного пространства. Передавая запросы на разные серверы в зависимости от определённых условий, перенаправляющий сервер может гарантировать, что внутренние запросы обслуживаются приватными серверами, в то время как внешние запросы используют общедоступный DNS.
Conclusion
So now you are familiar with what the Authoritative DNS server actually is and its crucial purpose! Its ability to provide authoritative answers to the DNS requests (DNS queries) is one of the key fundamentals of the entire DNS (Domain Name System) and the Internet as well!
What is Authoritative Name Server? - The Authoritative DNS server is the final holder of the IP of the domain you are looking for. It is the name server which has the original zone records.
How to get Authoritative DNS server for a domain?
It is actually very easy to get the Authoritative DNS server for a domain name. Here we are going to show you how by using popular tools such as Dig, NSlookup, Host, and WHOIS.
We are going to use the Dig command and request the NS records, where NS stands for nameserver. Therefore, this DNS record is going to show us which are the authoritative DNS servers for the particular domain name or DNS zone.
Type the following:
NSlookup is another popular tool that can help you get the Authoritative DNS server for a domain name or a DNS zone. It works on Windows, Linux, and macOS. Once again, we are going to query the NS records.
Simply type the following:
Host command is a beneficial tool that you can use on your Linux or macOS device. For our purpose, to get a list of the Authoritative DNS servers, we should request the NS record.
Just write the following:
With the WHOIS command, you can get a list of the Authoritative DNS servers too.
Write the following:
Authoritative DNS server
Such a server is the name server, which has the original zone records. It has been configured from the original source, and it returns answers to queries that have been predetermined by the administrator.
These DNS servers are giving responses to queries just for the zones they are configured. This makes them very efficient and fast. They will not respond to recursive queries too. The requests that reach them are from Resolving name servers (resolvers) and the authoritative servers will either have the complete answer or they will pass to the name server who is responsible for it.
The authoritative servers don’t cache query results. They have data that is saved in their system.
It can be master or slave. It can store the original zones records, or a secondary server which communicates directly with the primary and copies the records directly through a DNS mechanism.
The authoritative DNS servers can be where the website is hosted or where the DNS provider is.
Комбинированные решения
Несмотря на то, что вышеупомянутые решения построены с очень конкретными целями, часто возникает желание настроить DNS-сервер так, чтобы сочетать преимущества каждого из них.
DNS-сервер может быть настроен для работы в качестве рекурсивного сервера кэширования для выбранного количества локальных клиентов, отвечая только на итеративные, авторитетные запросы от других клиентов. Это обычная конфигурация, поскольку она позволяет вам отвечать на глобальные запросы для вашего домена, а также позволяет вашим локальным клиентам использовать сервер для рекурсивного разрешения.
Хотя соответствующее программное обеспечение DNS специально разработано для выполнения одной конкретной роли, такие приложения, как Bind, невероятно гибки и могут использоваться в качестве гибридных решений. Хотя в некоторых случаях попытка предоставить слишком много услуг на одном сервере может привести к снижению производительности, во многих случаях, особенно в случае небольшой инфраструктуры, наиболее целесообразно поддерживать единое решение «все в одном».
Путь DNS-запроса
Когда клиентская программа хочет получить доступ к серверу по его доменному имени, она должна выяснить, как преобразовать доменное имя в фактический маршрутизируемый адрес, который она может использовать для связи. Необходимо знать эту информацию, чтобы отправлять информацию на сервер и получать от него ответ.
Некоторые приложения, в том числе большинство веб-браузеров, поддерживают внутренний кеш последних запросов. Если в нём есть такая функциональность, то это первое место, где приложение попытается найти IP-адрес домена, к которому нужно подключиться. Если оно не находит ответа на свой вопрос здесь, оно просит системного распознавателя (resolver — резолвер) выяснить, каков адрес доменного имени.
Затем рекурсивный сервер следует по пути отсылок к каждому последующему серверу имён, которому делегирована ответственность за компоненты домена, до тех пор, пока он не найдёт конкретный сервер имён, который имеет полный ответ. Он помещает этот ответ в кэш для последующих запросов, а затем возвращает его клиенту.
Как видно из этого примера, существует много разных типов серверов, и каждый из них играет свою роль. Давайте рассмотрим особенности различных типов DNS-серверов.
Различия в отношениях
Хотя, вероятно, функциональными различия являются наиболее очевидные между конфигурациями DNS-серверов, реляционные различия также чрезвычайно важны.
Источник
Рекомендуется Вам:
Функциональные различия
Некоторые из различий между DNS-серверами являются чисто функциональными. Большинство серверов, участвующих в реализации DNS, специализируются на определённых функциях. Тип DNS-сервера, который вы выберете, будет во многом зависеть от ваших потребностей и типа проблемы, которую вы надеетесь решить.
Заключение
Итак, теперь мы знаем, что если возникла необходимость настроить свой DNS сервер, то нужно определиться — какой именно DNS сервер нам нужен, поскольку существуют различные варианты.
Перенаправляющий/кэширующий DNS-сервер можно настроить даже на домашнем компьютере Linux. Такой сервер может полностью заменить файл /etc/hosts для обращения к ресурсам локальной сети. А при поступлении запросов для получения IP доменных имён, этот сервер будет получать данные от внешнего кэширующего сервера (например, 8.8.8.8 и 8.8.4.4 — DNS-серверы от Google) и сохранять полученные ответы в своём кэше — это в том случае, если вы настроили перенаправляющий DNS-сервер. Если же вы выберите рекурсивный кэширующий DNS-сервер, то он будет делать несколько запросов, начиная с корневых DNS-серверов и получать в конечном счёте ответы исключительно от авторитативных DNS-серверов (а не от сторонних кэширующих серверов, как это обычно происходит). Полученные данные также будут храниться в кэше. В случае повторных запросов этих имён, локальный DNS сервер их будет брать из кэша, что может немного ускорить работу сети.
В наших следующих руководствах (смотрите ссылки ниже) мы покажем, как начать работу с некоторыми из этих конфигураций. Мы начнём с обучения настройке кэширующего и перенаправляющего DNS-сервера. Позже мы расскажем о том, как обслуживать ваши домены, настроив пару DNS серверов с только авторитативной функцией (Authoritative-Only).
2 комментария to Сравнение типов DNS серверов: как выбрать правильную конфигурацию DNS
великолепные статьи, ничего лишнего и в то же время все развернуто. уже несколько дней читаю сайт, хотя искал материал изначально только по IPv6.
перенаправляющий/кэширующий DNS-сервер это тот, который обращается к публичным кэширующим DNS, например 8.8.8.8 или 1.1.1.1 а те, в свою очередь, к корневым DNS серверам,
а рекурсивный кэширующий DNS-сервер этот тот, который напрямую обращается к корневым DNS серверам минуя публичные кэширующие (это утверждение верно?), то есть 8.8.8.8 или 1.1.1.1, фактически, рекурсивный кэширующий DNS-сервер - это тот же сервер что преоставляется Google в рамках сервиса Google Public DNS, верно ли я понял,
а статья "Как настроить рекурсивный кэширующий или перенаправляющий DNS-сервер" еще ожидается к выходу?
Alexey :
перенаправляющий/кэширующий DNS-сервер это тот, который обращается к публичным кэширующим DNS, например 8.8.8.8 или 1.1.1.1 а те, в свою очередь, к корневым DNS серверам,
Да, например это dnscrypt-proxy, работающий на локальном компьютере (пример настройки в этой статье).
а статья "Как настроить рекурсивный кэширующий или перенаправляющий DNS-сервер" еще ожидается к выходу?
К сожалению не могу ничего сказать о сроках (((((( В принципе, таких инструкций уже написано достаточно много на русском и английском языках.
В данном материале разбирается типизация DNS серверов по их назначению, рассматриваются основной функционал серверов каждого типа и его значение для надежной и эффективной работы системы доменных имен.
В данном материале разбирается типизация DNS серверов по их назначению, рассматриваются основной функционал серверов каждого типа и его значение для надежной и эффективной работы системы доменных имен. Прежде чем приступить к чтению данного материала, необходимо ознакомиться с материалом "Как работает система доменных имен".
Сразу оговоримся, что в данном материале речь не идет о серверах, как о программах, которые реализуют функцию сервера доменных имен, например named или сервер доменных имен Windows Server 2000. Мы будем рассматривать серверы, как процессы, которые должны выполнять определенные функции по обслуживанию DNS запросов.
В документах RFC-1034 и RFC-1035 выделяют несколько типов DNS-серверов. В соответствии с типами откликов на запрос к системе доменных имен серверы можно разделить на авторитативные (authoritative) и неавторитативные (non authoritative).
Авторитативный отклик (authoritative response) возвращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая resolver-у (клиент DNS).
Неавторитативный отклик (non authoritative response) возвращают серверы, которые не отвечают за зону, содержащую необходимую resolver информацию.
Авторитативный отклик могут, в свою очередь, вернуть либо master-сервер зоны (primary server), либо slave-сервер (secondary server) зоны. В русскоязычной литературе их называют основным и дублирующим серверами (или первичным и вторичным, соответственно).
Master-сервер (primary, первичный) доменных имен является ответственным (authoritative) за информацию о зоне в том смысле, что читает описание зоны с локального диска компьютера, на котором он функционирует и отвечает в соответствии с этим описанием на запросы resolver-ов. Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера. Вообще говоря, такое определение несколько устарело, и позже будет ясно почему. Но при настройках реальных серверов мы будем использовать именно это определение.
Для зоны можно определить только один master-сервер, т.к. первоисточник может и должен быть только один.
Slave-сервер (secondary, вторичный, дублирующий) также является ответственным (authoritative) за зону. Его основное назначение заключается в том, чтобы подстраховать работу основного сервера доменных имен (master server), ответственного за зону, на случай его выхода из строя, а также для того, чтобы разгрузить основной сервер, приняв часть запросов на себя. Так, например, из 13 серверов, которые обслуживают корневую зону, 12 являются slave-серверами.
Администратор slave-сервера не прописывает данные описания зоны. Он только обеспечивает настройку своего сервера таким образом, чтобы его сервер копировал описание зоны с master-сервера, поддерживая его (описание зоны) в актуальном согласованном с master-сервером состоянии.
Обычно, время согласования описания зоны между slave-сервером и master-сервером задается администратором master-сервера в описании зоны. Slave-сервер в момент своего запуска копирует это описание и затем руководствуется им при обновлении информации о зоне. Slave-сервера периодически через заданный интервал времени опрашивают master-сервер на предмет изменения описания зоны. Если изменения имеют место быть, то описание зоны копируется на slave-сервер.
Спецификация DNS позволяет реализовать и другой механизм обновления информации - оповещение об изменениях. В этом случае инициатива обновления описаний зоны на slave-серверах принадлежит не этим серверам, а master-серверу. Последний оповещает slave-серверы от том, что в базу были внесены изменения, и необходимо эти изменения скопировать на slave-серверы.
Существует оговоренная практика резервирования серверов, которая описана в рекомендациях по ведению зон. Она заключается в том, что для домена второго уровня необходимо иметь как минимум два сервера, ответственных за зону, т.е. дающих авторитативные отклики на запросы. Один master-сервер и один slave-сервер. При этом эти серверы должны иметь независимые подключения к Интернет, чтобы обеспечить бесперебойное обслуживание запросов к зоне в случае потери связи с одним из сегментов сети, в котором находится один из серверов.
Рис.1. Схема подключения master и slave серверов зоны
Размещение обоих серверов на площадке регистратора, например, ru-center, также обеспечивает независимое подключение серверов, т.к. обычно регистратор имеет несколько точек подключения к Интернет.
Как уже было сказано, slave-сервер копирует описание зоны c master-сервера. В настоящее время существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
В современных RFC, которые расширяют толкование механизмов взаимодействия между участниками обмена данными в рамках DNS, типизацию серверов и их разделение на master-серверы и slave-серверы дают относительно процедур копирования зоны.
Так slave-сервером называют сервер, который использует механизм передачи зоны для получения копии зоны, а master-сервером называют сервер, с которого осуществляется копирование зоны. При этом зону можно скопировать с любого сервера, который является авторитативным. Т.е. зону можно скопировать и со slave-сервера, который относительно самой процедуры копирования зоны будет считаться master-сервером. Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master. Этот сервер для зоны только один, и он находится в корне процедуры копирования описания зоны.
Типизация серверов относительно процедуры обмена описаниями зон связана с возможностями, которые не описаны в RFC-1034 и RFC-1035, и, соответственно, не поддерживались в ранних версиях программ-серверов доменных имен. Это механизм объявлений об изменениях в описании зоны (RFC-1996), динамическое обновление описания зоны (RFC-2136) и инкрементальное обновление описания зоны (RFC-1995).
Для большинства администраторов корпоративных доменов все эти новшества, возможно, любопытны, но в реальной жизни не слишком полезны, т.к. вся их мощь проявляется только при работе с динамичными описаниями зон, информация в которых подвержена постоянным изменениям. Тем не менее, не сказать о них нельзя, т.к. при работе современными версиями программ-серверов обязательно возникнут вопросы типа "а чтобы это значило".
Сначала о том, что такое уведомления об изменениях описания зоны (DNS NOTIFY). Идея достаточно проста и проистекает из проблемы распространения изменений, внесенных в описание зоны при ее редактировании. Дело в том, что slave-серверы при традиционной работе опрашивают master-сервер (в данном контексте primary master) на предмет изменения в описании зоны через определенные промежутки времени, которые задаются в описании зоны. Возможна ситуация, когда изменения были внесены в зону сразу после ее копирования slave-сервером. В этом случае новая информация появится на всех slave-серверах только при следующем обновлении зоны.
О том, что обозначают другие позиции этих отчетов, мы поговорим тогда, когда будем обсуждать описание зоны (запись SOA), а пока только заметим, что внесение изменений в описание зоны не приводит к появлению возможности мгновенного их использования.
Таким образом, механизм уведомления об изменениях в описании зоны необходим для ускорения введения в жизнь сделанных изменений.
Принцип работы DNS NOTIFY следующий:
- В базу данных primary master вносятся изменения (руками с последующей перезагрузкой сервера или динамически по протоколу динамического обновления зоны).
- Primary master оповещает свои slave о том, что произошли изменения, сообщая им номер версии описания зоны.
- Slave запрашивает с primary master описание зоны и, если номера версии описаний зоны не совпадают (на primary master номер больше), то инициирует процесс обновления описания зоны.
- Завершив обновление описания зоны, slave посылает оповещения на известные ему авторитативные сервера зоны.
На рисунке пояснется работы приведенной выше схемы:
Рис.2. Схема работы DNS NOTIFY
На рисунке 2 primary master является для обоих slave-серверов master-сервером c точки зрения процедуры передачи зоны. Но в принципе, для одного из серверов он может быть и не определен в качестве master-сервера. В этом случае появляется дополнительное звено в дереве зависимости обмена данными зоны. В этом случае изменения будут передаваться от сервера к серверу так, как это показано на рисунке 3:
Рис.3. Схема работы DNS NOTIFY при двухзвенном оповещении об изменении описания зоны.
Теперь поясним механизм динамического обновления описания зоны (Dynamic Updates или DNS UPDATE). Изначально описание зоны было, да и до сих пор в большинстве случаев остается, статическим. Это значит, что есть на Primary master файл описания зоны, в который администратор вручную или при помощи скриптов изменения содержания файла вносит изменения. Для того чтобы они стали актуальными, т.е. их увидели resolver-ы, необходима перезагрузка сервера. Идея динамического обновления описания зоны состоит в том, чтобы, во-первых, вносить изменения в описание зоны без перезагрузки сервера, а, во-вторых, делать это удаленно, т.е. администратору не нужно получать доступ к файлам описания зон ни для ручного редактирования, ни для скриптов. Тем самым класс клиентов в модели "клиент-сервер" в рамках DNS обмена расширяется на группу клиентов администрирования.
Когда актуально динамическое обновление зоны? Чаще всего необходимость динамического обновления связывают с работой по протоколу DHCP (Dynamic Host Configuration Protocol, RFC-1541). DHCP Позволяет динамически назначать компьютерам IP-адреса, маски, IP-адреса шлюзов, доменные имена и т.п., т.е. передавать хостам данные без которых невозможна работа в сетях TCP/IP.
DHCP существенно облегчает работу сетевого администратора, которому не нужно настраивать каждый компьютер, подключенный к сети, вручную. Динамическое именование влечет за собой постоянное изменение информации в описании зоны.
Динамическое обновление позволяет авторизованным клиентам посылать запросы на динамическое обновление описания зоны серверам, которые являются авторитативными для соответствующей зоны. Обратите внимание, что запросы могут направляться как master-серверам, т.к. slave-серверам.
Если сервер не является Primary master-сервером зоны, то он отправляет (ретранслирует) запрос на обновление своему master-серверу. Таким образом запрос на обнавление достигает Primary master-сервера зоны.
Как только Primary master-сервер совершит обновление описания зоны, он может по механизму DNS NOTIFY оповестить об этом slave-серверы, которые, в свою очередь, обновят свои описания зоны.
В рамках динамического обновления можно удалять и добавлять отдельные записи описания ресурсов в описания зоны, наборы записей описания ресурсов, выделенных по определенному признаку, скажем записи определенного типа, или записи связанные с определенным доменом. Возможно редактирование описания зоны по условию.
Для того, чтобы успешно выполнялись обмены со slave-серверами, при каждом изменении зоны изменяется и номер ее версии. Это позволяет slave-серверам поддерживать свои описания зоны в актуальном, согласованном с Primary master-сервером состоянии.
Динамическое обновление описания зоны порождает другую проблему - многократную передачу по сети описания зоны между master-серверами и slave-серверами. Если описание зоны большое, то и объем трафика, который передается по сети, будет немаленький.
При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т.к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.
При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.
Для того, чтобы не передавать всю зону, а передавать только изменения предназначен механизм инкрементальной передачи описания зоны (IXFR, RFC-1995). В рамках обмена передаются номера версий описаний зон и записи, которые нужно добавить или удалить. Принцип простой - сначала идут номер старой версии и список записей, которые нужно удалить, а потом номер более свежей версии и записи, которые нужно добавить.
Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.
В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о "невидимых" серверах (stealth, см. RFC-1996). Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т.к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.
Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.
Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall. В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с "невидимого" Primary master:
Рис.4. Схема организации DNS-серверов с невидимым primary master сервером
Рассмотрим еще один тип серверов, которые выделяют при описании системы доменных имен - кэширующие (cache) серверы. Этот тип серверов отличается от тех, что мы обсудили раньше, тем, что сервер данного типа не является авторитативным для какой-либо зоны.
Серверы данного вида используют для организации централизованного кеширования соответствий доменных имен и IP-адресов. Идея организации кэширующего сервера состоит в том, чтобы на искать соответствие доменного имени и IP-адреса в сети, а накапливать их в своем локальном кэше и обслуживать от туда запросы relover-ов.
Кэш-сервер не поддерживает описаний зон и, соответственно, не посылает resolver-ам авторитативных откликов:
Выше приведен типичный отклик кэширующего сервера на запрос nslookup об адресе www.w3.org. Если бы сервер был авторитативным, то строчки "Non-authoritative answer" в отклике мы бы не увидели.
Мы не обсудили еще один тип серверов - это сервера, которые обслуживают корневую зону (Root servers). Их место в получении отклика на запрос к системе доменных имен ключевое. Именно к одному из корневых серверов обращается локальный сервер доменных имен, если не находит в зоне своей ответственности или в своем кэше соответствия между доменным именем и IP-адресом.
Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:
> .
Server: [144.206.192.60]
Address: 144.206.192.60
И еще несколько слов о root серверах в заключении этого раздела. Существует такая организация - IEPG (Internet Operational Group), задача которой помогать Интернет Сервис Провайдерам взаимодействовать в Сети Интернет. В 1999 году на очередной встрече этой группы обсуждались проблемы DNS И приводилась некоторая статистика по запросам к root серверам:
Средние цифры таковы:
Распределение запросов по типам:
Поиск IP-адреса(A) 77%
Поиск сервера доменных имен (NS) 15%
Поиск почтового шлюза(MX) 5%
Статистика обслуживания запросов, которая названа ужасающей(Scary statistics):
- Только 26% правильных(valid) запросов к корневой зоне.
- 66% запросов к несуществующим доменам верхнего уровня (non existent TLDs)
По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствие негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду.
Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности приреализации протоколов.
К слову сказать, в 2002 году на встрече IEGP также обсуждались проблемы DNS, а точнее масштаб ошибок при делегировании и описании зон.
Сразу оговоримся, что в данном материале речь не идет о серверах, как о программах, которые реализуют функцию сервера доменных имен, например named или сервер доменных имен Windows Server 2000. Мы будем рассматривать серверы, как процессы, которые должны выполнять определенные функции по обслуживанию DNS запросов.
В документах RFC-1034 и RFC-1035 выделяют несколько типов DNS-серверов. В соответствии с типами откликов на запрос к системе доменных имен серверы можно разделить на авторитативные (authoritative) и неавторитативные (non authoritative).
Авторитативный отклик (authoritative response) возвращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая resolver-у (клиент DNS).
Неавторитативный отклик (non authoritative response) возвращают серверы, которые не отвечают за зону, содержащую необходимую resolver информацию.
Авторитативный отклик могут, в свою очередь, вернуть либо master-сервер зоны (primary server), либо slave-сервер (secondary server) зоны. В русскоязычной литературе их называют основным и дублирующим серверами (или первичным и вторичным, соответственно).
Master-сервер (primary, первичный) доменных имен является ответственным (authoritative) за информацию о зоне в том смысле, что читает описание зоны с локального диска компьютера, на котором он функционирует и отвечает в соответствии с этим описанием на запросы resolver-ов. Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера. Вообще говоря, такое определение несколько устарело, и позже будет ясно почему. Но при настройках реальных серверов мы будем использовать именно это определение.
Для зоны можно определить только один master-сервер, т.к. первоисточник может и должен быть только один.
Slave-сервер (secondary, вторичный, дублирующий) также является ответственным (authoritative) за зону. Его основное назначение заключается в том, чтобы подстраховать работу основного сервера доменных имен (master server), ответственного за зону, на случай его выхода из строя, а также для того, чтобы разгрузить основной сервер, приняв часть запросов на себя. Так, например, из 13 серверов, которые обслуживают корневую зону, 12 являются slave-серверами.
Администратор slave-сервера не прописывает данные описания зоны. Он только обеспечивает настройку своего сервера таким образом, чтобы его сервер копировал описание зоны с master-сервера, поддерживая его (описание зоны) в актуальном согласованном с master-сервером состоянии.
Обычно, время согласования описания зоны между slave-сервером и master-сервером задается администратором master-сервера в описании зоны. Slave-сервер в момент своего запуска копирует это описание и затем руководствуется им при обновлении информации о зоне. Slave-сервера периодически через заданный интервал времени опрашивают master-сервер на предмет изменения описания зоны. Если изменения имеют место быть, то описание зоны копируется на slave-сервер.
Спецификация DNS позволяет реализовать и другой механизм обновления информации - оповещение об изменениях. В этом случае инициатива обновления описаний зоны на slave-серверах принадлежит не этим серверам, а master-серверу. Последний оповещает slave-серверы от том, что в базу были внесены изменения, и необходимо эти изменения скопировать на slave-серверы.
Существует оговоренная практика резервирования серверов, которая описана в рекомендациях по ведению зон. Она заключается в том, что для домена второго уровня необходимо иметь как минимум два сервера, ответственных за зону, т.е. дающих авторитативные отклики на запросы. Один master-сервер и один slave-сервер. При этом эти серверы должны иметь независимые подключения к Интернет, чтобы обеспечить бесперебойное обслуживание запросов к зоне в случае потери связи с одним из сегментов сети, в котором находится один из серверов.
Рис.1. Схема подключения master и slave серверов зоны
Размещение обоих серверов на площадке регистратора, например, ru-center, также обеспечивает независимое подключение серверов, т.к. обычно регистратор имеет несколько точек подключения к Интернет.
Как уже было сказано, slave-сервер копирует описание зоны c master-сервера. В настоящее время существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
В современных RFC, которые расширяют толкование механизмов взаимодействия между участниками обмена данными в рамках DNS, типизацию серверов и их разделение на master-серверы и slave-серверы дают относительно процедур копирования зоны.
Так slave-сервером называют сервер, который использует механизм передачи зоны для получения копии зоны, а master-сервером называют сервер, с которого осуществляется копирование зоны. При этом зону можно скопировать с любого сервера, который является авторитативным. Т.е. зону можно скопировать и со slave-сервера, который относительно самой процедуры копирования зоны будет считаться master-сервером. Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master. Этот сервер для зоны только один, и он находится в корне процедуры копирования описания зоны.
Типизация серверов относительно процедуры обмена описаниями зон связана с возможностями, которые не описаны в RFC-1034 и RFC-1035, и, соответственно, не поддерживались в ранних версиях программ-серверов доменных имен. Это механизм объявлений об изменениях в описании зоны (RFC-1996), динамическое обновление описания зоны (RFC-2136) и инкрементальное обновление описания зоны (RFC-1995).
Для большинства администраторов корпоративных доменов все эти новшества, возможно, любопытны, но в реальной жизни не слишком полезны, т.к. вся их мощь проявляется только при работе с динамичными описаниями зон, информация в которых подвержена постоянным изменениям. Тем не менее, не сказать о них нельзя, т.к. при работе современными версиями программ-серверов обязательно возникнут вопросы типа "а чтобы это значило".
Сначала о том, что такое уведомления об изменениях описания зоны (DNS NOTIFY). Идея достаточно проста и проистекает из проблемы распространения изменений, внесенных в описание зоны при ее редактировании. Дело в том, что slave-серверы при традиционной работе опрашивают master-сервер (в данном контексте primary master) на предмет изменения в описании зоны через определенные промежутки времени, которые задаются в описании зоны. Возможна ситуация, когда изменения были внесены в зону сразу после ее копирования slave-сервером. В этом случае новая информация появится на всех slave-серверах только при следующем обновлении зоны.
О том, что обозначают другие позиции этих отчетов, мы поговорим тогда, когда будем обсуждать описание зоны (запись SOA), а пока только заметим, что внесение изменений в описание зоны не приводит к появлению возможности мгновенного их использования.
Таким образом, механизм уведомления об изменениях в описании зоны необходим для ускорения введения в жизнь сделанных изменений.
Принцип работы DNS NOTIFY следующий:
- В базу данных primary master вносятся изменения (руками с последующей перезагрузкой сервера или динамически по протоколу динамического обновления зоны).
- Primary master оповещает свои slave о том, что произошли изменения, сообщая им номер версии описания зоны.
- Slave запрашивает с primary master описание зоны и, если номера версии описаний зоны не совпадают (на primary master номер больше), то инициирует процесс обновления описания зоны.
- Завершив обновление описания зоны, slave посылает оповещения на известные ему авторитативные сервера зоны.
На рисунке пояснется работы приведенной выше схемы:
Рис.2. Схема работы DNS NOTIFY
На рисунке 2 primary master является для обоих slave-серверов master-сервером c точки зрения процедуры передачи зоны. Но в принципе, для одного из серверов он может быть и не определен в качестве master-сервера. В этом случае появляется дополнительное звено в дереве зависимости обмена данными зоны. В этом случае изменения будут передаваться от сервера к серверу так, как это показано на рисунке 3:
Рис.3. Схема работы DNS NOTIFY при двухзвенном оповещении об изменении описания зоны.
Теперь поясним механизм динамического обновления описания зоны (Dynamic Updates или DNS UPDATE). Изначально описание зоны было, да и до сих пор в большинстве случаев остается, статическим. Это значит, что есть на Primary master файл описания зоны, в который администратор вручную или при помощи скриптов изменения содержания файла вносит изменения. Для того чтобы они стали актуальными, т.е. их увидели resolver-ы, необходима перезагрузка сервера. Идея динамического обновления описания зоны состоит в том, чтобы, во-первых, вносить изменения в описание зоны без перезагрузки сервера, а, во-вторых, делать это удаленно, т.е. администратору не нужно получать доступ к файлам описания зон ни для ручного редактирования, ни для скриптов. Тем самым класс клиентов в модели "клиент-сервер" в рамках DNS обмена расширяется на группу клиентов администрирования.
Когда актуально динамическое обновление зоны? Чаще всего необходимость динамического обновления связывают с работой по протоколу DHCP (Dynamic Host Configuration Protocol, RFC-1541). DHCP Позволяет динамически назначать компьютерам IP-адреса, маски, IP-адреса шлюзов, доменные имена и т.п., т.е. передавать хостам данные без которых невозможна работа в сетях TCP/IP.
DHCP существенно облегчает работу сетевого администратора, которому не нужно настраивать каждый компьютер, подключенный к сети, вручную. Динамическое именование влечет за собой постоянное изменение информации в описании зоны.
Динамическое обновление позволяет авторизованным клиентам посылать запросы на динамическое обновление описания зоны серверам, которые являются авторитативными для соответствующей зоны. Обратите внимание, что запросы могут направляться как master-серверам, т.к. slave-серверам.
Если сервер не является Primary master-сервером зоны, то он отправляет (ретранслирует) запрос на обновление своему master-серверу. Таким образом запрос на обнавление достигает Primary master-сервера зоны.
Как только Primary master-сервер совершит обновление описания зоны, он может по механизму DNS NOTIFY оповестить об этом slave-серверы, которые, в свою очередь, обновят свои описания зоны.
В рамках динамического обновления можно удалять и добавлять отдельные записи описания ресурсов в описания зоны, наборы записей описания ресурсов, выделенных по определенному признаку, скажем записи определенного типа, или записи связанные с определенным доменом. Возможно редактирование описания зоны по условию.
Для того, чтобы успешно выполнялись обмены со slave-серверами, при каждом изменении зоны изменяется и номер ее версии. Это позволяет slave-серверам поддерживать свои описания зоны в актуальном, согласованном с Primary master-сервером состоянии.
Динамическое обновление описания зоны порождает другую проблему - многократную передачу по сети описания зоны между master-серверами и slave-серверами. Если описание зоны большое, то и объем трафика, который передается по сети, будет немаленький.
При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т.к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.
При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.
Для того, чтобы не передавать всю зону, а передавать только изменения предназначен механизм инкрементальной передачи описания зоны (IXFR, RFC-1995). В рамках обмена передаются номера версий описаний зон и записи, которые нужно добавить или удалить. Принцип простой - сначала идут номер старой версии и список записей, которые нужно удалить, а потом номер более свежей версии и записи, которые нужно добавить.
Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.
В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о "невидимых" серверах (stealth, см. RFC-1996). Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т.к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.
Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.
Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall. В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с "невидимого" Primary master:
Рис.4. Схема организации DNS-серверов с невидимым primary master сервером
Рассмотрим еще один тип серверов, которые выделяют при описании системы доменных имен - кэширующие (cache) серверы. Этот тип серверов отличается от тех, что мы обсудили раньше, тем, что сервер данного типа не является авторитативным для какой-либо зоны.
Серверы данного вида используют для организации централизованного кеширования соответствий доменных имен и IP-адресов. Идея организации кэширующего сервера состоит в том, чтобы на искать соответствие доменного имени и IP-адреса в сети, а накапливать их в своем локальном кэше и обслуживать от туда запросы relover-ов.
Кэш-сервер не поддерживает описаний зон и, соответственно, не посылает resolver-ам авторитативных откликов:
Выше приведен типичный отклик кэширующего сервера на запрос nslookup об адресе www.w3.org. Если бы сервер был авторитативным, то строчки "Non-authoritative answer" в отклике мы бы не увидели.
Мы не обсудили еще один тип серверов - это сервера, которые обслуживают корневую зону (Root servers). Их место в получении отклика на запрос к системе доменных имен ключевое. Именно к одному из корневых серверов обращается локальный сервер доменных имен, если не находит в зоне своей ответственности или в своем кэше соответствия между доменным именем и IP-адресом.
Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:
> .
Server: [144.206.192.60]
Address: 144.206.192.60
И еще несколько слов о root серверах в заключении этого раздела. Существует такая организация - IEPG (Internet Operational Group), задача которой помогать Интернет Сервис Провайдерам взаимодействовать в Сети Интернет. В 1999 году на очередной встрече этой группы обсуждались проблемы DNS И приводилась некоторая статистика по запросам к root серверам:
Средние цифры таковы:
Распределение запросов по типам:
Поиск IP-адреса(A)77%
Поиск сервера доменных имен (NS)15%
Поиск почтового шлюза(MX)5%
Статистика обслуживания запросов, которая названа ужасающей(Scary statistics):
По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствие негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду.
Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности приреализации протоколов.
К слову сказать, в 2002 году на встрече IEGP также обсуждались проблемы DNS, а точнее масштаб ошибок при делегировании и описании зон.
The authoritative DNS server is the final holder of the IP of the domain you are looking for. When you write a domain name in your browser, a DNS query is sent to your internet service provider (ISP). The ISP has a recursive server, which might have the needed information cached in its memory. But if the data is outdated, this recursive server need to find the IP elsewhere. It will try to find it in other recursive servers, but if it can’t, it needs to get the IP address from an authoritative DNS server.
Этичный хакинг и тестирование на проникновение, информационная безопасность
Связанные статьи:
факультете информационной безопасности от GeekBrains? Комплексная годовая программа практического обучения с охватом всех основных тем, а также с дополнительными курсами в подарок. По итогам обучения выдаётся свидетельство установленного образца и сертификат. По этой ссылке специальная скидка на любые факультеты и курсы!
Authoritative DNS server vs. Recursive DNS server
Both Authoritative DNS servers and Recursive DNS servers have crucial functions, and they depend on each other to fulfill their purposes. However, there are some fundamental differences between them.
Authoritative DNS servers store the most recent and accurate information (DNS records) for a domain and are able to provide the final answers for users’ DNS queries (DNS lookups). On the other hand, Recursive DNS servers only keep a copy of the DNS information for a particular amount of time (TTL). Additionally, they often have to obtain the answer for a DNS query from another server.
So let’s explain a little bit more about the differences between them!
An authoritative DNS server is responsible for answering DNS queries for a particular set of DNS zones by providing information from its own data. It does not have the need to reference another source. Most commonly, it replies to the requests with one of the following types of answers:
- Authoritative DNS information (DNS records) from its own store. It could come from a master zone file, from a secondary zone duplicate transferred from a master server, from Dynamic DNS, etc.
- In case it doesn’t know the answer, it is going to direct to another nameserver. For instance, the Root name server points to the responsible TLD (Top-Level Domain) server.
- An authoritative NXDOMAIN. It replies that the requested domain name doesn’t exist.
- An authoritative empty NOERROR (NODATA) answer. The requested domain name exists, but the particular queried DNS record does not.
The Recursive DNS server replies to DNS queries by asking other nameservers for the needed information (DNS records). In some cases, this server responds to DNS requests directly from its cache if the information is available there. In case it is not, the Recursive DNS server, also known as DNS resolver, is going to perform a search and ask the responsible authoritative servers until it finds the needed answer.
Normally, Recursive DNS servers store in their cache memory information about previously queried domain names for further use. That really reduces the network traffic and improves the performance.
Recursive DNS servers normally answer DNS queries in the following way:
- Authoritative DNS information (DNS records) from its own store, if there is any. That could be a positive response, NXDOMAIN, or NOERROR/NODATA.
- Non-authoritative DNS information that is received and cached from a previous recursive DNS query, if there is any.
- Data retrieved from remote authoritative name servers. It can be further cached and reused for answering future DNS queries.
Recursive DNS servers are most commonly used to reply to general DNS queries for users on a local network.
Кеширующий DNS-сервер
Кэширующий DNS-сервер — это сервер, который обрабатывает рекурсивные запросы от клиентов. Почти каждый DNS-сервер, с которым свяжется заглушка обработчика операционной системы, будет кэширующим DNS-сервером.
Чтобы избежать потери производительности при отправке нескольких итеративных запросов другим DNS-серверам каждый раз, когда он получает рекурсивный запрос, сервер кэширует свои результаты. Это позволяет ему иметь доступ к широкой базе информации DNS (общедоступные DNS всего мира) и совмещать это с очень быстрой обработкой последних запросов.
Кэширующий DNS-сервер имеет следующие свойства:
Введение
DNS, или Система доменных имён, является неотъемлемой частью того, как системы соединяются друг с другом для общения в Интернете. Без DNS компьютеры и люди, которые их используют, должны были бы соединяться, используя только числовые адреса, известные как IP-адреса.
Помимо очевидной проблемы запоминания большого количества сложных чисел для простых задач, связь через IP-адреса также вызывает некоторые дополнительные проблемы. Перемещение вашего сайта на другого хостинг-провайдера или перемещение ваших серверов в разные места потребует от вас информирования каждого клиента о новом местоположении.
DNS-серверы (компьютеры, которые вместе образуют систему, позволяющую нам использовать имена вместо IP адресов), могут обслуживать множество различных функций, каждая из которых может способствовать вашей возможности доступа к серверам по имени.
В предыдущем руководстве мы обсудили некоторые основные термины и понятия системы доменных имён. Предполагается, что вы прочитали предыдущую статью. В этом руководстве мы поговорим о некоторых типах настроек DNS-сервера и о преимуществах, вариантах использования и свойствах каждого из них.
Публичные и частные серверы
Часто организации используют DNS как снаружи, так и внутри. Однако информация, которая должна быть доступна в обеих из этих сфер, часто существенно отличается.
Организация может поддерживать доступными из вне DNS серверы с только авторитативной функцией (Authoritative-Only) для обработки публичных DNS-запросов для доменов и зон, которые относятся к их «юрисдикции». Для своих внутренних пользователей организация может запустить отдельный DNS-сервер, который содержит публичную информацию, предоставляемую общедоступным DNS, а также дополнительную информацию о внутренних хостах и службах. Он также может предоставлять дополнительные функции, такие как рекурсия и кэширование для своих внутренних клиентов.
Хотя выше мы упомянули о возможности иметь один сервер для выполнения всех этих задач на «комбинированном» сервере, есть определённые преимущества для разделения рабочей нагрузки. На самом деле, поддержание совершенно отдельных серверов (внутренних и внешних), которые не знают друг друга, обычно является более предпочтительным вариантом. С точки зрения безопасности особенно важно, чтобы на общедоступном сервере не было приватных записей. Это означает не перечислять ваши частные серверы имён с записями NS в публичных файлах зон.
Есть некоторые дополнительные соображения, которые следует иметь в виду. Хотя может быть проще, если ваши общедоступные и частные серверы будут совместно использовать данные зон, которые у них общие, и находится в традиционных отношениях главный-подчиненный (master-slave), это может привести к утечке информации о вашей частной инфраструктуре.
Кроме того, что ваши приватные сервера не должны попадать в сами файлы зон (то есть не должны быть доступны для публичного поиска), также неплохо удалить любые ссылки на приватные сервера в файлах конфигурации публичного сервера. Это означает удаление передачи, уведомлений и сведений о конфигурации, чтобы компрометация общедоступного сервера не означала, что ваши внутренние серверы имён внезапно становятся доступными.
Это означает поддержание отдельных файлов зон для каждого, что может быть дополнительной работой. Однако это может быть необходимо для абсолютного разделения и безопасности.
Основной (Primary) и подчинённый (Slave) серверы
Учитывая важность DNS в обеспечении доступности служб и целых сетей, большинство DNS-серверов, которые являются авторитативными для зоны, будут иметь встроенную избыточность. Существуют различные термины для отношений между этими серверами, но в целом сервер может быть главным (Primary) или подчиненным (Slave) в своей конфигурации.
И главный, и подчинённый серверы являются авторитативными для зон, с которыми они работают. Главный (master) не имеет больше власти над зонами, чем Slave. Единственный различающий фактор между главным и подчиненным серверами — это то, откуда они читают свои файлы зон.
Главный сервер считывает файлы своей зоны из файлов на системном диске, обычно здесь администратор зоны добавляет, редактирует или передаёт исходные файлы зоны.
Подчинённый сервер получает зоны, для которых он является полномочным, посредством передачи зоны от одного из главных серверов для зоны. Как только он получает эти зоны, он помещает их в кеш. Если он должен перезапуститься, он сначала проверяет свой кэш, чтобы увидеть, обновлены ли зоны внутри. Если нет, он запрашивает обновлённую информацию с главного сервера.
Серверы не обязательно должны относиться только к master или только к slave для всех зон, с которыми они работают. Главный или подчинённый статус присваивается по зонам, поэтому сервер может быть ведущим для некоторых зон и ведомым для других.
DNS-зоны обычно имеют как минимум два сервера имён. Любая зона, отвечающая за маршрутизируемую зону Интернета, должна иметь как минимум два сервера имён. Часто для обслуживания повышенной нагрузки и увеличения избыточности используется гораздо больше серверов имён.
DNS серверы с только авторитативной функцией (Authoritative-Only)
Authoritative-Only DNS-сервер — это сервер, который заботится только о том, чтобы отвечать на запросы для зон, за которые он отвечает. Поскольку он не помогает разрешать запросы для внешних зон, он, как правило, очень быстрый и может эффективно обрабатывать много запросов.
Серверы с только авторитативной функцией имеют следующие свойства:
- Очень быстро реагирует на запросы для зон, которые он контролирует. Сервер с только авторитативной функцией будет иметь всю информацию о домене, за который он отвечает, или справочную информацию для зон в домене, которые были делегированы другим серверам имён.
- Не будет отвечать на рекурсивные запросы. Серверы с только авторитативной функцией по своему понятию не предназначены отвечать на них. Это делает его только сервером, а не клиентом в системе DNS. Любой запрос, достигающий Authoritative-Only сервера, обычно поступает от распознавателя (резолвера), получившего ссылку на него, а это означает, что Authoritative-Only сервер либо имеет полный ответ, либо сможет передать новую ссылку на сервер имён, которому была делегирована соответствующая ответственность.
- Не кеширует результаты запроса. Поскольку сервер authoritative-only никогда не запрашивает информацию на других серверах для обработки запроса, то ему просто нечего кэшировать. Вся информация, которую он знает, уже находится в его системе.
Читайте также: