Руководство по подсети клиента EDNS (ECS)

Введение

RFC 7871 — Клиентская подсеть в DNS-запросах — определяет механизм для рекурсивных распознавателей, таких как Google Public DNS, для отправки частичной информации об IP-адресе клиента на авторитетные серверы имен DNS. Сети доставки контента (CDN) и чувствительные к задержке службы используют это для предоставления точных ответов с географической привязкой при ответе на запросы имен, поступающие через общедоступные преобразователи DNS.

RFC описывает функции ECS, которые должны быть реализованы авторитетными серверами имен; но разработчики не всегда следуют этим требованиям. Существуют также проблемы с эксплуатацией и развертыванием ECS, которые не решает RFC, которые могут вызвать проблемы для распознавателей, таких как Google Public DNS, которые автоматически определяют поддержку ECS на авторитетных серверах имен, а также распознавателей, которым требуется белый список ECS, таких как OpenDNS .

Эти рекомендации призваны помочь авторитетным разработчикам и операторам DNS избежать многих распространенных ошибок, которые могут вызвать проблемы для ECS.

Важно: при развертывании ECS для авторитетных серверов имен и зон DNS следуйте всем рекомендациям , чтобы убедиться, что Google Public DNS всегда отправляет данные ECS на серверы имен, возвращает правильные ответы клиентам с географической привязкой и может разрешать имена в ECS- включенные зоны DNS (несоблюдение этих рекомендаций может иногда вызывать ответы SERVFAIL).

Определения терминов

Мы используем следующие термины для описания операций ECS:

• Сервер имен реализует (или поддерживает ) ECS, если он отвечает на запросы ECS ответами ECS с соответствующими параметрами ECS (даже если параметры ECS всегда имеют глобальную длину префикса области /0).

  Примечание. Ответы ECS ДОЛЖНЫ ¹ соответствовать семейству адресов ECS , адресу и длине префикса источника соответствующих запросов. В противном случае сервер имен неправильно реализует ECS, и Google Public DNS может не отправлять ему запросы ECS.

• Зона активируется ECS, если запросы ECS к ее серверам имен, отправленные с ненулевым префиксом источника, получают ответы ECS с ненулевой областью действия.

Рекомендации для авторитетных серверов имен

1. Все авторитетные серверы имен для зоны с поддержкой ECS должны включить ECS для зоны.

   • Даже если только один сервер имен не реализует ECS или не включает его для зоны, он быстро становится источником большей части кэшированных данных. Поскольку его ответы имеют глобальную область действия, они используются (до истечения срока жизни) как ответы на все запросы для одного и того же имени (независимо от клиентской подсети). Ответы от серверов , которые реализуют ECS и включают его, используются только для запросов от клиентов в определенной области, поэтому вероятность их использования гораздо ниже, чем ответов глобальной области.

2. Полномочные серверы имен, которые реализуют ECS, ДОЛЖНЫ ² отправлять ответы ECS на запросы ECS для всех зон, обслуживаемых с IP-адреса или имени хоста NS, даже для зон, в которых не включена ECS.

   • Google Public DNS автоматически определяет поддержку ECS по IP-адресу, а не по имени хоста сервера имен или зоне DNS, поскольку количество адресов меньше, чем количество имен хостов сервера имен, и намного меньше, чем количество зон DNS. Если авторитетный сервер имен не всегда отправляет ответы ECS на запросы ECS (даже для зон, не поддерживающих ECS), Google Public DNS может перестать отправлять ему запросы ECS.

3. Полномочные серверы имен, которые реализуют ECS, должны отвечать на все запросы ECS ответами ECS, включая отрицательные и реферальные ответы.

   • Те же проблемы с автоматическим определением поддержки ECS применимы и здесь.

   • Отрицательные ответы (NXDOMAIN и NODATA) ДОЛЖНЫ ³ использовать глобальную область /0 для лучшего кэширования и совместимости с RFC 7871.

   • Помимо NXDOMAIN и NODATA (NOERROR с пустым разделом ответа), другие ответы об ошибках на запросы ECS (в частности, SERVFAIL и REFUSED) должны включать соответствующий параметр ECS с глобальной областью действия /0.

     • Если авторитетный сервер имен пытается снять нагрузку с DoS-атаки, он может вернуть SERVFAIL без данных ECS; это приводит к тому, что Google Public DNS прекращает отправлять запросы с ECS (что может уменьшить количество отправляемых законных запросов, но не повлияет на случайные запросы атаки поддоменов). Уменьшение нагрузки законных запросов во время DoS-атаки может повысить, а может и не улучшить показатель успешности законных запросов (хотя ответы могут обслуживаться из кэша для всех клиентов).

       Более эффективный подход к сбросу нагрузки — отправлять все ответы с глобальной областью действия /0, чтобы Google Public DNS продолжал отправлять запросы ECS. Это позволяет Google Public DNS возвращать ответы с географической привязкой намного раньше после прекращения атаки, поскольку ему не нужно повторно обнаруживать поддержку ECS, просто повторно запрашивать после истечения TTL ответа глобальной области.

   • Ответы направления (делегирования) также должны содержать соответствующие данные ECS, и СЛЕДУЕТ ⁴ использовать глобальную область действия /0. Обратите внимание, что ответы делегирования никогда не пересылаются клиентам, адреса которых указаны в данных ECS, поэтому любые географически расположенные записи NS, A или AAAA должны выбираться по IP-адресу клиента преобразователя , а не по данным ECS.

