Протягом багатьох років традиційна архітектура системи доменних імен (Domain Name System — DNS) забезпечувала непередбачений, але надійний рівень конфіденційності. Коли пристрій запитував авторитетний сервер імен, запит завжди проходив через проміжний рекурсивний резолвер (Recursive Resolver), яким керував інтернет-провайдер (ISP) або оператор загальнодоступної служби DNS. Авторитетний сервер імен бачив лише IP-адресу рекурсивного вузла, завдяки чому справжня IP-адреса користувача залишалася прихованою за спільною інфраструктурою кешування.

Бурхливий розвиток глобальних мереж доставки контенту (Content Delivery Networks — CDNs) кардинально змінив цю схему. Сучасні хмарні сервіси масового масштабу покладаються на протоколи Anycast та GeoDNS для скерування клієнтів до топологічно та фізично найближчого периферійного кластера (Edge Node). Проте коли користувачі налаштовують централізовані рекурсивні перетворювачі у віддалених дата-центрах, географічні системи GeoDNS часто спрямовують запити до серверів за тисячі кілометрів. Це спричиняє істотне зростання мережевої затримки (RTT) та зниження швидкості передавання даних.

Щоб узгодити баланс між точністю маршрутизації в мережах CDN та ефективністю рекурсивного кешування, Інженерна рада інтернету (IETF) у травні 2016 року ухвалила специфікацію RFC 7871: «Client Subnet in DNS Queries», відому як EDNS Client Subnet (ECS). Попри оптимізацію мережевих маршрутів, новий стандарт спричинив масштабний витік метаданих. Згідно з протоколом, рекурсивні резолвери додають префікс підмережі користувача безпосередньо у вихідні пакети DNS, передаючи дані про географічну локацію авторитетним серверам по всьому світу — навіть коли трафік зашифровано протоколами DNS over HTTPS (DoH) або DNS over TLS (DoT).

[Класична рекурсивна архітектура DNS: IP-адреса клієнта прихована]
Клієнт (203.0.113.88) ───> Рекурсивний Резолвер (198.51.100.1) ───> Авторитетний Сервер
                                 [Бачить лише IP резолвера: 198.51.100.1]

────────────────────────────────────────────────────────────────────────────────────────

[Схема RFC 7871 EDNS Client Subnet (ECS): Передавання підмережі]
Клієнт (203.0.113.88) ───> Рекурсивний Резолвер (198.51.100.1)
                                 │
                                 ├─ Додає EDNS0 Option 8: Підмережа 203.0.113.0/24
                                 ▼
                            Авторитетний Сервер (CDN / Трекер)
                                 [Фіксує запитаний домен + домашню підмережу 203.0.113.0/24]

Структура протоколу RFC 7871: EDNS0 Option Code 8

Щоб зрозуміти механізм передавання географічних метаданих через ECS, варто проаналізувати двійкову структуру, затверджену стандартами RFC 6891 (EDNS0) та RFC 7871.

Традиційні повідомлення DNS через протокол UDP обмежені довжиною 512 байтів. Специфікація RFC 6891 запровадила механізми розширення DNS (Extension Mechanisms for DNS — EDNS0) у формі спеціального псевдозапису OPT Resource Record. Цей запис дає змогу клієнтам узгоджувати буфери обміну розміром до 4096 байтів і вставляти довільні опції різної довжини в секцію додаткових записів (Additional Records).

