Root hints dns что это

Обновлено: 05.07.2024

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

DNS Advertisers(Публикующие сервера).

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

Это лишь один пример, как вы можете использовать DNS для внешних пользователей. Еще один случай – если вы хотите использовать свой собственный DNS, но ваш Интернет и почтовые серверы расположены где-то на другом хосте. В таком случае, вы настраиваете свой опубликованный DNS сервер на возврат IP-адресов хостера ваших серверов. То, что у вас размещаются ваши собственные сервисы DNS, не означает, что вы должны быть хостом для всех своих сервисов. В некоторых случаях вы будете размещать у себя ваши собственные службы (такие как Exchange), но передадите хостинг веб-сайта третьему лицу. В таком случае, ваш DNS сервер будет возвращать IP-адреса вашего хостера веб-сайта и IP-адреса внешнего интерфейса ISA Firewall, используемого для E-mail публикации.

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

DNS Resolvers(Сервера разрешения имен)

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

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

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

Мы поговорим подробней о серверах разрешения имен в следующей статье. Эта статья о публикующих серверах.

Защита системных настроек сервера DNS для публикующего сервера

На этом этапе вы уже знаете, что при публикации DNS сервера, вы получаете публикующий сервер (DNS advertiser). Пользователи из Интернета, скорее всего, получат анонимный доступ к подобным серверам, поскольку аутентификация не предусмотрена в мерах безопасности для разрешения имен DNS. Поэтому ваши DNS сервера вполне могут быть атакованы анонимным Интернет-пользователем, и вследствие этого вам стоит предпринять некоторые действия для того, чтобы заблокировать системные настройки вашего DNS сервера. Стоит отметить, что атаки будут идти только с 53-их портов UDP и TCP, потому что ваше правило публикации DNS Server Publishing Rule не позволит никаких других подключений к DNS серверу.

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

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

Находясь в диалоговом окне Properties для сервера DNS, на вкладке Interfaces, убедитесь, что вы отметили условие Only the following IP addresses и затем выберите определенный IP адрес, который DNS server будет прослушивать в поисках входящих запросов DNS. Это мелочь, но я обнаружил, что она может предотвратить некоторые потенциальные сложности в устранении неполадок в тех случаях, когда к DNS серверу прикреплено несколько IP адресов (как в случае, когда DNS сервер также поддерживает множество веб-страниц, прослушивающих разные IP адреса).

На вкладке Forwarders, вам нужно убрать галочку рядом с опцией Enable forwarders. Причиной для этого служит то, что мы не хотим сделать наши публикующие серверы серверами разрешения имен. Если позволить серверу стать сервером разрешения имен, он откроется для потенциальных атак, которые были бы невозможны, будь он только публикующим сервером. Таким образом, это предотвращает использование DNS сервера для разрешения имен – почему вы должны предоставлять эти сервисы каждому встречному и позволять ему использовать вашу сеть? Он вполне может воспользоваться собственными серверами или подобным сервером своего провайдера.

На закладке Advanced нам нужно отметить опции Disable recursion и Secure cache against pollution. Опция Disable recursion запрещает DNS серверу разрешать те имена, для которых он не является авторитетным. Иначе говоря, если сервер не может разрешить имя, используя записи ресурса (Resource Records), настроенные на сервере, то DNS запрос не будет выполнен. Опция Secure cache against pollution не позволяет атакующим засорить кэш DNS сервера, хоть это и так технически невозможно, когда рекурсия отключена. Однако я все равно использую эту опцию, с ней мне как-то спокойнее (теперь я заговорил как настоящий админ-железячник!)

На закладке Root Hints показан список корневых серверов DNS в Интернете. Они используются, когда DNS серверу нужно выполнить рекурсию. Раз уж мы не хотим, чтобы наши публикующие серверы выполняли рекурсию, почему бы нам не убрать все корневые серверы из списка, и тем самым не избавиться от искушения ее включить? Это неплохая идея, и все, что вам надо сделать, это всего лишь выделить все корневые серверы в списке и нажать кнопку Remove. Когда это будет сделано, ваша закладка Root Hints должна будет выглядеть как моя на рисунке, приведенном ниже.

