Инструмент для отслеживания dns-запросов: dnspeep / хабр

Проверка на наличие проблем с достоверными данными

Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.

Если сервер является сервером-источником

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

Если на сервере размещается дополнительная копия зоны

Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).

Примечание

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

Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.
Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.
На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:

Например, если зона — corp.contoso.com, введите: .
Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье .
Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.

Принцип работы и применение

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

То же самое происходит, когда вы набираете адрес сайта в браузере. Так как компьютер не знает реального IP-адреса, он отсылает запрос на DNS-сервер, на котором храниться база адресов. После получения ответа браузер загружает данные с нужного сайта и показывает их пользователю.

Рассмотрим подробнее, как работает dns сервер:

Пользователь в адресной строке браузера вводит доменное имя сайта, на который хочет перейти.
Браузер ищет нужный IP-адрес на локальном компьютере, в файле hosts. Если нужной информации там не находит, то отправляет свой запрос на сервер более высокого уровня. Например, это может быть локальный сервер провайдера.
Если и на этом сервере нет данных об IP-адресе сайта, то запрос переправляется на сервис более высокого уровня. Такая переадресация будет длиться, пока нужный адрес не будет найден или корневой DNS-сервер не ответит, что сайта с таким именем не существует.
После этого начнётся обратное движение запроса, от высшего уровня до низшего, пока данные не придут на компьютер пользователя.

С помощью DNS можно не только найти адрес сайта по IP-адресу, но и выполнить обратную операцию: зная адрес, узнать его доменное имя.

Защита DNS-серверов от атак

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

Наиболее опасными считают нападения на корневые серверы, хранящие данные об IP-адресах. Например, в историю вошла произошедшая в октябре 2002 года DDoS-атака на 10 из 13 серверов верхнего уровня.

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

Существует несколько схем, настройка которых позволит защитить DNS-сервер от атак хакеров:

Использование технологии uRPF (Unicast Reverse Path Forwarding).
Суть состоит в том, чтобы определить возможность принятия пакета с конкретным адресом отправителя на указанном устройстве для передачи данных. Пакет проходит проверку и принимается в том случае, когда сетевой интерфейс, с которого он получен, предназначен для обмена информацией с адресатом данного пакета. В обратной ситуации пакет будет отброшен. Этот способ помогает выявить и частично отобрать фальшивый трафик, но не гарантирует надежную защиту от фальсификации. uRPF полагает, что данные отправляются на определенный адрес через неизменный интерфейс. Ситуация усложняется, если появляется несколько провайдеров.
Применение функции IP Source Guard.
В ее основе лежит технология uRPF и проверка DHCP-пакетов. IP Source Guard отслеживает DHCP-трафик в интернете и выясняет, какие IP-адреса получили сетевые устройства. Это позволяет выявить поддельный трафик на некоторых портах установки. После этого данные собираются и записываются в общую таблицу итогов проверки DHCP-пакетов. В дальнейшем IP Source Guard обращается к этой таблице, чтобы осуществить проверку пакетов, полученных коммутатором. Если IP-адрес пакета не совпадает с адресом источника, то пакет откладывается.
Использование утилиты dns-validator.
Эта программа контролирует передачу всех пакетов DNS, соотносит запрос с ответом и в случае расхождения названий отправляет уведомление пользователю.

Enabling DNS Logging for Windows Server 2012

Domain Name System (DNS)

To turn on DNS logging for a Microsoft Windows Server 2012 system
which is functioning as a DNS server, take the following steps:

Hit Ctrl-Esc.
Click on Administrative Tools.
Select DNS.
Right-click on the DNS server and select
Properties.
Click on the Debug Logging tab.
Check the box next to Log packets for
debugging. Ensure that at least Incoming, UDP,
Queries/Transfers, and the packet type of Request are
checked. You may also want to log TCP packets, outgoing packets, and
response packets as well to see the IP addresses returned by the DNS
server for queries on names.
Specify the directory path and file name for the log file. You can
also specify a maximum size, if you wish. The default value is
500,000,000 bytes, i.e., 500 MB. If you only want to log DNS queries/responses
from/to a particular system that is querying the DNS server, check the check
box next to «Filter packets by IP addess» and then specify the IP address
or addresses of systems for which you wish to record data on DNS queries and/or
responses.
Click on OK.
If you don’t want to see any other entries in the log,
e.g., for problems on the DNS server, you can click on the Event Logging
tab and set the value for «Log the following events» to «No events»
and click on OK.