4. Полномочные серверы имен, реализующие ECS, должны включать соответствующий параметр ECS в ответы на все типы запросов, полученные с параметром ECS. Недостаточно отвечать на запросы адреса IPv4 (A) данными ECS; ответы на запрос A, AAAA, PTR, MX или запрос любого другого типа должны иметь совпадающие данные ECS, иначе резолверы могут отбросить ответ как возможно поддельный, а Google Public DNS может перестать отправлять запросы с данными ECS.

   В частности, ответы ECS на запросы SOA, NS и DS всегда должны использовать глобальную область /0 для лучшего кэширования и согласованного представления делегирования (геолокационные ответы на запросы A/AAAA для имен хостов серверов имен допустимы). Ответы на запросы любого типа (например, TXT, PTR и т. д.), которые не изменяются на основе данных ECS, не должны использовать область действия, равную длине исходного префикса, они должны использовать глобальную область действия /0 для лучшего кэширования и уменьшения нагрузки запросов.

5. Авторитетным серверам имен, возвращающим ответы CNAME с поддержкой ECS, СЛЕДУЕТ ⁵ включать только первый CNAME в цепочке, а конечная цель цепочки CNAME должна быть с поддержкой ECS с той же длиной префикса области. Из-за неоднозначности спецификации ECS некоторые рекурсивные преобразователи (в частности, Unbound ⁶ ) могут возвращать ответ с областью действия конечного домена, отличного от CNAME (/0, если он не поддерживает ECS).

6. Данные ECS могут содержать адреса IPv6 даже для серверов имен только для IPv4 (и наоборот, хотя серверы имен только для IPv6 встречаются редко).

   Важно: Отсутствие возврата действительной области IPv6 ECS — наиболее частая причина, по которой авторитетные серверы имен не получают данные ECS из Google Public DNS.

   • Серверы имен должны отвечать допустимыми данными параметра ECS (область /0 в порядке, но исходный адрес и длина префикса должны совпадать).

   • ECS для зоны можно включить отдельно для адресов IPv4 и IPv6.

7. Авторитетные серверы имен, возвращающие ответы с поддержкой ECS, НЕ ДОЛЖНЫ ⁷ перекрывать префиксы областей в своих ответах. Примером перекрывающихся префиксов области действия может быть следующее:

   • Запрос с префиксом источника 198.18.0.0/15 : ответ A с префиксом области 198.0.0.0/8

   • Запрос с префиксом источника 198.51.100/24 ​​: ответ B с префиксом области 198.51.0.0/16

   Если клиент запрашивает рекурсивный распознаватель с поддержкой ECS в указанном выше порядке, оба запроса могут получить ответ A, поскольку область действия кэшированного ответа A включает область префикса второго запроса. Даже если клиентские запросы выполняются в обратном порядке и оба запроса перенаправляются на авторитетные серверы имен, кэшированные ответы могут истечь в разное время; последующие запросы к рекурсивному преобразователю с перекрывающимся префиксом 198.51.100/24 ​​могут получить либо ответ A, либо ответ B.

8. При реализации поддержки ECS в первый раз на серверах имен используйте новые IP-адреса для серверов имен, обслуживающих эти зоны с поддержкой ECS.

   • Когда авторитетные серверы имен, которые внедрили ECS, но вернули результаты глобальной области, начинают возвращать ответы с поддержкой ECS для зоны, Google Public DNS начинает возвращать географически привязанные ответы на запросы, как только истечет срок жизни предыдущих ответов глобальной области.

   • Автоматическое определение Google Public DNS поддержки ECS очень редко пытается запросить ECS для IP-адреса (или имени хоста сервера имен), когда он автоматически обнаруживает отсутствие поддержки ECS (тайм-ауты, возврат FORMERR, BADVERS или отправка ответов, отличных от ECS). Новые реализации ECS на этих IP-адресах (или именах хостов NS) автоматически обнаруживаются очень медленно или не обнаруживаются вообще.

9. Убедитесь, что сетевые соединения надежны и что любое ограничение скорости ответа установлено достаточно высоко, чтобы серверы имен не отбрасывали запросы (или, что еще хуже, отвечали ошибками при отсутствии соответствующей опции ECS).

   • Для серверов имен, реализующих ограничение скорости ответов на запросы ECS, лучшим ответом является NODATA с установленным флагом усечения (TC), содержащим только соответствующий раздел вопроса и соответствующий параметр ECS.

10. Отправляйте своевременные ответы на все запросы (в идеале в течение 1 секунды).

    • Использование онлайн-сервисов поиска Geo-IP для запросов ECS не будет работать надежно, поскольку совокупная задержка запроса DNS и онлайн-сервиса Geo-IP вряд ли будет в пределах одной секунды. Автоматическое определение поддержки ECS в общедоступных DNS Google считает задержку ответов признаком плохой или неполной поддержки ECS и снижает вероятность того, что будущие запросы будут отправляться с помощью ECS. Если задерживается достаточное количество ответов, он прекращает отправку запросов ECS.

Ссылки на RFC 7871 и другие сноски

¹ https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

² https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

³ https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

⁴ https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

⁵ https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

⁶ https://unbound.net/pipermail/unbound-users/2015-May/003875.html

Использование области действия конечного домена в цепочке CNAME безвредно в Unbound, поскольку обычно он развертывается как локальная заглушка или преобразователь переадресации, где все клиенты находятся в одной подсети и получат одинаковый ответ.

⁷ https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.