На данном этапе наши системные настройки DNS сервера защищены так, как только мы можем это сделать. Заметьте, для этого примера я использовал серверWindows DNS, который работает превосходно и стабилен настолько, насколько это возможно (Он был запущен у меня около года и я перезагружал его лишь один раз, когда я устанавливал обновление, связанное со службами DNS). Однако вам необязательно использовать сервер Windows DNS. Любой сервер подходит, и если вы хотите сэкономить, вы легко можете использовать общедоступный DNS сервер. Просто убедитесь в том, что вы настроили его так, что он не будет выполнять рекурсии любого типа и будет отвечать на запросы лишь для тех доменов и ресурсов, для которых он является авторитетным.

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

Если вы позволите передачу зон с внутреннего сервера на публикующий, вы передадите частные записи о вашей внутренней сети на открытый DNS сервер, а это как раз то, чего делать не стоит! В общем, вам не нужно включать передачу зон с внутреннего DNS сервера на публикующий сервер.

Для начала необходимо все разложить по полочкам 1 :

Структура множества доменных имен представляет из себя древовидную иерархию. Чтобы не усложнять изначально достаточно простую вещь, я подобрал наиболее подходящую картинку с описанием иерархии доменных имен 2 :

Классификация доменных имен также не должна вызывать сложностей в понимании, но на удивление в интернете практически не найти нормальные иллюстрации. Мне под руки попалась только одна 3 :

Вообще на этом канале 4 огромное количество уроков, которые посвящены именно DNS. Однозначно советую к просмотру. Хоть и описание типов dns-серверов есть и на Википедии 5 , оно там плоское и только зря сводит с толку.

Вопросов кто такие dns-клиенты возникать не должно.

Вот таки размышления. Конечно все эти определения скорее запутывают, чем помогают разобраться. Надо просто иметь в виду, что есть primary master и он стоит вверху иерархии и есть все остальные. Стоит добавить, что серверы всех трех типов будут являться авторитативными, то есть ответственными за зону.

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu .

Наглядно рекурсивный 11 12 запрос выглядит так:

а нерекурсивный 13 :

На этом обзор основных принципов работы dns закончен. Рассмотрение типов записей dns, а также механизмов работы обратного разрешения имен (ip-адрес по dns-имени) я в рамках этой статьи я затрагивать не планировал, хотя конечно же это очень интересные темы.

Этот раздел будет посвящен обзору лучших практик по настройке роли DNS (интегрированной в AD) на Windows Server 2012 R2, но большинство советов актуальны и для предыдущих версий ОС. Тем не менее не стоит забывать про улучшения, которые добавляются в каждой новой версии и 2012 R2 не исключение 14 15 .

Я подразумеваю, что нет никакого смысла повторять, что в каждом домене должно быть минимум два контроллера домена. Это необходимо для отказоустойчивости. Собственный ip-адрес сервера должен быть обязательно статическим 16 .

Собственно сами рекомендации:

Суть в том, что, во избежание проблем с репликацией, в списке первичных dns-серверов на каждом контроллере домена первыми должны быть указаны партнеры по репликации, то есть другие контроллеры домена. Собственный адрес отдельно взятого сервера должен быть указан самым последним 18 в его списке dns-серверов. Для увеличения производительности последним в списке используйте loopback-адрес 127.0.0.1 19 как собственный адрес сервера (но не реальный сетевой адрес адаптера), хоть и это иногда может вызывать небольшие проблемы 20 .

2) На клиентских системах должны использоваться только локальные dns-серверы, но никак не публичные.

В противном случае у вас могут возникнуть проблемы 21 с разрешением внутренних имен, хотя выход наружу будет доступен. Тем не менее в корпоративной сети у меня доступ наружу по dns портам разрешен только контроллерам домена и серверам Exchange.

Позаботьтесь о том, чтобы ваш dhcp-сервер выдавал клиентам настройки со всеми имеющимися у вас адресами серверов dns. Их может быть два, а может быть и больше, все зависит от конкретной топологии. Если у вас структура AD с множеством сайтов, то логично, чтобы по порядку сначала шли серверы сайта, в котором этот пк находится и уже только потом выдавались адреса dns-серверов других сайтов 22 .

3) Если у вас домен AD, то используйте только интегрированную с AD роль DNS (AD-integrated). Прибавится достаточно много плюсов в плане безопасности, производительности и отказоустойчивости 23 .

Производительность всей инфраструктуры увеличивается, поскольку все партнеры по репликации (контроллеры домена) имеют одинаковый вес и нет master- и slave- серверов. То есть, если бы запрос поступил к slave-серверу классического dns, то он должен был бы обратиться к мастеру для инициирования процесса обновления. При интегрированной в ad dns каждый контроллер домена может писать изменения в базу dns и уже дальше неспеша реплицировать их на другие контроллеры. К тому же сам по себе механизм репликации ad ds значительно быстрее.

