Кратко

  • Авторитетный сервер возвращает SCOPE PREFIX-LENGTH, задавая сеть, в пределах которой кэшированный ответ можно применять к следующим клиентам.
  • Рекурсивный резолвер отдельно выбирает SOURCE PREFIX-LENGTH — число битов клиентской сети, передаваемых вверх в усечённом виде.
  • Ни префикс, ни область не доказывают личность, согласие или точную географию. RFC 7871 описал издержки приватности и кэша, а RFC 8932 рекомендовал избегать ECS либо минимизировать и раскрывать его применение.

Ответ, который наследуют другие

В ECS-запросе длина области равна нулю. Содержательный SCOPE PREFIX-LENGTH появляется в ответе: он сообщает, сколько старших битов определяют сеть, охваченную выбранным результатом. Короткая область разрешает использовать ответ шире. Более длинная может означать, что исходного префикса не хватило для желаемой точности выбора.

Область превращается в правило кэша. Обычный поиск всё ещё начинается с имени, типа и класса, но затем ECS-совместимый резолвер выбирает RRset по префиксному совпадению. Ответ связывается с описанной сетью, и клиенты, подходящие под неё, могут получить результат запроса, который они сами не отправляли авторитетной стороне.

Если ECS в ответе нет, его обычно считают ответом с областью /0, пригодным для любых клиентских адресов. При REFUSED совместимый резолвер повторяет запрос без ECS, чтобы отличить отказ от опции от иных соглашений вокруг того же кода.

Это наследование не является подтверждением качества. RFC 7871 не определяет метод, по которому авторитетная сторона выбирает адаптированный ответ. Область не гарантирует ближайший, самый быстрый или доступный сервер и не удостоверяет географию.

Как появился клиентский префикс

Обычно авторитетный сервер видит адрес рекурсивного резолвера, а не исходной сети. Это может быть приемлемой топологической подсказкой, когда резолвер близок к пользователю. Централизованный сервис, однако, способен обслуживать удалённые сети, и адаптация по его собственному адресу не обязательно подходит клиенту.

ECS, документированный RFC 7871, позволяет посреднику включить сведения о сети происхождения в запрос вверх. Опция содержит семейство адреса, длину исходного префикса, длину области и переменное поле адреса. Для IPv4 и IPv6 адрес обрезается до значимых битов и дополняется лишь до последнего необходимого октета. Полный адрес передавать не требуется.

Резолвер задаёт максимальную длину, с которой готов работать в кэше, и должен выбрать префикс короче полного адреса. Если входящий запрос уже ограничивает раскрытие меньшей длиной, следующий пересыльщик не вправе её увеличить. Так SOURCE PREFIX-LENGTH ограничивает контекст, который посредник раскрывает от имени клиента.

Два числа не описывают человека

Исходная длина и область отвечают на разные вопросы. Первая определяет, сколько сетевых битов отправлено. Вторая — насколько широко результат можно повторно использовать. Совместно они образуют двустороннее правило раскрытия и кэширования, но не идентификационную запись.

Топологическая близость лишь слабо связана с расстоянием на карте. Префикс не доказывает личность, устройство, приложение или согласие. Даже проверка полей ответа имеет более узкое назначение: RFC рекомендует отбрасывать ответы, чьи ненулевые поля идентичности запроса не совпадают, ограничивая некоторые пути подмены и загрязнения кэша. Это не аутентифицирует клиентский контекст.

Разделённый кэш и его цена

Для одного имени, типа и класса могут храниться разные ответы по сетям. Число записей растёт, доля повторного использования снижается, нагрузка на память и серверы может увеличиться. RFC 7871 поэтому рекомендовал держать ECS выключенным по умолчанию, включать при ясной выгоде и ограничивать количество сетей и ответов на запрос. Нельзя раскрывать больше адресных битов, чем резолвер готов кэшировать.

Такая цена важна для исторической оценки. Механизм локальности изменил не только содержимое запроса, но и устройство общего ресурса: кэш стал хранить последствия политик резолвера и авторитетного сервера раздельно для сетей.

/0 и реальная возможность отказаться

Стаб-резолвер может задать SOURCE PREFIX-LENGTH равным нулю. Получив это значение, рекурсивный сервис не должен добавлять адрес клиента в последующие запросы; он может убрать ECS или использовать собственную информацию. Пересыльщики обязаны сохранять уже установленное ограничение.

RFC 7871 отмечал в 2016 году, что практическая возможность выразить предпочтение зависела от того, предоставляет ли программное обеспечение такой контроль. Это историческое наблюдение, а не современная перепись. В используемых источниках нет текущих показателей внедрения, списка публичных резолверов или сравнения поставщиков.

RFC 8932 в 2020 году рассмотрел ECS применительно к сервисам приватного DNS. Шифрование защищает участок от клиента до резолвера от некоторых наблюдателей, но сам резолвер продолжает видеть запрос и может отправлять информацию дальше. Рекомендации требуют уважать /0, избегать ECS вверх либо предлагать вариант без него. Если ECS нужен, следует использовать самый короткий практически достаточный префикс, по возможности ограничить получателей и раскрыть фактическую длину и политику.

DNSSEC решает другую задачу

Область ECS не становится аутентифицированной благодаря DNSSEC. RFC 7871 рекомендует область /0 для большинства DNSSEC-записей; RRSIG остаётся связанным с подписанным RRset. Валидация не подписывает решение резолвера раскрыть префикс, не доказывает местоположение и не подтверждает политику авторитетного выбора.

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

Источники