If you wish to delete an existing log file that is in use and start a
new one, right-click on the DNS server in the DNS Manager window,
select All Tasks, then Stop. You can then move or delete
the log file, right-click on the DNS server again, select All Tasks,
then Start to restart logging.

When you check the log file, entries will appear such as the following:

The entries above show the system with IP address 192.168.0.42 queried the
DNS server for the address of imap-mail.outlook.com. The Windows Server 2012
DNS server did not know the IP address, so it in turn queried a
system
at 10.255.176.137. It received a response from the DNS forwarder and
returned the response to the system at 192.168.0.42. The numbers
you see for reflect
the number of characters
in various parts of the address. E.g.,
is 9 characters,
is 7
characters, and is 3 characters.

A valuable and free tool which can aid you in examining Microsoft Windows
DNS log files is Windows
DNS Log Analyser.

If you wish to rotate the log file daily, you can use the instructions
at , though, since the command is
deprecated, you will need to use the
schtasks command, instead of
the command. A command similar to the one shown below can
be used to run the batch file at one minute after midnight every night:

C:\>schtasks /create /tn "Rotate DNS Log" /tr "C:\Program Files\Utilities\rotatednslog" /sc daily /st 00:01
SUCCESS: The scheduled task "Rotate DNS Log" has successfully been created.

I can check on the status of the avove scheduled task as shown below:

C:\>schtasks /query /tn "Rotate DNS Log"

Folder: \
TaskName                                 Next Run Time          Status
======================================== ====================== ===============
Rotate DNS Log                           2/20/2015 12:01:00 AM  Ready

In the above example, the task was submitted on February 19, 2015.

Justdeals Daily Electronics Deals

Created: Thursday, February 19, 2015

Last modified: Thursday February 19, 2015 11:28 PM

Типы DNS-записей

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

A – адресная запись, которая отвечает за привязку доменного имени к определенному IP-адресу по протоколу IPv4.
AAAA – аналогична предыдущей, только действительна на основе интернет-протокола IPv6.
CNAME – данный тип записи указывает на каноническое имя для псевдонима. С ее помощью к одному поддомену привязываются все ресурсные записи домена первого уровня.
DKIM-подпись – подтверждает подлинность отправителя электронного письма. Именно эта ресурсная запись добавляет в сообщение цифровую подпись. Тем самым снижается вероятность попадания письма в папку «Спам».
MX – регистрирует почтовые серверы, используя при этом протокол SMTP. Отвечает за доставку электронного письма на указанный сервер.
NS – указывает на DNS-серверы, которые обслуживают домен. Чуть ли не одна из самых важных записей, без которой функционирование домена дало бы сбой.
PTR – действует обратно записям A и AAAA, то есть показывает соответствие IP-адреса и доменного имени. Многие почтовые серверы во время фильтрации писем проверяют ее наличие.
SOA – используется для указания на новую зону и авторитетность указанной в ней информации.
SPF – защищает домен от подделки, показывает список доверенных серверов, с которых отправляются электронные письма. Это нужно для того, чтобы предотвратить рассылку спама от вашего доменного имени.
SRV – хранит данные о местоположении серверов, обеспечивающих работу тех или иных служб.
TXT – содержит общую вспомогательную информацию о домене, используется для указания SPF-записей, подтверждения прав собственности, обеспечения безопасности электронной почты и так далее.

Как доработать производительный RLS

Неоднократно в последнее время поступали задачи, когда требовалось доработать новый производительный RLS. В своей статье Ретунский Александр, программист компании АО «Корпоративные ИТ-проекты» (официальный партнер ИнфоСофт) опишет последовательность действий при доработке нового RLS, ключевые моменты и сложности, с которыми столкнулся. В Интернете статей или инструкций, которые подробно и просто описывают – как доработать производительный RLS, не так много и автор делиться своим опытом.
В данной статье не будут описаны различия и плюсы/минусы между стандартным и производительным RLS, в Интернете по этому вопросу есть много информации.

Условия фильтра запросов

Фильтры запросов можно создавать с помощью любых логических сочетаний (и/или/или не) следующих критериев.

Имя	Описание
Подсеть клиента	Имя предопределенной клиентской подсети. Используется для проверки подсети, из которой был отправлен запрос.
Транспортный протокол	Транспортный протокол, используемый в запросе. Возможные значения: UDP и TCP.
протокол IP	Сетевой протокол, используемый в запросе. Возможные значения: IPv4 и IPv6.
IP-адрес интерфейса сервера	IP-адрес сетевого интерфейса DNS-сервера, получившего запрос DNS.
Полное доменное имя.	Полное доменное имя записи в запросе с возможностью использования подстановочных знаков.
Тип запроса	Тип запрашиваемой записи (A, SRV, TXT и т. д.).
Время дня	Время суток, когда получен запрос.