Безопасность увеличивается благодаря защищенным динамическим обновлениям 24 . О DNSSEC речь тут не идет, это общая технология, хотя и в Windows есть её реализация 25 26 .

Есть также рекомендации 29 30 31 32 (обязательно к прочтению) касательно автоматической очистке записей dns. В этой статье я их подробно не рассматриваю, поскольку автоматическая очистка записей по умолчанию отключена. На деле процесс настройки очень простой, но имеет колоссальные последствия 33 для инфраструктуры в том случае, если вы не понимаете что конкретно делаете и к чему это может привести.

Fenix by Takeda11

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

Как работает DNS: рекурсивные и авторитетные DNS-серверы

Во-первых, нам нужно немного объяснить систему DNS. Существует два вида DNS-серверов: авторитетные и рекурсивные.

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

Когда люди посещают ваш веб-сайт, они, вероятно, делают DNS-запросы к рекурсивному DNS-серверу. Итак, как же работают рекурсивные DNS-серверы? Давайте посмотрим!

Шаг 1: IP-адреса для корневых DNS-серверов жестко закодированы в его исходном коде. Вы можете увидеть это в исходном коде unbound. Допустим, для начала он выберет 198.41.0.4. Вот официальный источник этих жестко закодированных IP-адресов, также известный как «корневой файл подсказок» (root hints file).

Детали ответа DNS немного сложнее — в этом случае есть раздел авторитетности (authority section) с некоторыми записями NS и дополнительный раздел с записями A, так что вам не нужно делать дополнительный поиск, чтобы получить IP-адреса этих серверов имен.

Мы почти закончили!

Как увидеть все шаги рекурсивного DNS-сервера: dig +trace

Чтобы посмотреть, что рекурсивный DNS-сервер будет делать для резолвинга домена, можно запустить:

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

Обновим записи DNS

Теперь, когда мы знаем основы работы DNS, давайте обновим некоторые записи DNS и посмотрим, что произойдет.

При обновлении записей DNS существует два основных варианта:

сохранить те же серверы имен;
изменить серверы имен.

Поговорим о TTL

Но мы забыли кое-что важное. Это TTL. Как мы сказали ранее, рекурсивный DNS-сервер будет кэшировать записи до истечения срока их действия. Он принимает решение об истечении срока действия записи в зависимости от ее TTL (time to live, времени жизни).

В этом примере сервер имен GitHub для его DNS-записи возвращает TTL 60, что означает 60 секунд:

Вариант 1: обновление записи DNS на тех же серверах имен

Во-первых, я обновила свои серверы имен (Cloudflare), чтобы получить новую запись DNS — запись A, которая сопоставляет test.jvns.ca на 1.2.3.4:

Это сработало немедленно! Не было никакой необходимости ждать вообще, потому что перед этим не было никакой DNS-записи test.jvns.ca , которая могла быть кэширована. Отлично. Но похоже, что новая запись кэшируется в течение примерно пяти минут (299 секунд).

Итак, а если мы попытаемся изменить этот 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. Некоторые DNS-серверы интернет-провайдеров будут кэшировать записи дольше, чем указано в TTL. Например, в течение двух дней вместо пяти минут. И люди всегда могут жестко закодировать старый IP-адрес в своем файле /etc/hosts .

На практике при обновлении записи DNS с пятиминутным TTL можно ожидать, что большой процент клиентов быстро перейдет на новые IP-адреса (например в течение 15 минут), а затем появится куча отставших, которые будут медленно обновляться в течение следующих нескольких дней.

Вариант 2: обновление ваших серверов имен

Итак, мы видели, что когда вы обновляете IP-адрес, не меняя свои серверы имен, многие DNS-серверы довольно быстро получают новый IP-адрес. Отлично. Но что произойдет, если вы измените свои серверы имен? Давайте попробуем!

Ладно, давайте посмотрим, изменилось ли что-нибудь:

Никаких изменений. Если я спрошу другой DNS-сервер, то он знает новый IP:

У серверов имен TTL намного больше

Причина, по которой мой регистратор говорил: «Это займёт 48 часов» в том, что TTL на NS-записях (сведения о том, к какому серверу имен должен обратиться рекурсивный сервер) намного больше.

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 в течение дня или двух.