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

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

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

* В корпоративных сетях DNS используется для разрешения имён внутренних серверов (например, `fileserver.corp.local`).
* В **Active Directory** (AD) DNS критически важен для работы доменных служб: аутентификации, групповых политик, поиска контроллеров домена.

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

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

`sub4.sub3.sub2.example.com.`

1. **.** (корень) — невидимая "точка" в конце (по умолчанию опускается). Но если вы ее подставите в браузер, он вас поймет. \
   Корнеая зона управляется организацией IANA. Имеет 13 логических серверов (более 1000 физических экземпляров по всему миру). Содержат информацию только о серверах TLD. &#x20;
2. **com** — домен верхнего уровня (TLD - top-level domain):
   * **gTLD** (общие): .com, .org, .net
   * **ccTLD** (национальные): .ru, .de, .jp
   * **Специальные**: .arpa, .local, .onion
3. **example** — домен второго уровня. Регистрируются у аккредитованных регистраторов. Информация доступна в whois. \
   Владелец домена может создавать поддомены любого уровня.&#x20;
4. **sub2, sub3, sub4** — поддомены (управляются владельцем example.com). \
   Глубина вложенности технически не ограничена. Но глубокая иерархия увеличивает время разрешения имён.&#x20;

<figure><img src="https://2619622447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSG1McEjK3LmDkNQ9xxhf%2Fuploads%2FzXy1ud8iMGTrYV5uMxoh%2Fimage.png?alt=media&#x26;token=6174e9c0-39d2-48bd-ace2-02095ae78155" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
WHOIS - распределённая база данных о владельцах доменов и IP-адресов.

Для доменов:

* Информация о регистраторе
* Даты создания и окончания регистрации
* Контакты владельца (часто скрытые из-за GDPR)
* DNS-серверы домена

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

* Принадлежность блоков адресов
* Контакты администраторов сетей
{% endhint %}

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

* **Корневые серверы** (13 групп, обозначаемые от A до M)
* **Серверы доменов верхнего уровня** (TLD: .com, .org, .ru)
* **Авторитативные серверы** (управляющие конкретными доменами)

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

{% hint style="info" %}
**Кодировка Punycode** позволяет использовать кириллицу и эмодзи (например, `россия.рф` → `xn--h1alffa9f.xn--p1ai`).
{% endhint %}

### **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).

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

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

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

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

1. **Верификация серверов**
   1. **Почтовые серверы** проверяют PTR, чтобы отсечь спам:\
      &#xNAN;_&#x415;сли IP `1.2.3.4` не резолвится в `mail.example.com`, письма могут попасть в спам_.
   2. **SSH/FTP**: Некоторые системы требуют PTR для подключения.
2. **Логирование и мониторинг**\
   В логах вместо `54.239.28.85` вы увидите `aws-server.amazon.com` — удобнее анализировать трафик.

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

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

<details>

<summary>Домен arpa</summary>

* Первоначально создан для переходного периода ARPANET → Internet
* Единственный TLD, управляемый непосредственно IETF
* Сейчас содержит несколько поддоменов:
  * `in-addr.arpa` (IPv4)
  * `ip6.arpa` (IPv6)
  * `e164.arpa` (для телефонии ENUM)

</details>

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

```
8.8.4.4 → 4.4.8.8.in-addr.arpa
```

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

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

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

## **Основные типы 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-сервера обычно выполняет контроллер домена.&#x20;
     * Этот сервер может:
       * **Вернуть локальный IP**, если домен внутренний (например, `wiki.corp.local`).
       * **Делегировать запрос внешнему DNS**, если домен публичный (как `ya.ru`).
   *   **Рекурсивный DNS-запрос (если предыдущие шаги не дали ответа)**

       * Запрос уходит к **провайдерскому или публичному DNS** (например, `8.8.8.8`).
       * Процесс разрешения:

       \


       <div data-full-width="true"><figure><img src="https://2619622447-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSG1McEjK3LmDkNQ9xxhf%2Fuploads%2F4vNBkQDB9tBogt93t60p%2FDeepSeek%20Mermaid%20May%2010%202025.svg?alt=media&#x26;token=df008a7c-87c8-44ff-ba51-b4bd93305c63" alt=""><figcaption></figcaption></figure></div>
4. **Кэширование результата**
   * IP сохраняется в кэше **корпоративного DNS** и локальной машины.

{% hint style="info" %}
При установке сетевого события, EventID 5156 не логирует DNS-имя узла, куда подключение было устанволено. \
А вот sysmon 3 логирует имя, при этом он беет его как раз и локального кеша. \
Поэтому редко возможны случаи, когда обращение было по IP и сопоставленное имя уже не актуально и не соотвествует действительности.&#x20;
{% endhint %}

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

## 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. Это широковещательный запрос.&#x20;
3. Атакующий отвечает: "Я fileserver!".
4. Жертва отправляет NTLM-хэш злоумышленнику. Либо же это позволяет атакующему провести атаку **SMB Relay** для доступа к ресурсам без пароля.

{% hint style="info" %}
Часто этот механизм используется для записей WPAD.&#x20;

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

1. Компьютер жертвы ищет `wpad.[домен]` через DNS. Если в сети нет настоящего сервера WPAD-сервера, то отправляются широковещательные запросы LLMNR/NBNS.
2. Атакующий отвечает: "WPAD — это я!". И тем самым заставляемжертву подключиться к своему фальшивому WPAD-серверу.&#x20;
3. Жертва загружает `wpad.dat` с сервера злоумышленника.&#x20;
4.  Прокси-скрипт перенаправляет трафик через сервер атакующего.

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

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

**Защита:** синкхолинг wpad.\[doamin], отключение WPAD, отключение LLMNR, NBNS.&#x20;
{% endhint %}

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

* **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).

{% hint style="info" %}
34% вредоносных программ используют DNS для C\&C (FireEye).
{% endhint %}