Стандарт RFC 7871 закріпив код опції 8 (Option Code 8) за полем client-subnet. Коли рекурсивний резолвер обробляє запит до доменного вузла з підтримкою ECS, він формує запис OPT, що містить чотири параметри:

                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-------------------------------+-------------------------------+
 |          OPTION-CODE          |         OPTION-LENGTH         |
 |            (0x0008)           |           (Змінна)            |
 +-------------------------------+-------------------------------+
 |            FAMILY             |SOURCE-NETMASK | SCOPE-NETMASK |
 +-------------------------------+---------------+---------------+
 |                           ADDRESS                             |
 |                    (Байти мережевої адреси)                   |
 +---------------------------------------------------------------+
  • FAMILY (16 бітів): Визначає сімейство мережевого протоколу (1 для IPv4 або 2 для IPv6).
  • SOURCE-NETMASK (8 бітів): Довжина маски клієнтської підмережі, яку надсилає резолвер. Для IPv4 стандарт RFC 7871 радить вживати префікс /24 (відкидаючи останні 8 бітів). Для IPv6 рекомендовано префікс /56.
  • SCOPE-NETMASK (8 бітів): Значення у відповіді авторитетного сервера, яке визначає діапазон підмережі, для якої відповідь вважається дійсною для кешування.
  • ADDRESS (Змінна довжина): Скорочене двійкове представлення клієнтської мережевої адреси (наприклад, 3 октети для підмережі /24).

