Bulk dns resolver как пользоваться

Обновлено: 02.07.2024

Система доменных имен (DNS, Domain Name System) представляет собой механизм, а именно распределенную БД, предназначенный для поиска по имени хоста его IP адреса и некоторой другой информации (например, имени почтового сервера). В статье описываются:

Пространство доменных имен

Поддерево вместе со своим корневым узлом называется доменом (поддоменом). Имя домена определяется полным именем его корневого узла. Группировка узлов в домены является чисто логической, т.е. не определяется ни месторасположением, ни IP-адресом, ни маршрутизацией. Узел входит в состав нескольких вложенных доменов (поддеревьев) по пути от узла к корню. Домен первого (высшего) уровня в качестве непосредственного предка имеет корневой узел. Домен второго уровня в качестве непосредственного предка имеет домен первого уровня.

Дерево доменых имен делится на независимо администрируемые части, называемые зонами (здесь имеются в виду права на администрирование части БД пространства доменных имен, а не на администрирование самих хостов). Зона включает в себя домен, делегированный данной организации, за вычетом поддоменов, право администрирования которыми было делегировано ею другим организациям.

Кроме пространства доменных имен Интернет допустимы частные пространства имен.

Архитектура системы доменных имен

Клиенты обычно реализуются в виде библиотеки подпрограмм, присоединяемых к каждой программе (статически или динамически), которой требуется сервис доменных имен. Простой (stub) клиент обращается к указанному при настройке DNS серверу (серверам), интерпретирует ответ и возвращает результат запросившей программе. Если используется протокол UDP, то клиент должен уметь обрабатывать ошибки. Если сервер не отвечает, клиент должен уметь использовать запасной(ые). Реализация клиента в Solaris и Linux позволяет также получить информацию из других источников (локальный файл, NIS, NIS+ и т.д.) в зависимости от настройки Name Service Switch. Некоторые клиенты позволяют кешировать информацию самостоятельно, либо с помощью nscd.

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

Еще существуют (существовали, RFC 3425?) инверсные запросы (inverse queries), при котором DNS сервер производит поиск в локальных данных доменного имени, имеющего требуемое значение RR.

При выборе одного из уполномоченных серверов зоны используется время отклика (RTT, roundtrip time). При первых запросах уполномоченные сервера опрашиваются по очереди в случайном порядке. В дальнейшем используется уполномоченный сервер зоны, имеющий минимальное RTT.

Пространство доменных имен Интернет

gTLD управляет GNSO ICANN, общий список регистраторов. Хотя права на администрирование каждого конкретного домена высшего уровня делегированы одной конкретной организации (оператору регистра), но зарегистрировать свой домен второго уровня в большинстве из них можно у одного из многочисленных регистраторов (коммерческие организации, имеющие доступ к общей базе данных оператора регистра). На сайте регистратора имеется whois-сервис для соответствующего домена. Такая двухуровневая система была разработана для обеспечения конкуренции между регистраторами. Более того, так как в таких странах как Россия нет действующих местных регистраторов gTLD, то для оплаты услуг в местной валюте придется прибегнуть к услугам агентов, посредников или провайдера (это уже третий уровень). Список gTLD:

Список ccTLD базируется на стандарте двухбуквенных кодов государств и зависимых територрий ISO 3166. В каждой стране свои правила регистрации доменов второго уровня.Поиск информации можно начать со списков регистраторов и whois-сервисов:

Отображение адресов в имена

Зоны верхнего уровня в домене in-addr.arpa. делегированы IANA региональным регистраторам (RIR, Regional Internet Registrator) вместе с блоками IP-адресов.

Записи о ресурсах (RR, Resource Records)

BIND версии ? позволяет дополнительно использовать директиву $GENERATE для создания последовательности RR, отличающихся лишь параметром:

$GENERATE интервал левая-часть тип-записи правая-часть

Интервал чисел задается либо в виде начало-конец, либо в виде начало-конец/шаг. По умолчанию, шаг равен 1. Левая часть задает правило формирования доменных имен для последовательности записей, у которых индекс пробегает от начало до конец с шагом шаг. Правая часть задает правило формирования данных записи (пока разрешены только типы PTR, CNAME, DNAME, A, AAAA и NS). В правилах одинокий символ $ заменяется текущим значением индекса. Значение индекса может быть модифицировано заданием смещения (вычитается из индекса), ширины поля (используется для форматирования результата) и системы счисления (d, o, x, X) в фигурных скобках через запятую. Если получилось относительное имя, то оно дополняется текущим суффиксом. Используется в основном для автоматической генерации обратных зон:

