DNS и разрешение имен

Domain Name System (DNS) — это фундаментальный механизм, который превращает удобные для человека доменные имена (например, ya.ru) в машинные IP-адреса (такие как 77.88.55.242), позволяя компьютерам находить друг друга в сети.

Хотя DNS чаще всего ассоциируется с интернетом, она играет ключевую роль и в корпоративных и домашних сетях:

  • В корпоративных сетях DNS используется для разрешения имён внутренних серверов (например, fileserver.corp.local).

  • В Active Directory (AD) DNS критически важен для работы доменных служб: аутентификации, групповых политик, поиска контроллеров домена.

Использует UDP/53 (запросы) и TCP/53 (большие ответы).

Структура доменного имени

sub4.sub3.sub2.example.com.

  1. . (корень) — невидимая "точка" в конце (по умолчанию опускается). Но если вы ее подставите в браузер, он вас поймет. Корнеая зона управляется организацией IANA. Имеет 13 логических серверов (более 1000 физических экземпляров по всему миру). Содержат информацию только о серверах TLD.

  2. com — домен верхнего уровня (TLD - top-level domain):

    • gTLD (общие): .com, .org, .net

    • ccTLD (национальные): .ru, .de, .jp

    • Специальные: .arpa, .local, .onion

  3. example — домен второго уровня. Регистрируются у аккредитованных регистраторов. Информация доступна в whois. Владелец домена может создавать поддомены любого уровня.

  4. sub2, sub3, sub4 — поддомены (управляются владельцем example.com). Глубина вложенности технически не ограничена. Но глубокая иерархия увеличивает время разрешения имён.

WHOIS - распределённая база данных о владельцах доменов и IP-адресов.

Для доменов:

  • Информация о регистраторе

  • Даты создания и окончания регистрации

  • Контакты владельца (часто скрытые из-за GDPR)

  • DNS-серверы домена

Для IP-адресов:

  • Принадлежность блоков адресов

  • Контакты администраторов сетей

DNS организована как распределённая база данных с древовидной структурой:

  • Корневые серверы (13 групп, обозначаемые от A до M)

  • Серверы доменов верхнего уровня (TLD: .com, .org, .ru)

  • Авторитативные серверы (управляющие конкретными доменами)

Каждый уровень делегирует ответственность за поддомены нижестоящим серверам или другому серверу. Например, владелец example.com может передать управление cdn.example.com на серверы Cloudflare через NS-записи.

Кодировка Punycode позволяет использовать кириллицу и эмодзи (например, россия.рф → xn--h1alffa9f.xn--p1ai).

CDN (Content Delivery Network) — технология доставки контента

CDN — это распределённая сеть серверов, расположенных географически близко к пользователям, которая ускоряет загрузку веб-контента (изображений, видео, скриптов) за счёт кэширования и минимизации задержек.

Как работает CDN?

  1. Пользователь запрашивает контент (например, картинку с сайта).

  2. CDN определяет его местоположение и направляет запрос к ближайшему серверу (PoP — Point of Presence).

  3. Если контент есть в кэше сервера — он сразу отдаётся. Если нет — сервер CDN загружает его с origin-сервера (основного источника), кэширует и затем отдаёт пользователю.

Примеры CDN-провайдеров

  • Cloudflare (бесплатный тариф + защита от атак).

  • Akamai (крупнейшая CDN в мире).

  • AWS CloudFront (интеграция с Amazon Web Services).

Поэтому вы часто сможете увидеть резолв их доменов из своей сети.

Обратное разрешение имён (Reverse DNS / PTR-записи)

Механизм преобразования IP-адреса → доменное имя (обратное обычному DNS). Пример: 8.8.8.8 → dns.google.

Зачем это нужно

  1. Верификация серверов

    1. Почтовые серверы проверяют PTR, чтобы отсечь спам: Если IP 1.2.3.4 не резолвится в mail.example.com, письма могут попасть в спам.

    2. SSH/FTP: Некоторые системы требуют PTR для подключения.

  2. Логирование и мониторинг В логах вместо 54.239.28.85 вы увидите aws-server.amazon.com — удобнее анализировать трафик.