В следующих примерах показано, как создать фильтры для политики DNS, которые либо блокируют, либо разрешают запросы разрешения имен DNS.

Примечание

в примерах команд в этом разделе используется команда Windows PowerShell Add-днссерверкуериресолутионполици. Дополнительные сведения см. в разделе Add-днссерверкуериресолутионполици.

2021: «Ростелеком» запретил использование публичных DNS-серверов Google, Cloudflare и сервиса DoH

13 сентября 2021 года появилась информация о том, что «Ростелеком» направил своим подразделениям официальное письмо, запрещающие применение публичных DNS-серверов , Cloudflare и сервиса DoH (doh.opendns.com).

Согласно документу, подразделениям «Ростелекома» дается указание «запретить к использованию для выдачи абонентам с BRAS/DHCP и в технологических сетях адресов DNS Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1) и сервиса doh.opendns.com».

Как пишет Telegram-канал «Двач», «Ростелеком», вероятно, действует согласно указаниям Роскомнадзора и таким образом прорабатывается блокировка Рунета.

Как ранее сообщалось, в сентябре Роскомнадзор планирует протестировать блокировку ряда иностранных интернет-протоколов, скрывающих имя сайта, включая DoH, который внедряют Mozilla и Google. Такие протоколы могут затруднить блокировку доступа к запрещенным ресурсам.

«Ростелеком» решил заблокировать DNS-серверы Google, Cloudflare

Чтобы сохранить работоспособность сетей, ведомство рекомендовало компаниям до 9 сентября подключиться к DNS-сервисам российских операторов связи или Национальной системе доменных имен (НСДИ).

Вместо указанных серверов и DoH «Ростелеком» предложил использовать DNS-серверы под собственным управлением или IP-адреса Национальной системы доменных имен.

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

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

Технический директор «Роскомсвободы» Станислав Шакиров рассказал РБК, что компании заранее переводят клиентов на другие серверы на случай возможной блокировки публичных DNS-серверов Google и Cloudflare. Анонимный источник издания полагает, что основная цель ограничений — прекратить работу протокола DoH, поскольку на мобильных сетях практически нет проблем с блокировкой доступа к запрещенным сайтам.

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

Записи DNS

Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей:

имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись,
тип (TYPE) ресурсной записи — определяет формат и назначение данной ресурсной записи,
класс (CLASS) ресурсной записи; теоретически считается, что DNS может использоваться не только с TCP/IP, но и с другими типами сетей, код в поле класс определяет тип сети,
TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера,
длина поля данных (RDLEN),
поле данных (RDATA), формат и содержание которого зависит от типа записи.

Наиболее важные типы DNS-записей:

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

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

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

Что освещается в материале

Мы затронем немного основ: что значит аббревиатура DNS, как это функционирует. Понимание этого позволит пользователю использовать возможности провайдера в полной мере.
Порядок организации максимально скоростного интернет-соединения, а также список IP, которые нужно вводить вручную.
Чем различаются настройки параметров – ручная/автоматическая.
Какие могут возникнуть проблемы при эксплуатации, какие оповещения при ошибке подключения выдаются пользователю.

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

Другими словами, через DNS осуществляется анализ того, что ввёл в адресной строке пользователь, распознавание и сопоставление с конкретным сайтом и соединение пользователя с этим сайтом. При этом система автоматически присваивает пользователю индивидуальный IP для осуществления обратной связи. Иначе говоря, вы послали запрос, а сервер сайта должен выдать на ваш компьютер свои данные, то есть страницу сайта.

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

Подытоживая вышеописанное, можно отметить основные пункты:

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

Проверка регистрации записи ресурса

Конечный контроллер домена использует запись ресурса DNS-псевдонима (CNAME) для указания партнера по репликации исходного контроллера домена. хотя контроллеры домена, работающие Windows server (начиная с Windows server 2003 с пакетом обновления 1 (sp1)), могут обнаружить исходные партнеры репликации с помощью полных доменных имен или, если это не удается, ожидается, что NetBIOS-намессе запись ресурса псевдонима (CNAME) будет проверяться на предмет правильной работы DNS.

Для проверки регистрации записей ресурсов, включая регистрацию записи ресурса псевдонима (CNAME), можно использовать следующую процедуру.