Хоча скорочення до префікса /24 планувалося як компроміс для захисту приватності (об'єднуючи користувачів у групу з 256 адрес), практичні дослідження підтверджують, що провайдерські підмережі /24 безпосередньо прив'язані до конкретних міських вулиць, поштових індексів або корпоративних будівель.

Вектор стеження: Міждоменне профілювання та сенсори Passive DNS

Постійне передавання префіксів через механізм ECS перетворює стандартні запити DNS на платформу цифрового профілювання:

  1. Нівелювання шифрування каналу: Користувачі часто вмикають протоколи DoH або DoT на пристроях, розраховуючи на повну конфіденційність. Проте DoH та DoT захищають передавання лише на першому відрізку між пристроєм та рекурсивним сервером. Згідно зі стандартом RFC 7871, резолвер розшифровує запит і відправляє блок ECS авторитетним серверам сторонніх компаній у незашифрованому вигляді через звичайний порт UDP 53. Шифрування першого сегмента не рятує від подальшого витоку метаданих.
  2. Збирання мережевої телеметрії авторитетними платформами: Авторитетні сервери рекламних корпорацій, аналітичних агентств та медіа-гігантів обробляють мільярди запитів щодня. Фіксуючи вхідний префікс ECS, ці компанії формують поведінкові хронологічні карти, відстежуючи, які саме ресурси переглядають абоненти певної домашньої підмережі протягом доби.
  3. Наповнення баз пасивного моніторингу (Passive DNS): Служби аналізу кіберзагроз розгортають сенсори Passive DNS (pDNS) для фіксації інтернет-трафіку. Присутність записів ECS дає змогу архіваторам пов'язувати кожен домен із конкретною фізичною підмережею, спрощуючи деанонімізацію користувачів.
Конфігурація протоколу Захист першого відрізка Приватність на рекурсивному вузлі Відображення на авторитетному вузлі Точність маршрутизації CDN
Звичайний DNS (ISP) Відсутній (UDP 53) Низька (провайдер бачить запити) IP резолвера (Без ECS) Середня
Публічний DoH (Увімкнено ECS) Високий (TLS 1.3 / HTTP/2) Залежить від правил служби Підмережа клієнта (/24 або /56) Дуже висока
Публічний DoH (Вимкнено ECS) Високий (TLS 1.3 / HTTP/2) Висока Лише IP резолвера Середня
Внутрішній DNS VPNRice Повна інкапсуляція L3 Anycast-система без журналів Вихідний IP шлюзу VPN (Без ECS) Оптимальна та приватна

Розподіл індустрії: Конфлікт анонімності та оптимізації маршрутів

Через суперечність між ефективністю розподілу трафіку та правом на конфіденційність провідні оператори DNS обрали різні підходи:

  • Google Public DNS (8.8.8.8): Передає параметри ECS партнерським серверам для оптимізації CDN, але підтримує клієнтські запити з нульовим префіксом джерела (0.0.0.0/0).
  • OpenDNS / Cisco Umbrella: Продовжує транслювати метадані клієнтських підмереж для забезпечення географічного розподілу навантаження.
  • Cloudflare (1.1.1.1): Принципово відмовляється від RFC 7871. Політика сервісу забороняє додавання префіксів підмереж до запитів, надаючи абсолютну перевагу захисту персональних даних.
  • Quad9 (9.9.9.9): Дотримується суворих стандартів безпеки і цілеспрямовано вилучає атрибути ECS з усіх вихідних потоків.

Захист від витоків ECS за допомогою тунелювання L3 та приватних резолверів

Вимкнення ECS на рівні окремих програм не дає гарантованого результату, оскільки пристрій не здатний змусити сторонній рекурсивний сервер скасувати генерацію Option Code 8. Надійний захист потребує комплексної багаторівневої структури:

[Робоча станція / Мобільний пристрій]
                 │
                 ├─ Запит DNS до внутрішнього шлюзу (наприклад, 10.8.0.1)
                 ▼
[Віртуальний мережевий адаптер: wg0 / tun0]
   Інкапсуляція мережевого рівня (Layer 3) через WireGuard / RiceGuard
   Автентифіковане шифрування: ChaCha20-Poly1305 (ключ 256 бітів)
                 │
                 ▼
[Фізичний адаптер Wi-Fi / Канал провайдера]
   Передавання непрозорих пакетів UDP; провайдер не бачить запитів
                 │
                 ▼
[Anycast-шлюз та власний рекурсивний резолвер VPNRice]
   1. Повне вилучення метаданих EDNS Client Subnet (FAMILY=0, SOURCE=0)
   2. Автономне рекурсивне оброблення через власні кореневі сервери
   3. Сторонній авторитетний сервер бачить лише адресу дата-центру VPN

Під час маршрутизації через платформу VPNRice із протоколом RiceGuard:

  • Перехоплення потоків DNS усередині тунелю: Усі запити на порти 53, 853 та DoH спрямовуються до ізольованого внутрішнього резолвера. Провайдер фізичної мережі позбавлений доступу до відкритих пакетів.
  • Повна нейтралізація опцій ECS: Сервери VPNRice автоматично блокують передавання атрибутів RFC 7871. Якщо зовнішній авторитетний сервер вимагає надання ECS, шлюз повертає FAMILY=0 та SOURCE-NETMASK=0.
  • Нормалізація вихідного Anycast IP: Зовнішні авторитетні системи фіксують лише публічну адресу дата-центру VPNRice. Географічні запити спрямовуються до найближчих до шлюзу серверів, забезпечуючи високу швидкість без загрози витоку реальних координат користувача.

Практична перевірка параметрів передавання ECS

Системні інженери та спеціалісти з кібербезпеки можуть перевірити наявність опції ECS у своїх з'єднаннях за допомогою консольних утиліт:

# 1. Перевірка надсилання префікса ECS поточним резолвером через Google TXT endpoint
dig +subnet=0.0.0.0/0 TXT o-o.myaddr.l.google.com @8.8.8.8 +short

# 2. Аналіз трафіку у Wireshark / tshark для виявлення Option Code 8
# Фільтр відображення Wireshark: dns.edns0.opt.code == 8

# 3. Вимкнення передавання ECS у конфігураційному файлі Unbound (unbound.conf):
# server:
#     send-client-subnet: no
#     max-udp-size: 1232

# 4. Вимкнення передавання ECS у конфігурації BIND 9 (named.conf):
# options {
#     ecs-server no;
#     ecs-client no;
# };
  • Обирайте резолвери без підтримки ECS: Працюючи без тунелю, скеровуйте запити на сервери, які гарантують відмову від передавання підмереж (Quad9, Cloudflare).
  • Підтримуйте постійну активність VPN: Скеровуйте весь трафік через тунелі WireGuard або RiceGuard для повної ізоляції запитів усередині захищеної Anycast-мережі.
  • Контролюйте інтерфейси Dual-Stack: Перевіряйте з'єднання IPv6, щоб запобігти витоку адресних префіксів /56 або /64 SLAAC повз зашифрований канал.