Как работает технически

Для обратного разрешения используется специальный домен in-addr.arpa

Домен arpa

  • Первоначально создан для переходного периода ARPANET → Internet

  • Единственный TLD, управляемый непосредственно IETF

  • Сейчас содержит несколько поддоменов:

    • in-addr.arpa (IPv4)

    • ip6.arpa (IPv6)

    • e164.arpa (для телефонии ENUM)

IP записывается в обратном порядке:

8.8.4.4 → 4.4.8.8.in-addr.arpa

Для 4.4.8.8.in-addr.arpa создается специальная PTR-запись (PTR-записи настраивает владелец IP-адреса). 

# Пример записи в зоне 4.8.8.in-addr.arpa:  
8   IN   PTR   dns.google.

Эту запись используют инструменты nsllokup, dig -x и другие для обратного разрешения имен.

Основные типы DNS-записей

Тип
Назначение
Пример

A

IPv4-адрес

192.0.2.1

AAAA

IPv6-адрес

2001:db8::1

CNAME

Каноническое имя

www → example.com

MX

Почтовый сервер

10 mail.example.com

TXT

Произвольный текст

"v=spf1..."

NS

Сервер имён

ns1.example.com

PTR

Обратная запись

1.2.0.192.in-addr.arpa → example.com

ANY-запросы почти отключены из-за злоупотреблений (возвращают все записи домена).

Что происходит, если вбить в браузере ya.ru

  1. Проверка локального кэша:

    ОС проверяет кэш DNS (если запрос к ya.ru был недавно):

    • Windows: ipconfig /displaydns | find "ya.ru"

    • Linux: systemd-resolve --statistics или sudo journalctl -u systemd-resolved

  2. Чтение файла hosts:

    Проверка /etc/hosts (Linux/macOS) или C:\Windows\System32\drivers\etc\hosts (Windows) на наличие принудительного сопоставления:

    87.250.250.242 ya.ru  # Пример принудительной записи

  3. Обращение к DNS-резолверу: Запрос отправляется к DNS-серверу из настроек ОС (например, 8.8.8.8, провайдерский или корпоративный).

    • Если клиент в корпоративной сети:

      • Запрос сначала отправляется на внутренний DNS-сервер компании (например, ns1.corp.local). В среде Active Directory роль DNS-сервера обычно выполняет контроллер домена.

      • Этот сервер может:

        • Вернуть локальный IP, если домен внутренний (например, wiki.corp.local).

        • Делегировать запрос внешнему DNS, если домен публичный (как ya.ru).

    • Рекурсивный DNS-запрос (если предыдущие шаги не дали ответа)

      • Запрос уходит к провайдерскому или публичному DNS (например, 8.8.8.8).

      • Процесс разрешения:

  4. Кэширование результата

    • IP сохраняется в кэше корпоративного DNS и локальной машины.

При установке сетевого события, EventID 5156 не логирует DNS-имя узла, куда подключение было устанволено. А вот sysmon 3 логирует имя, при этом он беет его как раз и локального кеша. Поэтому редко возможны случаи, когда обращение было по IP и сопоставленное имя уже не актуально и не соотвествует действительности.

В корпоративных сетях часто принудительно резолвят в 127.0.0.1 фишинговые и вредоносные домены, чтобы машины из внутренней сети не могли получить к ним доступ. Это называется Domain Sinkholing (перенаправление домена в "сток").

NBNS, LLMNR - альтернативные протоколы разрешения имен

DNS, LLMNR, NBNS - эти три протокола используются для преобразования имён в IP-адреса в локальных сетях, но имеют критические различия в безопасности.

  • DNS - основная система разрешения имён в сети (и интернете).

  • LLMNR (Link-Local Multicast Name Resolution)

    • Multicast-запрос (UDP/5355, адрес 224.0.0.252)

    • Активен по умолчанию в Windows Vista и новее.

    • Используется, только если DNS не сработал.

  • NBNS (NetBIOS Name Service)

    • Устаревший протокол (UDP/137, Broadcast).

    • Включён в Windows для обратной совместимости.

    • Срабатывает последним, если все предыдущие методы не дали ответа.