$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-127 $ CNAME $.0

1.0.0.192.IN-ADDR.ARPA CNAME 1.0.0.0.192.IN-ADDR.ARPA
2.0.0.192.IN-ADDR.ARPA CNAME 2.0.0.0.192.IN-ADDR.ARPA
.
127.0.0.192.IN-ADDR.ARPA CNAME 127.0.0.0.192.IN-ADDR.ARPA

Протокол DNS

Расширение протокола TSIG

Данный механизм требует меньшей нагрузки на процессор и меньших затрат на создание инфраструктуры при небольшом количестве узлов по сравнению с DNSSEC с его механизмами ассиметричного шифрования и публичных ключей (RFC 2535, RFC 2137). С другой стороны DNSSEC позволяет легко масштабировать установленную инфраструктуру распределения ключей и обеспечивать цифровую подпись (TSIG несмотря на название не позволяет производить подтверждение авторства запросов из-за симметричности ключа).

Динамические изменения зоны

RFC 2136 расширяет протокол DNS возможностью динамического изменения содержимого зоны по требованию клиента. Это избавляет от необходимости при частых изменениях (например, работа DHCP) редактировать текстовый файл с описанием зоны и перезапускать сервер. С помощью данного расширения можно одним пакетом внести несколько изменений в зону, управляемую данным первичным уполномоченным сервером (все доменные имена должны быть внутри зоны):

добавить запись ресурса (RR) в набор записей ресурсов (RRset); записи типа SOA и CNAME не добавляются, а замещаются; если SOA не было или её серийный номер был больше, то добавление игнорируется; попытка заменить нормальный набор записей на CNAME или CNAME на нормальный набор записей игнорируется; попытка добавить дублирующую запись игнорируется
удалить запись ресурса (RR) с заданным значением из набора записей ресурсов (RRset); не удаляются последняя запись NS и SOA самой зоны; попытка удалить несуществующую запись игнорируется
удалить набор записей ресурсов (RRset); не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется
удалить все наборы ресурсов, относящиеся к указанному доменному имени; не удаляются записи NS и SOA самой зоны; попытка удалить несуществующий набор игнорируется

Набор изменений может быть предварён набором условий следующих типов (все доменные имена должны быть внутри зоны):

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

есь пакет условий и изменений является атомарным, т.е. обрабатывается как единое неделимое целое (как транзакция в СУБД). При этом сервер обязан записать изменения на диск до ответа клиенту. bind временно записывает изменения в журнал и сливает его с файлом зоны позднее. Если изменения не затронули SOA, то сервер должен увеличить серийный номер автоматически. Метод стандартом не задаётся. Если автоувеличение серийного номера производится с задержкой, но она не должна быть более 300 секунд или 1/3 от времени обновления зоны.

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

Сервер может проверять право клиента на изменение зоны по его IP адресу (не рекомендуется) или при помощи механизма TSIG.

DNS клиент (resolver)

Настройка работы клиента DNS производится с помощью файла /etc/resolv.conf или переменных окружения при запуске процесса.

Переменная окружения LOCALDOMAIN перекрывает действие инструкций domain и search. Переменная окружения RES_OPTIONS перекрывает действие инструкции options. Переменная окружения HOSTALIASES позволяет задать имя файла (например, /etc/host.aliases), содержащего список синонимов доменных имен (по одному простому имени и его доменному синониму без завершающей точки на строке через пробел).

Если при загрузке компьютера требуется наличие работающего локального сервера DNS (обычно из-за указания доменных имен в ifconfig или route), то желательно обеспечить резервный метод разрешения доменных имен с помощью настройки NSS и заполнения /etc/hosts, иначе клиентские компьютеры будут вынуждены дожидаться загрузки одного из серверов DNS. Тем более важно обеспечить резервный метод для хостов, на которых работают серверы DNS. А лучше всего не использовать DNS во время загрузки. Ещё имеется загадочный файл /etc/ppp/resolv.conf.

