Root hints dns что это
Для системного администратора
Понятие DNS рекурсии
Основная концепция преобразования DNS названий достаточно проста. Каждому веб сайту присваивается уникальный IP адрес. Для доступа к веб сайту клиенту необходимо знать этот IP адрес сайта. Конечно, пользователь обычно не вводит IP адрес в своем браузере Web browser, а вместо этого вводит название домена сайта (domain name). Для доступа к запрашиваемому веб сайту браузер (Web browser) должен уметь преобразовывать название домена сайта (domain name) в соответствующий ему IP адрес. В этом месте в игру вступает DNS. На клиентском компьютере настроен адрес предпочтительного сервера DNS (preferred DNS server). Запрашиваемый URL передается на сервер DNS, а сервер DNS возвращает IP адрес для запрашиваемого веб сайта. После этого клиент может обратиться к запрашиваемому сайту.
Как вы можете увидеть, процесс преобразования название в адрес достаточно краток. Однако, по всему миру существует огромное множество веб сайтов, и новые сайты создаются каждый день. Ваш сервер DNS просто не в состоянии знать IP адрес каждого отдельного веб сайта. Если сервер DNS не знает адрес запрашиваемого сайта, то он использует один из двух методов для определения IP адреса сайта.
Предпочтительный метод преобразования имени в адрес называется рекурсией (recursion). Если говорить в общем, то рекурсия это процесс, при котором сам сервер DNS отправляет запросы на другие сервера DNS, для того чтобы затем по обратной цепочке передать ответ клиенту, который совершил запрос. В общем, DNS сервер становится DNS клиентом. Некоторые администраторы предпочитают отключить рекурсию в целях увеличения производительности. Если рекурсия отключена, то сервер DNS использует процесс, называемый итерация (iteration), для обработки запроса.
Root Hints
Если сервер DNS не знает адрес запрашиваемого сайта, то он передает запрос другому серверу DNS. Для этого сервер DNS server должен знать IP адрес другого сервера DNS, которому он может передать запрос. Это задача корневых подсказок (root hints). Корневые подсказки предоставляют список IP адресов DNS серверов, которые находятся на корневом уровне (root level) иерархии DNS.
Хорошая новость заключается в том, что корневые подсказки (root hints) заранее настроены на DNS серверах, работающих под управлением операционной системы Windows Server 2003. Корневые подсказки (root hints) хранятся в файл под названием CACHE.DNS, который находится в папке \Windows\System32\Dns. Если вы хотите узнать, как выглядят корневые подсказки, то вы можете открыть этот файл в блокноте (Notepad). Как вы можете увидеть на рисунке A, файл с корневыми подсказками представляет собой ничто иное, чем обыкновенный текстовый файл, в котором попарно расположены DNS сервера и их IP адреса.
Рисунок A : Корневые подсказки соответствуют DNS серверам корневого уровня и их IP адресам
Теперь давайте поговорим о том, что такое корневые подсказки, что они делают, а также рассмотрим процесс рекурсии (recursion process) в действии. Диаграмма, изображенная на рисунке B иллюстрирует пример, о котором я хочу вам рассказать.
Рисунок B : Так работает DNS рекурсия (recursion)
Процесс начинается с того, что пользователь вводит URL в своем браузере (Web browser). В нашем примере давайте предположим, что пользователь ввел в качестве URL следующий адрес www.contoso.com. После этого запрос на преобразование названия домена Contoso.com в IP адрес передается на предпочтительный сервер DNS (preferred DNS server), который задан на рабочей станции. Очень часто в КЭШе предпочтительного сервера DNS (preferred DNS server) уже содержится запрашиваемая запись, но в этом примере давайте предположим, что на нашем предпочтительно сервере DNS нет информации относительно сайта CONTOSO.COM.
Если предположить также, что включена DNS рекурсия, то сервер DNS server начинает работать в роли DNS клиента и отправляет серию итерационных запросов на другие сервера DNS. Я объясню разницу между итеративным (iterative) и рекурсивным (recursive) запросом позднее, а сейчас просто представьте, что в целом процесс считается рекурсивным потому, что клиент отправляет лишь один запрос на предпочтительный сервер DNS (preferred DNS server).
В любом случае, предпочтительный сервер DNS на рабочей станции не знает IP адреса веб сайта www.contoso.com, и не знает IP адрес сервера DNS, которые отвечает за домен Contoso.com (а поэтому знает IP адрес сайта www.contoso.com). Все что знает DNS сервер, лишь IP адрес DNS сервера корневого уровня (благодаря файлу с корневыми подсказками). Поэтому предпочтительный сервер DNS (preferred DNS server) передает запрос корневому серверу DNS (root DNS server).
В этом примере необходимо обратить внимание на две вещи. Во-первых, как я уже объяснял ранее, клиент совершает лишь один запрос DNS. Он абсолютно ничего не знает об итеративных запросах сервер DNS. Во-вторых, сервер DNS, который отвечает за домен CONTOSO.COM вовсе не обязательно принадлежит Contoso. Обычно, этот сервер DNS принадлежит компании, занимающейся веб хостингом (Web hosting company) и отвечает за все сайты, принадлежащие этой компании. Именно поэтому предпочтительный сервер DNS (preferred DNS server) не может пропустить один шаг и сразу передать клиенту адрес DNS сервера, который отвечает за домен, по крайней мере не в нашем случае.
Если сервер DNS не поддерживает рекурсивные очереди (recursive queries), то клиент по умолчанию будет выполнять итеративные запросы (iterative queries).
Если вы заинтересованы в достижении лучшей производительности, то должны разрешить вашему серверу DNS отправлять рекурсивные запросы. Причина для этого заключается в том, что если клиенты вынуждены совершать итеративные запросы, то они могут потенциально отправлять три или четыре запроса на сервер DNS в рамках каждого запроса на преобразование имени в IP адрес. Сервер DNS должен обработать все эти запросы рекурсивные или итеративные, но если используется рекурсия (recursion), то большинство запросов на преобразование имен обрабатывается вашим сервером DNS и происходят вдали от вашей сети. В результате этого снижается трафик и улучшается производительность.
Заключение
В этой статье я рассказал о том, как работает рекурсивная очередь DNS (recursive DNS query). Большинство серверов DNS поддерживают, как рекурсивные (recursive), так и итеративные запросы от клиентов. Если вы настроите ваш сервер DNS на поддержку рекурсивных очередей (recursive queries), то в общем сможете добиться лучшей производительности, т.к. благодаря этому можно добиться снижению количества запросов, которые должен совершить сетевой клиент.
Автор: Брайн Позей (Brien Posey)
Взято с netdocs.ru
Этот пост October 23, 2007 at 8:20 pm опубликовал molse в категории DNS. Желающие могут оформить RSS подписку на комменты. Оставьте комментарий(последний комментарий отображается первым) или оставьте трэкбэк. Ccылка на трэкбэк.
Что происходит, когда вы обновляете свой DNS
Fenix by Takeda11
Многие путаются в обновлении записей DNS, когда изменяют IP-адрес своего сайта. Почему эти записи медленно обновляются? Неужели действительно нужно ждать два дня, чтобы всё обновилось? Почему одни посетители видят новый IP, а другие — старый?
Команда Mail.ru Cloud Solutions перевела статью разработчика и автора статей Джулии Эванс, где она отвечает на эти вопросы и популярно рассказывает, что происходит во время обновления DNS с точки зрения фронтендера.
Вот краткое исследование того, что происходит за кулисами, когда вы обновляете запись DNS.
Как работает DNS: рекурсивные и авторитетные DNS-серверы
Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.
Рекурсивные DNS-серверы сами по себе ничего не знают о том, кому принадлежит какой IP-адрес. Они вычисляют IP-адрес для домена, запрашивая его у соответствующих авторитетных DNS-серверов, а затем кэшируют этот IP-адрес на случай, если их снова спросят о нем. Так, 8.8.8.8 — это рекурсивный DNS-сервер.
Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!
Как рекурсивный DNS-сервер запрашивает IP-адрес github.com
Давайте рассмотрим пример того, что делает рекурсивный DNS-сервер (например, 8.8.8.8), когда вы запрашиваете у него IP-адрес (запись А) для github.com. Во-первых, если у него уже есть кэшированный результат, он выдаст его. Но что, если все кэши просрочены? Вот что происходит.
Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).
Шаг 2: Спросить корневые серверы имен о github.com.
Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.
У нас есть новый IP-адрес для отправки запроса! Это один из серверов имен для github.com.
Шаг 4: Спросить у серверов имен github.com об адресе github.com.
Мы почти закончили!
Итак, у нас есть запись А для github.com. Теперь у рекурсивного сервера есть IP-адрес github.com, и он может вернуть его вам. И он смог провернуть всю процедуру, начиная всего с нескольких жестко закодированных IP-адресов: адресов корневых серверов имен.
Как увидеть все шаги рекурсивного DNS-сервера: dig +trace
Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:
Эта команда показывает все DNS-записи, которые запрашивает рекурсивный сервер, начиная с корневых DNS-серверов, то есть все четыре шага, которые мы только что прошли.
Обновим записи DNS
Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.
При обновлении записей DNS существует два основных варианта:
Поговорим о TTL
Но мы забыли кое-что важное. Это TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).
В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:
Это довольно короткий TTL. Теоретически, если бы все DNS-реализации следовали стандарту DNS, это означало бы, что если GitHub решил изменить IP-адрес для github.com, каждый получил бы новый IP-адрес в течение 60 секунд. Давайте посмотрим, как это происходит на практике.
Вариант 1: обновление записи DNS на тех же серверах имен
Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:
Итак, а если мы попытаемся изменить этот IP-адрес? Я изменила его на 5.6.7.8, а затем запустила тот же DNS-запрос:
Похоже, что на этом DNS-сервере запись 1.2.3.4 всё еще кэшируется в течение 144 секунд. Интересно, что если запросить 8.8.8.8 несколько раз, вы получите противоречивые результаты — иногда он выдает новый IP, а иногда старый. Вероятно, 8.8.8.8 на самом деле распределяет нагрузку на кучу разных бэкендов, у каждого из которых собственный кэш.
После пяти минут ожидания все кэши 8.8.8.8 обновились и всегда возвращали новую запись 5.6.7.8. Потрясающе. Это довольно быстро!
Не всегда можно полагаться на TTL
На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.
Вариант 2: обновление ваших серверов имен
Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!
Я не хотела обновлять серверы имен для своего блога, поэтому вместо этого взяла другой свой домен и использовала его в примерах для журнала по HTTP это examplecat.com.
Когда я внесла изменения, мой доменный регистратор несколько зловеще высветил сообщение: «Изменения в examplecat.com сохранены. Они вступят в силу в течение ближайших 48 часов». Затем я установила новую запись A для домена, чтобы она указывала на 1.2.3.4.
Ладно, давайте посмотрим, изменилось ли что-нибудь:
Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:
Но 8.8.8.8 по-прежнему ничего не знает. Причина, по которой 1.1.1.1 видит новый IP, хотя я только что изменила его пять минут назад, вероятно, заключается в том, что никто никогда не спрашивал 1.1.1.1 об этом examplecat.com раньше — значит, у него в кэше ничего не было.
У серверов имен TTL намного больше
Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.
Новый сервер имен определенно возвращает новый IP-адрес для examplecat.com:
Но вспомните, что произошло, когда мы запросили серверы имен github.com раньше:
172 800 секунд — это 48 часов! Таким образом, обновление сервера имен, как правило, занимает гораздо больше времени. Время нужно, чтобы закончился срок действия кэшей и распространился новый адрес. Это гораздо дольше, чем просто обновление IP-адреса без изменения вашего сервера имен.
Как обновляются ваши серверы имен
Библиотека DNS-резолвера вашей программы также может кэшировать записи DNS
Еще одна причина, по которой TTL может не соблюдаться на практике: многие программы должны резолвить DNS-имена, а некоторые программы также будут кэшировать DNS-записи в памяти на неопределенный срок (до тех пор, пока программу не перезапустят).
Например, есть статья о настройке JVM TTL для поиска DNS-имен. Я сама писала не так много кода JVM для поиска DNS, но небольшой поиск в интернете о JVM и DNS создает впечатление, что вы можете настроить JVM так, чтобы он кэшировал каждый поиск DNS в течение бесконечного времени (например, см. этот тикет ElasticSearch).
Вот и всё!
Надеюсь, что это поможет вам понять, что происходит при обновлении вашего DNS.
Оговорюсь, что всю историю распространения DNS определяют не только TTL. Некоторые рекурсивные DNS-серверы наверняка не уважают TTL, даже такие основные серверы как 8.8.8.8. Так что даже если вы просто обновляете запись A, указав маленький TTL, возможно, что на практике всё равно будут приходить запросы на старый IP в течение дня или двух.
Unbound (Русский)
Unbound это удостоверяющий, рекурсивный и кеширующий DNS сервер. Согласно Википедии:
Unbound вытеснил Berkeley Internet Name Domain (BIND) став стандартом как именной сервер в множестве open source проектах, в которых рассматриваются такие преимущества как маленький размер, современность и безопасность.
Contents
Установка
Настройка
Если не указано другое, все нижеописанные опции находятся в секции server конфигурационного файла таким образом:
Локальный DNS сервер
Если вы хотите использовать unbound как ваш локальный DNS сервер, установите в строке nameserver loopback адреса 127.0.0.1 и ::1 :
Удостоверьтесь, что файл /etc/resolv.conf защищен от записи как описано в Domain name resolution (Русский)#Перезапись файла /etc/resolv.conf.
Просмотрите Domain name resolution (Русский)#Утилиты для различных способов проверить ваши настройки
При проверке, удостоверьтесь, что используемый сервер имеет адрес 127.0.0.1 или ::1 после применения изменений в resolv.conf.
В разделе #Переадресация запросов вы можете настроить unbound для переадресации запросов к нужным DNS серверам, если требуется.
Корневые подсказки (Root hints)
Для рекурсивных запросов хоста который не имеет требуемого адреса в кеше, вашему DNS серверу нужно знать адреса корневых DNS серверов, у которых он будет запрашивать адреса DNS серверов доменов верхнего уровня и далее по цепочке, пока не будет достигнут именной сервер, обслуживающий запрашиваемый домен. Для этого требуются корневые подсказки (Root hints), файл содержащий в себе IP адреса корневых DNS серверов. Unbound имеет встроенные корневые подсказки, и если он обновляется регулярно, вмешательства не требуется. С другой стороны хорошей практикой является самостоятельное сопровождение корневых подсказок, так как встроенные могут потерять актуальность.
Для начала укажите unbound путь к файлу root.hints :
Затем, поместите файл root.hints в директорию unbound. Простой способ сделать это можно этой командой:
Если вы все таки используете этот файл вместо встроенных корневых подсказок, для поддержания актуальности нужно обновлять root.hints как минимум раз в шесть месяцев. Вы можете делать это вручную или используя Systemd/Timers. Смотрите пример файла службы в разделе #Служба systemd для обновления корневых подсказок.
Проверка достоверности DNSSEC
Для того, чтобы проверять достоверность домена с помощью DNSSEC, в файле конфигурации требуется указать путь файла trust anchor:
Проверка достоверности DNSSEC будет выполнятся только если запрашиваемый DNS сервер поддерживает эту технологию. Если в #Переадресация запросов были указаны сервера, не поддерживающие DNSSEC, все их ответы на запросы будут рассматриваться как небезопасные, так как невозможно доказать обратное.
Тестирование работоспособности
Для проверки работоспособности DNSSEC, после запуска службы unbound.service выполните:
В ответе должен быть IP адрес и (secure) после него.
Так же вы можете использовать drill для проверки вашего сервера следующими командами:
Переадресация запросов
Если вам необходимо только перенаправлять DNS запросы на внешний DNS сервер, можете сразу перейти к #Переадресация остальных запросов.
Доступ локальной сети к DNS
Используя openresolv
Если ваш сетевой менеджер поддерживает Openresolv (Русский), вы можете настроить его для предоставления доступа локальных DNS серверов и доменов к Unbound:
Настройте Unbound для чтения файла, сгенерированного openresolv и разрешите содержать в ответных сообщениях диапазоны частных IP-адресов[2]:
Вы также можете выключить проверку достоверности DNSSEC для локальных доменов, так как они не могут подтвердить свою достоверность (подробнее RFC 6762 Appendix G):
Исключение приватных диапазонов IP адресов из ответов
Будет полезным исключить из ответов DNS сервера адреса из диапазонов частных IP-адресов, так как это защитит от уязвимости перепривязывания DNS. По умолчанию данная функция не включена, что бы добавить нужную подсеть в список исключения из ответа DNS сервера используйте данный шаблон:
Вы можете добавить эти строки в ваш конфигурационный файл для исключения всего диапазона частных адресов:
Добавить локальный DNS сервер
Для использования локального DNS сервер для прямого и обратного поиска локальных адресов добавьте нужные зоны как показано ниже (выберите нужный IP адрес DNS сервера локальной сети вместо адреса 10.0.0.1 указанного ниже):
Данные строки необходима для работы обратного поиска.
Вы так же можете добавить localhost для переадресации и обратного поиска с помощью следующих строк:
Переадресация остальных запросов
Используя openresolv
Если ваш сетевой менеджер поддерживает Openresolv (Русский), вы можете настроить его для предоставления внешних DNS серверов для Unbound:
Затем настройте Unbound для чтения сгенерированного openresolv файла[3]:
Ручное указание DNS серверов
Переадресация через DNS over TLS
Контроль доступа
Вы можете указать интерфейсы, на которые будет отвечать сервер с помощью IP адреса. По умолчанию принимает запросы только от localhost.
Для прослушивания всех интерфейсов, используйте следующую строку:
Для определения доступа к серверу определенным IP адресам используйте опцию access-control :
действие может быть одним из: deny (игнорирует запросы), refuse (отвечает ошибкой), allow (разрешает рекурсивные запросы), allow_snoop (разрешает рекурсивные и остальные запросы) По умолчанию игнорируются все запросы, кроме от localhost.
Использование
Запуск Unbound
Удаленное управление Unbound
Настройка unbound-control
Перед тем, как начать, необходимо выполнить следующие шаги:
1) Для начала выполните следующую команду
2) После, отредактируйте /etc/unbound/unbound.conf используя следующий пример. Опция control-enable: yes обязательная, остальное можете настроить как необходимо вам.
Использование unbound-control
Список команд, которые вы можете использовать для unbound-control:
Обратитесь к unbound-control(8) для подробностей и поддерживаемых команд.
Советы и приёмы
Черный список доменов
Использование вместе с авторитетный DNS сервером
Для пользователей, которые желают иметь подтверждающий, рекурсивный и кеширующий DNS сервер вместе с авторитетным на одной машине, может быть полезно обратиться к странице NSD в которой описан пример такой конфигурации. Наличие одного сервера как авторитетный и отдельного для выполнения подтверждения, рекурсии и кеширования повышает уровень безопасности по отношению к единому DNS серверу выполняющему эти функции. Многие пользователи используют Bind в этом случае как единый DNS сервер, и пример для миграции на комбинацию Bind и NDS серверов предоставлен на странице NSD.
Доступ к DNS серверу через WAN интерфейс
Вы можете поменять настройки и прослушиваемые интерфейсы для нужного сервера, чтобы машины за пределами локальной сети могли получить доступ к определенным машинам внутри локальной сети. Это будет полезно для различных веб-сервисов которым нужен доступ извне. Похожий способ использовался с помощью сервера bind в комбинации с использованием перенаправления портов на машинах принимающих запросы для переадресации запросов на нужные машины.
Служба systemd для обновления корневых подсказок
Можете использовать эти примеры для создания systemd службы которая будет обновлять root.hints ежемесячно методом, описанным в разделе #Корневые подсказки (Root hints):
Решение проблем
Определение нужного количества потоков (num-threads)
В странице man руководства для unbound.conf говорится:
и другие источники предполагают, что параметр num-threads должен быть равен количеству ядер процессора. Пример конфигурации в
Установите num-threads равное количеству ядер процессора в вашей системе. Например для систем с 4 физическими ядрами поддерживающих гиперпоточность (hyper-threading) используйте 8.
Reviewing DNS Concepts
Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012
Domain Name System (DNS) is a distributed database that represents a namespace. The namespace contains all of the information needed for any client to look up any name. Any DNS server can answer queries about any name within its namespace. A DNS server answers queries in one of the following ways:
It is important to understand the core features of DNS, such as delegation, recursive name resolution, and Active Directory-integrated DNS zones, because they have a direct impact on your Active Directory logical structure design.
For more information about DNS and Active Directory Domain Services (AD DS), see DNS and AD DS.
Delegation
For a DNS server to answer queries about any name, it must have a direct or indirect path to every zone in the namespace. These paths are created by means of delegation. A delegation is a record in a parent zone that lists a name server that is authoritative for the zone in the next level of the hierarchy. Delegations make it possible for servers in one zone to refer clients to servers in other zones. The following illustration shows one example of delegation.
A delegation uses two types of records. The name server (NS) resource record provides the name of an authoritative server. Host (A) and host (AAAA) resource records provide IP version 4 (IPv4) and IP version 6 (IPv6) addresses of an authoritative server.
This system of zones and delegations creates a hierarchical tree that represents the DNS namespace. Each zone represents a layer in the hierarchy, and each delegation represents a branch of the tree.
By using the hierarchy of zones and delegations, a DNS root server can find any name in the DNS namespace. The root zone includes delegations that lead directly or indirectly to all other zones in the hierarchy. Any server that can query the DNS root server can use the information in the delegations to find any name in the namespace.
Recursive name resolution
Recursive name resolution is the process by which a DNS server uses the hierarchy of zones and delegations to respond to queries for which it is not authoritative.
In some configurations, DNS servers include root hints (that is, a list of names and IP addresses) that enable them to query the DNS root servers. In other configurations, servers forward all queries that they cannot answer to another server. Forwarding and root hints are both methods that DNS servers can use to resolve queries for which they are not authoritative.
Resolving names by using root hints
Root hints enable any DNS server to locate the DNS root servers. After a DNS server locates the DNS root server, it can resolve any query for that namespace. The following illustration describes how DNS resolves a name by using root hints.
In this example, the following events occur:
Resolving names by using forwarding
Forwarding enables you to route name resolution through specific servers instead of using root hints. The following illustration describes how DNS resolves a name by using forwarding.
In this example, the following events occur: