DNS-маршрутизация по IP резолвера не всегда отражает реальное местоположение пользователя.
В классических географических DNS-решениях решения обычно принимаются по IP-адресу DNS-резолвера. Когда пользователь полагается на удалённый публичный резолвер, DNS-система видит местоположение резолвера, а не фактическое положение пользователя. В результате пользователь в Турции может быть направлен в дата-центр в неправильном регионе или в неоправданно удалённый PoP.
Однослойной маршрутизации только по странам также недостаточно для большинства корпоративных сценариев. Внутри одной страны разные операторы, разные ASN, разные города или разные приватные сетевые блоки могут требовать отдельной маршрутизации. Потребности вроде телеком-пиринга, соответствия, задержки, выбора PoP в стиле CDN и маршрутизации кампаний требуют более тонкой грануляции.
Использование онлайн-API GeoIP для географических решений несёт дополнительные риски. Отправка контекста DNS-запроса во внешний сервис может создать проблемы для места хранения данных и приватности запросов. Зависимость столь критичного слоя принятия решений, как GTM, от внешнего API также является слабым местом для операционной непрерывности.
Правильная модель — поддерживать информацию о подсети клиента, принимать географические решения через локальные базы на устройстве и расширять топологические правила за пределы страны, включая город, ASN и CIDR. Формирование контролируемого финального ответа через fallback-записи при отсутствии совпадения должно быть частью той же модели.
TR7 DNS Geographic Routing даёт именно это: EDNS Client Subnet, пятимерные топологические правила, офлайн GeoIP-базы и выбор записей на основе селектора приближают DNS-ответы к реальному контексту пользователя.
Наш подход
TR7 реализует географические DNS-решения через подсеть клиента, многомерную топологию, офлайн GeoIP и Lua-конвейер выбора.
EDNS Client Subnet использует реальную подсеть клиента вместо местоположения резолвера
С поддержкой EDNS Client Subnet DNS-решение больше не привязано только к IP резолвера. Географические решения принимаются по фактической подсети клиента, обеспечивая более точный выбор ЦОД или PoP.
Пятимерная топология выходит за рамки решений на уровне страны
TR7 может определять правила по сети/CIDR, стране, городу, континенту и ASN. Каждое правило может быть записано с нормальным или negate-поведением.
Офлайн GeoIP-базы удерживают контекст запроса на устройстве
Географические решения принимаются по локально хранящимся на устройстве базам ASN, City и Country. Контекст DNS-запроса никогда не отправляется во внешний GeoIP-сервис.
Топологический конвейер оценивает правила, условия и записи вместе
TR7 оценивает топологические правила по порядку и выбирает совпадающие кандидаты записей через логику селектора. Разные стратегии распределения могут быть построены с поведением all, closest, round-robin, weighted или random.
Возможности
DNS Geographic Routing формирует DNS-ответы на основе страны, города, ASN и CIDR с точностью подсети клиента.
Поддержка EDNS Client Subnet позволяет принимать решения ближе к реальному местоположению пользователя
TR7 может учитывать информацию о подсети клиента вместо опоры на IP резолвера. Это снижает риск перенаправления клиентов, использующих публичные резолверы, в неправильный регион. Географические DNS-решения приближаются к реальной сети пользователя. Это особенно критично для точного выбора ЦОД в сервисах с глобальным пользовательским трафиком.
Маршрутизация по странам удовлетворяет требования соответствия и производительности
Грануляция по стране позволяет формировать разные DNS-ответы на основе кода страны клиента. Выбор дата-центра может быть подстроен под Европу, Турцию, Ближний Восток или конкретную страну. Контроль на уровне страны важен для финансовых учреждений, организаций общественного сектора и сред с требованиями к месту хранения данных. Коды стран нормализуются для более согласованного сопоставления.
Маршрутизация по континентам обеспечивает широкое региональное распределение трафика
Грануляция по континенту позволяет направлять клиентов в разные группы записей на уровне континента. Можно определить отдельные наборы PoP или ЦОД для Европы, Азии, Северной Америки или других регионов. Этот подход даёт простое решение там, где детализация по странам не требуется, но региональная близость важна. Полезно в сценариях глобальных SaaS и доставки контента.
Маршрутизация по городам поддерживает локальные кампании и выбор PoP
Грануляция по городу сопоставляет пользователей из конкретных городов с разными записями. Можно формировать отдельные ответы landing-page, edge PoP или дата-центров для Стамбула, Анкары или других городов. Полезно для локальных кампаний, соответствия на уровне города или целей низкозадержной маршрутизации трафика. Информация о городе оценивается по офлайн-базе GeoIP.
Правила сети на основе CIDR разделяют приватные сети и сегменты клиентов
Грануляция по сети/CIDR позволяет определять пользовательские DNS-ответы для конкретных блоков IPv4 или IPv6. Корпоративные подсети клиентов, партнёрские сети, приватные диапазоны операторов или внутренние блоки доступа могут разделяться таким образом. Маршрутизация на уровне CIDR более детерминирована, чем по стране или городу. Мощно для эндпоинтов на клиента или выбора пирингового ЦОД.
Маршрутизация по ASN уточняет решения по операторам и пирингу
Грануляция по ASN выбирает DNS-ответ на основе оператора или владельца сети, к которой подключён клиент. Можно возвращать отдельные записи ЦОД для конкретных телеком-операторов, ISP-сетей или предпочтений CDN-пиринга. Этот подход создаёт ценность там, где разные операторы в одной стране имеют разное качество сети. Трафик маршрутизируется по реальной сетевой топологии, а не по национальной границе.
Флаг negate включает географические правила с исключением
Поведение negate можно применить к любому топологическому правилу. Это позволяет создавать обратные правила вида «каждая страна, кроме этой», «каждый ASN, кроме этого» или «каждая сеть, кроме этого CIDR». Логика исключения полезна для применения, разделения доступа, доставки альтернативного IP или сценариев исключения регионов высокого риска. Операторы могут строить как совпадающие, так и исключающие политики.
Fallback-записи формируют контролируемый ответ при отсутствии совпадения
Если географическое топологическое правило не даёт кандидатов записей, могут активироваться fallbackRecords. Эти записи могут представлять дефолтный ЦОД, сервис обслуживания или глобальный эндпоинт. Поведение fallback гарантирует контролируемый ответ последней инстанции вместо пустого или неожиданного DNS-ответа. Особенно важно для новых регионов или отсутствующих совпадений GeoIP.
Геополитика на запись задаёт разное поведение внутри одного домена
TR7 может определять независимые топологические политики для каждой записи. Под одним доменом A-записи, AAAA-записи или разные сервисные записи могут работать с разными географическими решениями. Это позволяет применять разные стратегии маршрутизации к разным компонентам приложения под одним доменом. Операторы управляют топологическим поведением на уровне записи, а не глобально.
Опции селектора распределяют по совпадающим кандидатам записей
Географическое совпадение может дать несколько кандидатов записей. TR7 затем может выбирать среди этих кандидатов через поведения селектора, такие как all, closest, round-robin, weighted round-robin, random или weighted random. Географическая фильтрация и распределение нагрузки таким образом объединяются в одной цепочке. Например, weighted-выбор можно применить между двумя ЦОД внутри одной страны.
Офлайн GeoLite2-базы снижают риск, связанный с местом хранения данных
Базы ASN, City и Country хранятся на устройстве, и географические решения принимаются локально. Контекст DNS-запроса никогда не отправляется во внешний GeoIP API. Это важное преимущество для организаций с ожиданиями приватности запросов и места хранения данных. Поток обновлений следует планировать отдельно; поведение страницы опирается на офлайн-модель решений.
Осведомлённость о TTL планируется вместе с поведением гео-кеша
Значение TTL для каждой DNS-записи влияет на поведение географической маршрутизации. Более короткий TTL даёт преимущества для быстрых изменений политики и failover; более длинный — снижает нагрузку на кеш резолверов. При проектировании гео-маршрутизации TTL, работоспособность ЦОД и цели распределения трафика следует планировать вместе. Оператор задаёт баланс между производительностью и скоростью изменений.
Операционная глубина
Географическая маршрутизация DNS эксплуатируется рядом с типами топологических правил, нормализованными полями, поведением рендеринга CIDR, fallback-логикой и пределами выполнения Lua.
Типы топологических правил
Конвейер топологических решений использует типы правил network, country, city, continent и ASN. Каждый тип правила может оцениваться с положительным или negate-поведением. Эта структура позволяет комбинировать несколько географических измерений принятия решений внутри одной записи.
Нормализация страны и континента
Коды стран и континентов приводятся к нижнему регистру перед сравнением. Это предотвращает нарушение совпадений из-за различий в регистре из разных источников. Нормализованные значения делают написание политик более согласованным.
Поведение рендеринга CIDR
Правила сети оценивают IP и CIDR вместе. Если CIDR не указан, может использоваться поведение точности на IP для IPv4. Эта модель позволяет обрабатывать как приватные сетевые блоки, так и одиночные IP-цели в рамках одной структуры политики.
Покрытие GeoIP-баз
TR7 может принимать географические решения по базам ASN, City и Country. Эти три источника данных образуют основу для решений по ASN, городу, стране и континенту. Поскольку базы находятся на устройстве, решения во время выполнения не зависят от внешнего сервиса.
Поведение при отсутствии совпадения
Если оценка топологии не даёт кандидатов записей, проверяется fallbackRecords. Если fallback существует, может быть сформирован финальный ответ со статусом failSafe. Если fallback не определён, может произойти пустое или стандартное DNS-поведение — поэтому план fallback рекомендован для всех производственных записей.
Пределы выполнения Lua
Топологический выбор работает через Lua-конвейер принятия решений. Пределы выполнения и интервалы health-check помогают сохранять DNS-решения детерминированными и контролируемыми. Влияние на производительность следует учитывать для очень сложных наборов правил.
Когда использовать
Маршрутизация по оператору с разделением ASN в Турции
Для разных операторских сетей в Турции могут возвращаться разные записи пирингового ЦОД. Топологическое правило ASN помогает направить пользователей внутри одной страны на более точный сетевой путь.
Выбор ЦОД по странам для европейских финансовых сервисов
Для стран вроде Германии, Франции или Италии можно определять разные цели соответствия или места хранения данных. Правило country возвращает подходящую запись ЦОД на основе страны клиента.
Маршрутизация PoP по континентам для глобального распределения
Глобальные сервисы могут направлять клиентов в наиболее подходящие PoP или группы дата-центров на уровне континента. Правила continent и поведение селектора можно комбинировать для регионального распределения нагрузки.
Географическое исключение для доставки альтернативного ответа
С флагом negate можно возвращать разные записи клиентам вне конкретных стран, ASN или CIDR. Эта модель полезна для применения, лицензирования, соответствия или разделения регионов высокого риска.
Маршрутизация кампаний и landing-страниц по городам
Пользователям из городов вроде Стамбула или Анкары можно возвращать собственный IP landing-страницы. Правило city обеспечивает точную DNS-маршрутизацию для сценариев маркетинга и локальной доставки сервисов.
Часто задаваемые вопросы
Как работает EDNS Client Subnet и почему это важно?
Для каких географических измерений можно определять топологические правила?
Зависит ли GeoIP-решение от внешнего сервиса?
Когда и как активируются fallback-записи?
Как поведения селектора работают вместе с географической маршрутизацией?
В каких сценариях используется флаг negate?
Привяжите DNS-решения к реальному местоположению пользователя
Географическая DNS-маршрутизация с EDNS Client Subnet, пятимерными топологическими правилами и офлайн GeoIP. Давайте пройдёмся по живой настройке на вашей собственной инфраструктуре.