NBNS/LLMNR — опасные пережитки прошлого в локальных сетях. Несмотря на устаревание, эти протоколы всё ещё включены по умолчанию в Windows и активно используются в корпоративных сетях.

Лучшая защита: отключить NBNS/LLMNR, усилить DNS и использовать современные методы аутентификации (Kerberos, SMBv3).

Как атакующие используют эти протоколы

  1. Жертва пытается подключиться к \\fileserver.

  2. DNS не отвечает → срабатывает LLMNR/NBNS. Это широковещательный запрос.

  3. Атакующий отвечает: "Я fileserver!".

  4. Жертва отправляет NTLM-хэш злоумышленнику. Либо же это позволяет атакующему провести атаку SMB Relay для доступа к ресурсам без пароля.

Часто этот механизм используется для записей WPAD.

WPAD — протокол автоматического обнаружения прокси-сервера в сети. Позволяет компьютерам автоматически находить прокси через DNS или DHCP. Браузеры запрашивают его автоматически.

  1. Компьютер жертвы ищет wpad.[домен] через DNS. Если в сети нет настоящего сервера WPAD-сервера, то отправляются широковещательные запросы LLMNR/NBNS.

  2. Атакующий отвечает: "WPAD — это я!". И тем самым заставляемжертву подключиться к своему фальшивому WPAD-серверу.

  3. Жертва загружает wpad.dat с сервера злоумышленника.

  4. Прокси-скрипт перенаправляет трафик через сервер атакующего.

    -> Атакующий может красть пароли, перенаправлять трафик или внедрять вредоносный код.

WPAD всё ещё включён по умолчанию в Windows 10/11 и macOS.

Защита: синкхолинг wpad.[doamin], отключение WPAD, отключение LLMNR, NBNS.

Инструменты:

  • Responder (автоматизирует атаку).

DGA (Domain Generation Algorithm) — алгоритм генерации доменных имен

DGA — это механизм, используемый вредоносным ПО для динамического создания большого количества псевдослучайных доменных имен, которые могут служить точками связи с Command & Control (C&C) серверами. Это усложняет блокировку вредоносного трафика и повышает устойчивость ботнетов.

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

  • Вредонос перебирает сгенерированные домены, пока не найдет активный C&C-сервер.

Антивирусы и фаерволы не успевают блокировать все варианты. Даже если 99% доменов заблокированы, 1% останется рабочим.

  • Подозрительные признаки:

    • Множество запросов к случайным доменам (asdfghjkl123.com, zxcvbnm789.net).

    • Короткое время жизни DNS-кэша (TTL ≈ 60 сек).

DNS-туннелирование: скрытая передача данных через DNS-запросы

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

Злоумышленник настраивает сервер, который:

  • Принимает DNS-запросы с закодированными данными (например, secret-data.evil.com).

  • Отправляет ответы, также содержащие скрытую информацию.

Жертва (зараженное устройство) отправляет DNS-запросы к подконтрольному домену, маскируя под легитимные запросы.

Данные разбиваются на части и встраиваются в поддомены:

1. Исходные данные: "hello" → кодировка в Base64 → "aGVsbG8="
2. DNS-запрос: aGVsbG8.evil.com
3. Сервер evil.com декодирует "aGVsbG8=" обратно в "hello".

Зачем используют DNS-туннелирование?

Цель

Пример

Обход фаерволов

В сетях, где запрещен HTTP/SSH, но разрешен DNS.

Кража данных

Экфильтрация паролей, документов через DNS.

Управление ботнетом

C&C-сервер отдает команды через DNS-ответы.

Как обнаружить DNS-туннелирование

  • Высокая частота запросов (100+ запросов в минуту от одного хоста).

  • Необычно длинные домены (gX7saB9Jk...tunnel.evil.com). Длина домена может достигать 253 символов (включая точки)

  • Нестандартные типы запросов (TXT, NULL, MX вместо A/AAAA).

34% вредоносных программ используют DNS для C&C (FireEye).

PreviousКриптография для аналитика SOCNextCheat Sheets

Last updated

Was this helpful?