Настройка DNS в MS Windows производится с помощью графического интерфейса. Изготовитель уверяет, что это очень просто ;). Вот только отличаются реализации клиента DNS в различных версиях MS Windows больше, чем Unix от Linux (в частности, TCP/IP стек в W2000 и XP взят из FreeBSD (NetBSD?):

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

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

Очистить / очистить кеш DNS в Windows

Процесс очистки кеша DNS одинаков для всех версий Windows. Вам нужно открыть командную строку с правами администратора и запустить ipconfig /flushdns .

Windows 10 и Windows 8

Чтобы очистить кеш DNS в Windows 10 и 8, выполните следующие действия:

Введите cmd в строку поиска Windows.

Щелкните правой кнопкой мыши командную строку и выберите Запуск от имени администратора. Откроется окно командной строки.

В командной строке введите следующую строку и нажмите Enter:

Windows 7

Чтобы очистить кеш DNS в Windows 7, выполните следующие действия:

Щелкните по кнопке Пуск.

Введите cmd в текстовое поле поиска меню «Пуск».

В командной строке введите следующую строку и нажмите Enter:

Очистить / очистить кеш DNS в Linux

В Linux кэширование DNS на уровне ОС отсутствует, если не установлена и не запущена служба кэширования, такая как Systemd-Resolved, DNSMasq или Nscd. Процесс очистки кеша DNS отличается в зависимости от дистрибутива Linux и службы кэширования, которую вы используете.

Systemd решено

Большинство современных дистрибутивов Linux, таких как Ubuntu 18.04, используют службу с разрешением systemd для кэширования записей DNS.

Чтобы узнать, запущена ли служба, используйте следующую команду:

Если служба запущена, команда будет печатать как active . В противном случае вы увидите inactive .

Чтобы очистить кэш Systemd Resolved DNS, введите:

DNSMasq

Если ваша система использует DNSMasq в качестве кэширующего сервера, для очистки кеша DNS вам необходимо перезапустить службу Dnsmasq:

Если ваша система использует Nscd, чтобы очистить кеш DNS, вам необходимо перезапустить службу Nscd:

Очистить / очистить кеш DNS в macOS

Команда для очистки кеша в macOS немного отличается в зависимости от используемой версии. Команда должна быть выполнена от имени пользователя с правами системного администратора (пользователь sudo).

Чтобы очистить кеш DNS в macOS, выполните следующие действия:

Перейдите в Приложения> Утилиты> Терминал. Это откроет окно терминала.

В командной строке введите следующую строку и нажмите Enter:

Для более ранних версий macOS команда очистки кеша отличается.

macOS версии 10.11 и 10.9

macOS версии 10.10

macOS версии 10.6 и 10.5

Очистить / очистить кеш DNS браузера

Большинство современных веб-браузеров имеют встроенный DNS-клиент для предотвращения повторяющихся запросов при каждом посещении веб-сайта.

Гугл Хром

Чтобы очистить кеш DNS Google Chrome , выполните следующие действия:

Если это не сработает, попробуйте очистить кеш и файлы cookie.

Этот метод должен работать для всех браузеров на базе Chrome, включая Chromium , Vivaldi и Opera .

Fire Fox

Чтобы очистить кеш DNS Firefox, выполните следующие действия:

В верхнем правом углу щелкните значок гамбургера ☰ чтобы открыть меню Firefox:
Щелкните ⚙ Options (Preferences) .
Щелкните вкладку Конфиденциальность и безопасность или Конфиденциальность слева.
Прокрутите вниз до раздела « History » и нажмите кнопку « Clear History. .
Выберите временной диапазон для очистки. Выберите «Все», чтобы удалить все.
Установите все флажки и нажмите «Очистить сейчас».

Если это не сработает, попробуйте следующий метод и временно отключите кеш DNS.

Откройте новую вкладку и введите about:config в адресной строке Firefox.
Найдите network.dnsCacheExpiration , временно установите значение 0 и нажмите OK. После этого верните значение по умолчанию и нажмите OK.
Найдите network.dnsCacheEntries , временно установите значение 0 и нажмите OK. После этого верните значение по умолчанию и нажмите OK.

Выводы

Мы показали вам, как очистить или очистить кеш DNS в операционных системах Windows, Linux и macOS.

Пользователи Linux и macOS могут использовать команду dig для запроса и устранения проблем с DNS.

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

В данном материале разбираются настройки и принципы функционирования resolver в различных версиях BIND. Обсуждаются также особенности resolver, поставляемого в дистрибутиве клонов Unix.

Установлен ли вообще сервер доменных имен,
Если сервер установлен, то где (IP-адрес сервера доменных имен).
Если сервер установлен, то к какому домену относится машина.

Иногда название BIND (Berkeley Internet Name Domain) вводит новичков в заблуждение. Им кажется, что речь идет не о программе, а некой альтернативе другой системе доменных имен. Для того чтобы этого избежать, иногда вместо слова "domain" используют слово "daemon", обычно употребляющиеся для обозначения программ-демонов в системах Unix, которые находятся в памяти компьютера и выполняют служебные операции. Для того чтобы потом не повторяться, сразу поясним различия между DNS и BIND.

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

Главная задача resolver - принять запрос от прикладного программного обеспечения, провзаимодействовать с серверами DNS и вернуть в зависимости от запроса либо IP-адрес, либо доменное имя.

Очевидно, что можно это сделать двумя разными способами. Во-первых, путем итеративного опроса серверов, а, во-вторых, путем посылки рекурсивного запроса одному из серверов доменных имен, который этот запрос и обслужит.

Рис.1. Типовая схема взаимодействия Resolver с локальным сервером доменных имен.

На практике второй способ является наиболее распространенным. При этом согласно RFC-1034 речь идет о так называемом "усеченном" resolver (stub resolver).

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

В Windows 2000 предусмотрен кэширующий resolver, который запускается в системе в качестве сервиса по умолчанию. Существует возможность остановки и повторного пуска этого сервиса, а также просмотра результатов его работы. Важно отметить, что данный resolver умеет осуществлять "отрицательное" кэширование (negative caching). Это значит что, если на какой-либо запрос поступает отрицательный ответ, например, отсутствие данного доменного имени, то этот ответ запоминается, и в следующий раз прикладная программа получит "отлуп" прямо из кэша resolver, а не после процедуры безуспешного поиска по серверам доменных имен. Естественно, что "отрицательный" ответ хранится в кэше resolver ограниченное время (Windows 2000 TCP/IP. DNS Resolver Cache Service.).

На самом деле, появление нового resolver в Windows 2000 позволило решить некоторые проблемы, которые windows-системы доставляли системе доменных имен (см. "Полезные ссылки" [2]). Впрочем всех проблем новый resolver Microsoft так и не решил.

В рамках пакета BIND также существует кэширующий resolver, который фактически реализует функции кэширующего сервера доменных имен. При этом он реализован как процесс-демон. О его настройках и использовании мы остановимся в конце данного раздела.

Рассуждения о настройке resolver мы будем вести в терминах Unix системы, если речь пойдет о другом операционном окружении, то это будет оговорено отдельно.

Традиционно вся совокупность параметров настройки resolver задается в файле /etc/resolv.conf. Приведем примера этого файла и разберем назначение каждой из команд, которая может быть использована в файле настройки resolver.

Узанать локальное доменное имя просто - нужно выполнить команду Hostname: > hostname generate.polyn.kiae.su >

В данном случае локальное доменное имя - polyn.kiae.su.

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

то система расширит имя radleg именем домена, и будет искать машину с именем radleg.polyn.kiae.su.

Указанный выше пример - это только частный случай процедуры расширения неполного имени, которая используется функциями resolver. В литературе этот процесс называется применением списка поиска.

Различают два алгоритма применения списка поиска. Ниже представлен алгоритм, который использует resolver стандартной библиотеки libc.a. Большинство клонов Unix (различные версии этой операционной системы) поставляются именно с таким алгоритмом. Обычно именно он применялся в 4-ых версиях пакета BIND.

Будет выполнена подстановка по следующим правилам: если в качестве домена в resolv.conf указан домен polyn.kiae.su, то будет проверена следующая последовательность имен: paul.polyn; paul.polyn.polyn.kiae.su; paul.polyn.kiae.su. Последнее имя будет разрешено сервером доменных имен. Ниже приведен пример поиска IP-адреса по списку поиска для неполного имени paul.polyn:

В этом примере адрес был успешно найден. А вот пример, в котором адрес не был найден:

Запрашивался адрес для неполного имени paul.polyn.kiae, в resolv.conf в качестве локального имени домена было указано:

Если ваш resolver ведет себя приведенным выше способом, то следует проверить, что в директиве domain срока заканчивается не пробелом, а отображаемым символом. В противном случае возможны ошибки при разрешении имен.

Усечение до двухзвенного имени вызвано проблемой, которая описана в RFC-1535. Суть ее заключается в том, при полном поиске, т.е. при подстановке и однозвенного имени появлялась реальная возможность "улететь" совсем на другой хост.

Если введено имя хоста без точек, то оно расширяется локальным доменным именем
Если пункт 1 не дал результата, то введенное имя используется в качестве имени TLD.
Если введенное имя содержит составное, но не полное (fully qualified domain name - FQDN), имя, то в этом случае сначала проверяется введенное имя без расширения его локальным доменным именем.
Если пункт 3 не дал результата, то введенное имя расширяется локальным доменным именем.

Усечений локального доменного имени в этом алгоритме не предусмотрено.

Если по каким-либо причинам стандартный алгоритм применения списка поиска не устраивает, то тогда вместо директивы damin в resolv.conf применяют директиву search:

После директивы search через пробел или табуляцию указывают доменные имена, которые будут расширять введенное пользователем имя, если оно не относится к FQDN.

Следует заметить, что размер списка не безграничен. Всего он может содержать 256 символов.

При указании имени домена следует учитывать то, как будет в этом случае работать весь комплекс программного обеспечения, установленный на данном компьютере. Дело в том, что некоторые программы, sendmail, например, способны сами решать проблему определения IP-адресов по именам (то бишь использовать свои собственные функции при обращении к DNS, например, sm_gethostbyname()). В ряде случаев это может привести к противоречиям и ошибкам при функционировании такого сорта программ.

Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. Возможно указание нескольких серверов. Обычно - это не более трех серверов доменных имен.

На самом деле, если собирать библиотеку resolver самостоятельно, то число сервер, которое можно указывать в resolv.conf может быть установлено произвольно Определяется переменной MAXNS в файле /usr/include/resolv.h.

Вообще говоря, многие ограничения resolver заданы переменными в этом файле. Например, максимальное число элементов списка поиска - MAXDNSRCH, минимальный уровень вложенности локального доменного имени - LOCALDOMAINPARTS и т.п..

Если нет указаний на сервер доменных имен, то предполагается, что существует локальный сервер доменных имен. В старых версиях предполагалось, что он размещен по адресу 127.0.01, в новых версиях предполагается, что локальный адрес 0.0.0.0. Изменение адреса связано с проблемами, которые возникали при работе хоста через коммутируемые соединения. Предполагалось, что адрес умолчания - это адрес полученный через ifconfig в момент начальной загрузки машины. В этом случае интерфейс должен быть поднят и активен. Все такого сорта адреса интерфейсов маршрутизировались через 127.0.0.1. Но если интерфейс не поднимался, то возникало "залипание" и машина висла на этапе начальной загрузки. Изменение адреса позволяет решить эту проблему в рамках самого пакета.

Общая рекомендация такова: всегда нужно создавать файл resolv.conf и указывать в нем адрес локального сервера доменных имен.

Если указано несколько серверов доменных имен, то адрес каждого сервера указывается отдельной строкой в файле resolv.conf:

Опрос серверов осуществляется по порядку их указания в файле resolv.conf. Сначала будет опрашиваться 192.168.0.1, потом, если первый сервер не ответил, - 192.168.0.2, и последним, если не ответили первые два, - 192.168.0.3. Минимальный интервал времени между попытками по умолчанию (переменная RES_TIMEOUT в файле resolv.conf - 5 секунд). Обычно resolver делает 2 или 3 серии попыток (зависит от версии).

Resolver не упорядочивает сервера из директив nameserver по продолжительности времени отклика от них. Он их всегда опрашивает в том порядке, в котором они указаны в файле resolv.conf. Наиболее целесообразно первым указывать основной сервер доменных имен данного домена, а вторым дублирующий сервер доменных имен данного домена .

Обычно директивами domain, search, nameserer и ограничиваются при описании файла настройки resolv.conf. Более подробную информацию можно найти на страницах руководств системных администраторов операционных систем (ссылка на man Unix приведен в "полезных" ссылках).

И в заключении несколько слов об "умном" resolver пакета BIND 9. Он носит название lwresd и запускается в момент начальной загрузки системы как демон. Прикладные программы для работы с ним должны быть отредактированы с библиотекой вызовов этого resolver (BIND 9 lightweight resolver library).

Как операционная система, Windows имеет свои причуды и недостатки, однако для каждой проблемы также существует одинаково мощное решение. Такие инструменты, как Powershell, Run и IPConfig, помогают нам решать основные проблемы.

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

Что такое ipconfig?

Что такое DNS Resolve Cache and Flush

Хотя DNS Resolver Cache очень помогает нам гораздо быстрее получить доступ к Интернету и сэкономить на пропускной способности, он, безусловно, имеет свои недостатки. В большинстве случаев DNS-кеш отвечает за ошибки подключения, и это часто решается с помощью команды Flush DNS . Команда flushdns очень полезна, когда веб-сайт изменил свой IP-адрес и возник конфликт, поскольку вы все еще используете более старую запись, хранящуюся в кэше DNS.

Чтобы очистить локальный кэш DNS вашего компьютера, все, что вам нужно сделать, это перейти в командную строку и ввести следующую команду «ipconfig/flushdns». Однако иногда в командной строке выдается следующая ошибка «Не удалось очистить кэш DNS Resolver» «Проблема»

По мнению экспертов Microsoft, эта проблема возникает, когда компьютер с именем «DNS-клиент» отключен. Обычно это включается при запуске. Для того, чтобы включить службу, следуйте инструкциям ниже,

Откройте диалоговое окно «Выполнить», нажав «WIN + R»
Введите services.msc и нажмите ОК
Выберите DNS-имя и дважды щелкните по нему.
Проверьте настройки «Тип запуска», убедитесь, что вы выбрали «Автоматически».
Перезагрузите компьютер и DNS-клиент должен быть включен автоматически

Последнее средство

Проблема «Не удалось очистить кэш DNS Resolver» по-прежнему сохраняется? В таких случаях нужно взглянуть на журналы Windows, чтобы понять, что произошло. Откройте диалоговое окно «Выполнить», набрав «WIN + R», нажмите «ОК»> «Журналы Windows»> «Системы».

Также можно просто ввести ipconfig/displaydns ’, чтобы просмотреть весь кэш DNS. Кроме того, результаты также можно экспортировать, введя следующую команду «ipconfig/displaydns> cached-dns.txt».

Вот как вы решаете проблему «Не удалось очистить кэш DNS Resolver». В связи с этим некоторые из нас отключают DNS-клиента, опасаясь, что он поглотит вычислительные ресурсы, и это чистый миф. В большинстве случаев DNS-клиент будет использовать около 200-300 КБ памяти, и его отключение, безусловно, не поможет вам повысить производительность.

Max power!

Современные DNS-серверы — распределенные. Они находятся в каждой точке мира и кешируют данные с различными типами записей. Эта запись для почты, а эта — для SIP. A-запись вернет привычный всем IPv4-адрес, AAAA — IPv6. Потом и DNSSEC подтянулся. В общем, обросла фичами та табличка, но сама суть осталась неизменна. Отсюда и атаки с использованием DNS-сервера, которые актуальны до сих пор.

Например, есть такой тип запроса — AXFR. Это запрос на передачу зоны DNS. Он используется для репликации DNS-сервера, а если сервер настроен неправильно, то он может вернуть все используемые записи конкретного домена на этом сервере. Во-первых, этот missconfig позволяет узнать техническую информацию об инфраструктуре какого-либо сайта, какие тут IP-адреса и поддомены. Именно так украли исходники HL2 (может, поэтому так долго нет третьей :D)? А так как в подавляющем большинстве случаев DNS работает по протоколу UDP, подделать отправителя несложно.

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

На смену им пришел DNSSEC — ключи, которые используются в нем, много больше, чем отправленные данные, в результате DDoS и отказ в обслуживании ресурса, который стал жертвой «дудосеров», стало получить еще легче. Да и вообще, DNS Amplification («DNS-усиление») имеет смысл, даже когда сервер просто возвращает больше информации, чем ему отправляется, — например, отправляются несколько десятков байт, а возвращается несколько сотен.

DNS Rebinding / Anti DNS Pinning

Но и атаки на клиентов не в диковинку. Одна из атак позволяет злоумышленнику обойти SOP и тем самым выполнить любое действие в контексте браузера пользователя от его лица. Ну не совсем обойти, а использовать одну особенность для атаки. Имя ее DNS Rebinding (она же Anti DNS Pinning). Смысл таков.

Есть некий сайт, подконтрольный злоумышленнику. Домен имеет две A-записи: первая — сам сайт хакера, вторая — внутренний ресурс, который недоступен извне. Жертва открывает зловредный сайт, страница (с JavaScript) загружается, после чего сервер, откуда загрузился сайт, перестает отвечать на запросы.

Что делает браузер, когда не отвечает IP из первой записи? Правильно! Идет ко второй! При попытке обращения к домену злоумышленника он идет на внутренний ресурс, тем самым силами JS он может отправлять и принимать запросы, да и вообще творить черт-те что. Почему? Потому что с точки зрения браузера страница обращается на свой же домен. Вроде бы и жертва находится на какой-то странице, в то же время эта страница начинает брутить его роутер или почту и выносить оттуда письма.

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

WARNING

Кстати, вот подсказка охотникам за ошибками. Видишь, что IP отвечает на произвольное доменное имя, — расскажи разработчикам об этой атаке :).

