EDNS Client Subnet (ECS, RFC 7871) — расширение EDNS0, которое позволяет рекурсивному DNS-резолверу передать авторитативному DNS «приблизительное местоположение» клиента в виде префикса подсети, а не полного IP-адреса. За счёт этого CDN/GeoDNS может вернуть A/AAAA на ближайший PoP/edge-узел и снизить задержки, особенно когда резолвер географически не рядом с пользователем.
Что такое ECS и зачем он нужен CDN/GeoDNS
Без ECS авторитативная сторона видит только IP рекурсивного резолвера. Если клиент пользуется публичным DNS или корпоративным резолвером в другом регионе, GeoDNS выбирает «ближайший PoP к резолверу», а не к пользователю. Отсюда типовая проблема: пользователь в одном городе, резолвер в другом — и трафик уезжает в «не тот» edge.
ECS пытается исправить именно это: резолвер добавляет к запросу информацию о клиентской подсети, а authoritative DNS использует её как сигнал для геораспределения ответов.
ECS повышает точность выбора CDN-узла в случаях, когда расположение рекурсивного DNS плохо отражает реальную географию пользователя.
Как ECS устроен на уровне протокола
ECS передаёт префикс (например, /24 для IPv4 или /56 для IPv6), а не полный адрес. Длина префикса — это политика резолвера: чем префикс короче, тем меньше точность, но лучше приватность и кэшируемость. Чем префикс длиннее — тем точнее попадание в PoP, но тем сильнее фрагментация DNS-кэша и выше риск деанонимизации.
Важно, что authoritative DNS может возвращать разные ответы на один и тот же QNAME в зависимости от ECS. Чтобы кэширование работало корректно, в ответе обычно присутствует информация о «scope» — для каких подсетей ответ допустимо переиспользовать.
Связь ECS с CDN: какие сигналы влияют на выбор PoP
На практике CDN направляет пользователя на edge, опираясь на комбинацию сигналов:
- Anycast-попадание DNS-запроса (куда приземлился запрос к резолверу/авторитативу);
- ECS (оценка географии пользователя по подсети);
- HTTP-сигналы после установления соединения (редиректы, внутренний роутинг, «догоняющая» оптимизация маршрута).
ECS особенно заметен в мобильных сетях и при CGNAT, при использовании публичных резолверов, а также в компаниях с централизованным корпоративным DNS. Эффект нужно оценивать метриками: RTT до edge, TTFB, доля «неправильных» PoP, межрегиональные запросы к origin.
Тёмная сторона ECS: приватность DNS и риски для корпоративных сетей
Компромисс ECS — DNS privacy. Даже если передаётся не полный IP, а подсеть, это всё равно дополнительные данные, которые уходят за пределы рекурсивного резолвера на сторону authoritative DNS (часто это CDN или внешний DNS-провайдер) и там могут логироваться.
Типовые практические риски:
1) Корреляция запросов. Подсеть — дополнительный идентификатор, который упрощает анализ трафика по операторам/регионам и иногда по отдельным офисам/провайдерам.
2) Подсветка корпоративной топологии. При слишком «точных» префиксах ECS может раскрывать диапазоны филиалов или отдельных площадок.
3) Шифрование DNS не отменяет ECS. DNS-over-TLS/DNS-over-HTTPS защищают канал «клиент↔резолвер», но ECS — это то, что резолвер сознательно пересылает дальше «резолвер↔authoritative». То есть шифрование до резолвера не убирает сам факт передачи геоинформации.
Если приоритет — минимизация передачи данных третьим сторонам, ECS часто рассматривают как нежелательный механизм, даже если он улучшает задержки.
Фрагментация кэша: почему ECS делает DNS «дороже»
Cache fragmentation — самый прикладной минус ECS для владельца рекурсивного резолвера. Когда ответ зависит от подсети, кэш перестаёт быть «один ответ на имя» и превращается в множество вариантов «имя + ECS-префикс».
- Падает hit ratio: больше запросов уходит на authoritative DNS, растёт внешний QPS.
- Растёт задержка при холодном кэше, особенно на CDN-зонах с короткими TTL.
- Сложнее планировать ресурсы: популярный домен может размножиться на сотни и тысячи вариантов в кэше.
- Усложняется инвалидация: при смене маппинга PoP «устаревшие» ответы живут в разных сегментах кэша.
На стороне authoritative DNS эффект тоже ощутим: больше уникальных комбинаций ECS, больше вычислений GeoDNS-правил, иногда больше размер ответа (EDNS), а значит выше риск проблем с UDP-фрагментацией и повторными попытками.
Типовые сценарии: когда ECS помогает, а когда мешает
Сценарий 1: пользователь и резолвер в одном регионе
Если ISP-резолвер действительно «рядом» с пользователем, ECS часто не даёт выигрыша: GeoDNS и так попадает по IP резолвера. В таком режиме ECS может лишь ухудшить кэшируемость.
Сценарий 2: публичный резолвер далеко
Классический кейс: клиент в одном регионе, а публичный резолвер географически «в другом». Без ECS — PoP выбирается по резолверу. С ECS — по пользовательской подсети, и задержка до edge обычно уменьшается.
Сценарий 3: корпоративный DNS в центральном офисе
Филиалы резолвят через центральную площадку. ECS может улучшить географию выдачи, но одновременно раскрывает структуру сети по подсетям и сильнее дробит кэш.
Сценарий 4: мобильные сети и CGNAT
В мобильных сетях ECS часто помогает «вернуть» пользователя в ближайший PoP, но слишком точный префикс повышает чувствительность к миграциям абонента между пулами адресов: кэш «не прогревается», растёт доля промахов.
Если вы дополнительно оптимизируете скорость сайта на уровне CDN, пригодится материал про ускорение WordPress на хостинге с CDN: ускорение WordPress на виртуальном хостинге с CDN.
Кто принимает решение об ECS: роли сторон
- Клиент обычно ECS не отправляет: это делает резолвер.
- Recursive resolver решает, добавлять ECS или нет, и с какой длиной префикса (отдельно для IPv4 и IPv6).
- Authoritative DNS решает, учитывать ECS при формировании ответа или игнорировать.
ECS работает только как «согласованное поведение»: резолвер должен отправить опцию, а authoritative — корректно её обработать и вернуть адекватный scope.
Практика диагностики: как проверить влияние ECS в проде
Диагностика строится на сравнении ответов на один и тот же домен через разные резолверы и из разных сетей. Минимально — посмотреть, меняются ли A/AAAA и TTL.
dig example.com A
dig example.com AAAA
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AДальше проверьте:
- возвращаются ли разные IP и насколько сильно «гуляет» география;
- какие TTL ставит CDN/GeoDNS и как быстро «перекладывается» трафик при сменах;
- появляются ли признаки EDNS/ECS в ответах (зависит от резолвера и от того, что именно он отражает в выводе).
Если вы управляете собственным резолвером (Unbound/BIND/PowerDNS Recursor и аналоги), обязательно посмотрите статистику кэша: изменения hit ratio, рост количества уникальных записей для популярных имён, нагрузку по исходящим запросам к authoritative.
Когда ECS включать, а когда лучше выключить
Обычно имеет смысл включать ECS, если
- много пользователей резолвят через удалённый резолвер (публичный DNS, централизованный корпоративный DNS);
- есть подтверждённая проблема неверного выбора PoP (RTT/TTFB выше ожидаемого, «странная» география в логах);
- ваш CDN/GeoDNS корректно работает со scope и не ломает кэширование.
Часто лучше выключить ECS, если
- на первом месте приватность и минимизация передачи данных третьим сторонам;
- резолвер и клиенты находятся в одном регионе (пользы мало, фрагментация кэша почти гарантирована);
- критичен hit ratio и стоимость/производительность рекурсивного кэша;
- TTL короткие, а геодробность высокая: кэш будет «расползаться» особенно быстро.
Компромиссные стратегии: как уменьшить вред без полного отказа
- Сократить длину ECS-префикса: меньше точность, но лучше приватность и кэшируемость.
- Включать ECS только для части зон: например, для latency-чувствительных API или доменов CDN-ассетов.
- Разнести резолверы по регионам: когда рекурсивный DNS «ближе к пользователю», необходимость в ECS часто отпадает.
- Проверять scope: слишком узкий scope увеличит кардинальность кэша, слишком широкий может приводить к неверным ответам для части пользователей.
Если вы владелец зоны и используете внешнего DNS-провайдера/CDN, уточните их политику по ECS: ожидаемые префиксы, TTL, поведение при отсутствии ECS, наличие защиты от чрезмерной дробности.
IPv6 и ECS: почему становится ещё сложнее
С IPv6 адресное пространство огромно, и «слишком точный» префикс ECS может резко увеличить кардинальность кэша. Поэтому многие резолверы/провайдеры используют относительно широкие значения (например, /56), чтобы кэш не превращался в бесконечную матрицу «имя + подсеть».
Если у вас много домашнего или мобильного IPv6 с частыми сменами префиксов, чрезмерная точность ECS может ухудшать предсказуемость: кэш прогревается хуже, а доля промахов растёт.
Чек-лист перед включением ECS
- Зафиксируйте цель. Что именно хотите улучшить: RTT до edge, TTFB, долю локальных PoP, межрегиональную стоимость.
- Снимите baseline. DNS latency, hit ratio, исходящий QPS к authoritative, распределение PoP.
- Оцените приватность. ECS — это передача подсети клиента третьей стороне (authoritative DNS/CDN); проверьте соответствие политикам и требованиям.
- Определите префиксы. Какие значения будут для IPv4 и IPv6 (source prefix-length).
- Прикиньте фрагментацию. Хватит ли памяти/кэша, не вырастет ли внешний QPS до проблемных значений.
- Подготовьте откат. Должно быть понятно, как быстро отключить ECS и вернуть прежнее поведение.
Итоги
ECS — рабочий инструмент для улучшения попадания в ближайший PoP, когда рекурсивный резолвер находится далеко от пользователя. Но за скорость часто платят приватностью DNS и фрагментацией кэша, что отражается на hit ratio, нагрузке и комплаенсе.
Правильная стратегия — включать ECS управляемо: измерять эффект, подбирать длину префикса, ограничивать зоны и заранее понимать, как изменится картина по кэшу и внешнему QPS.