To verify resource record registration

Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка.
Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить. С помощью средства Dcdiag можно проверить регистрацию всех записей ресурсов, необходимых для расположения контроллера домена, выполнив команду.

Эта команда проверяет регистрацию следующих записей ресурсов в DNS:

псевдоним (CNAME): запись ресурса на основе глобального уникального идентификатора (GUID), которая находит партнера репликации.
узел (A): запись ресурса узла, которая содержит IP-адрес контроллера домена.
Записи ресурсов LDAP SRV: службы (SRV), которые находят LDAP-серверы.
GC SRV: записи ресурсов службы (SRV), которые находят серверы глобального каталога
PDC SRV: записи ресурсов службы (SRV), которые находят хозяева операций эмулятора основного контроллера домена.

Для проверки регистрации записи ресурса псевдонима (CNAME) можно использовать следующую процедуру.

Проверка регистрации записи ресурса псевдонима (CNAME)

Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
Используйте оснастку DNS, чтобы выбрать любой контроллер домена, на котором работает служба DNS-сервера, где на сервере размещается зона DNS с тем же именем, что и домен Active Directory контроллера домена.
В дереве консоли щелкните зону с именем _msdcs. Dns_Domain_Name.
В области сведений убедитесь, что имеются следующие записи ресурсов: запись ресурса псевдонима (CNAME) с именем Dsa_Guid. _msdcs. < Dns_Domain_Name > и соответствующую запись ресурса узла (a) для имени DNS-сервера.

Если запись ресурса псевдонима (CNAME) не зарегистрирована, убедитесь, что динамическое обновление работает правильно. Используйте тест в следующем разделе, чтобы проверить динамическое обновление.

Доступ на уровне записей в типовых конфигурациях. Настройка доступа пользователей с разделением по подразделениям/складам – практический пример

Многим известно, что в современных конфигурациях, разработанных с использованием БСП, имеются широкие возможности для настройки прав доступа. В частности, реализован функционал разделения доступа на уровне записей (RLS). Однако администратор(разработчик) при планировании схемы доступа в организации неминуемо столкнется со сложностями, если временами путается в понятиях: Группы пользователей/Группы доступа/Профили групп доступа.
В статье представлен принцип решения типичной задачи – ограничения прав пользователя на просмотр/изменение информации «чужих» складов и подразделений в конфигурации 1С: Управление торговлей 11.4.

Атаки на DNS

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

Симптомы

На компьютере Windows, на который размещены контроллеры домена Active Directory, роли сервера DNS перестают отвечать на 15-25 минут. Эта проблема возникает после отображения сообщения о подготовке сетевых подключений и перед отображением запроса Windows логотипа (Ctrl+Alt+Del).

Следующий DNS Event ID 4013 входит в журнал событий DNS контроллеров доменов, которые после Windows начинаются:

В этой записи журнала значения <%Status% > не могут быть зарегистрированы. Или они включают, но не ограничиваются следующими значениями:

Hex	Байт	Десятичное число	Символический	Строка ошибки
000025f5	f5 25 00 00	9717	DNS_ERROR_DS_UNAVAILABLE	Служба каталогов недоступна
0000232d	2d 23 00 00	9005	DNS_ERROR_RCODE_REFUSED	Операция DNS была отклонена.
0000232a	2a 23 00 00	9002	DNS_ERROR_RCODE_SERVER_FAILURE	Сбой сервера DNS.

Где находятся

Самые важные DNS-серверы – корневые, которые содержат информацию о нахождении других серверов, более низкого уровня. Впервые они появились в Северной Америке, но потом их стали разворачивать и в других странах. Сейчас корневых серверов всего 13. Однако для увеличения надёжности работы интернет были созданы их копии, и их общее количество возросло до 123.

Наибольшее из количество расположено в Северной Америке, где их 40, что составляет 32,5% от общей численности. На втором месте по числу серверов находится Европа – 35 серверов (28,5%). 6 (4,9%) серверов имеется в Южной Америке и 3 (2,4%) в Африке. Также есть свои DNS-серверы есть в Австралии, Китае и даже Исландии. Общая закономерность расположения серверов такая: чем интенсивнее используется интернет, тем больше серверов.

В России есть несколько корневых серверов:

F.root – расположен в Москве;
I.root – находиться в Санкт-Петербурге;
J.root – распределённый, расположен в Москве, Санкт-Петербурге;
K.root – еще один распределённый, находится в трёх городах: Москва, Санкт-Петербург и Новосибирск;
L.root – присутствует сразу в трёх городах: Москва, Ростов-на-Дону и Екатеринбург.