А узнать, какие внутренние ресурсы доступны, можно с помощью проверки хеша браузера или с помощью вариации CSS History Hack. Последнюю использовали в исследовании этой уязвимости PTsecurity (ссылки на материалы, как всегда, в конце статьи). Но можно воспользоваться и еще одной фичей.

Как мы выяснили, если доменное имя имеет несколько IP-адресов, то браузер (или другой клиент) при недоступности первой записи переходит на вторую.

Тема такая. Специально настроенный сервер DNS возвращает на доменное имя злоумышленника подобные записи:

Теперь смотри. Когда жертва открывает страницу злоумышленника, на странице находится картинка, которая должна загрузиться с адреса test.evil.host, браузер резолвит доменное имя и получает массив IP-адресов.

Первым он пытается открыть 192.168.1.1:80, которого нет в нашей сети. Недоступен? Идет дальше и открывает 192.168.1.1.evil.host. Так как это подконтрольный сервер, мы фиксируем, что такого IP-адреса с таким портом нет.

И-и-и. Делаем перенаправление на test2.evil.host! И так до тех пор, пока ответа не будет или количество редиректов не достигнет 20 (обычно после браузер перестает ходить по редиректам, хотя Хром выводит ошибку и продолжает ходить).

XSS-инжекты через DNS

Некоторое время назад как иностранные, так и русскоязычные СМИ рассказывали об атаке, в которой в качестве TXT-записи отдается XSS-вектор. Настраиваем TXT-запись подобным образом (только замени квадратные скобки вокруг [script] на угловые <script>):

и там, где веб-приложение показывает эту запись, скрипт выполнится. Разумеется, если не фильтруются спецсимволы в пользовательских данных.

«А что тут такого?» — подумал я. У меня XSS-вектор в домене висит полдесятка лет (еще Agava не может ее нормально пофиксить, алерт вылезает прямо в кабинете), ведь завести подобную запись можно в любой панели управления. А как насчет других записей?

Вот что отдавал мой DNS-сервер

Самое смешное, что в самом начале теста я завел запись

(IP-адрес ns.hack нужно получить у домена ns.hack). И попробовал посовать этот домен во всякие формы сайтов. Ну и что ты думаешь?

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

Ну ладно, продолжим. Открываем dnschef.ini, пишем туда следующий конфиг (опять же, не забудь заменить скобки для [script]):

Также на сервере может быть закрыт доступ на 80/443-й порт, а DNS обычно открыт. Используя все эти трюки, я составил такой RCE-полиглот:

Команда ping выполнится на один из моих доменных имен, но, чтобы узнать, какой IP у домена, он придет ко мне — тут-то я и увижу, что выполнение произвольного кода сработало. Иду в конфиг, делаю так:

Ну и что? А ничего. Посовал на всяких сайтах домен, а отстука о выполнении произвольного кода нет. Не было. Где-то неделю. А потом та-да-ам!

Логи запросов с сервера

Действительно, кто-то собирал соответствие домен — запись и недостаточным образом фильтровал данные от DNS-сервера. Так может, таким образом можно и Shodan хакнуть? 🙂

Outro

Куда еще копать? DNS-туннели, DNS hijacking, OOB attacks, DNS cache poisoning, DNS flood. Я уверен, что можно таким образом выполнять SQL-инъекции и их будет много больше, — правда, это получается совсем вслепую. Хотя, может, попробуешь OOB-вектор в MS SQL?

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