Lineamientos de la subred del cliente de EDNS (ECS)

Introducción

RFC 7871: La subred de cliente en consultas de DNS define un mecanismo para agentes de resolución recurrentes, como el DNS público de Google, a fin de enviar información parcial de direcciones IP de clientes a servidores de nombres de DNS autorizados. Las redes de entrega de contenido (CDN) y los servicios sensibles a la latencia lo usan para proporcionar respuestas ubicadas geográficamente precisas cuando responden a búsquedas de nombres que provienen de agentes de resolución de DNS públicos.

El RFC describe las funciones de ECS que los servidores de nombres autorizados deben implementar, pero los implementadores no siempre cumplen con esos requisitos. También hay problemas operativos e de implementación de ECS que el RFC no soluciona, lo que puede causar problemas para agentes de resolución como el DNS público de Google que detectan de forma automática la compatibilidad de ECS en servidores de nombres autorizados, así como agentes de resolución que requieren una lista blanca de ECS, como OpenDNS.

El objetivo de estos lineamientos es ayudar a los implementadores y operadores de DNS autorizados a evitar muchos errores comunes que pueden causar problemas para el ECS.

Definiciones de términos

Usamos los siguientes términos para describir las operaciones de ECS:

  • Un servidor de nombres implementa (o admite) ECS si responde a consultas de ECS con respuestas de ECS que tienen opciones de ECS coincidentes (incluso si las opciones de ECS siempre tienen una longitud de prefijo de alcance /0 global).

  • Una zona es ECS habilitada si las consultas de ECS en sus servidores de nombres enviados con un prefijo de origen distinto de cero reciben respuestas de ECS con un alcance distinto de cero.

Lineamientos para servidores de nombres autorizados

  1. Todos los servidores de nombres autorizados para una zona con ECS habilitado deben habilitar ECS para la zona.

    • Incluso si solo un servidor de nombres no implementa ECS ni lo habilita para la zona, se convierte rápidamente en la fuente de la mayoría de los datos almacenados en caché. Debido a que sus respuestas tienen un alcance global, se usan (hasta que vence su TTL) como respuesta a todas las consultas para el mismo nombre (sin importar la subred del cliente). Las respuestas de los servidores que sí implementan ECS y lo habilitan solo se usan para las consultas de clientes dentro del alcance específico, por lo que es mucho menos probable que se usen que las respuestas de alcance global.

  2. Los servidores de nombres autorizados que implementan ECS DEBEN2 envían respuestas de ECS a consultas de ECS para todas las zonas entregadas desde una dirección IP o un nombre de host de NS, incluso para zonas que no están habilitadas.

    • El DNS público de Google detecta automáticamente la compatibilidad con ECS por dirección IP en lugar de nombre de host del servidor de nombres o zona DNS, porque la cantidad de direcciones es menor que la cantidad de nombres de host del servidor de nombres y mucho menor que la cantidad de zonas de DNS. Si un servidor de nombres autorizado no siempre envía respuestas ECS a consultas ECS (incluso para zonas que no están habilitadas para ECS), el DNS público de Google puede dejar de enviarle consultas ECS.

  3. Los servidores de nombres autorizados que implementan ECS deben responder a todas las consultas de ECS con respuestas de ECS, incluidas las respuestas negativas y de referencia.

    • Aquí también se aplican los mismos problemas relacionados con la detección automática de compatibilidad con ECS.

    • Las respuestas negativas (NXDOMAIN y NODATA) DEBEN3 usar el alcance global en /0 para mejorar el almacenamiento en caché y la compatibilidad con RFC 7871.

    • Además de NXDOMAIN y NODATA (NOERROR con la sección de respuesta vacía), otras respuestas de error a las consultas de ECS (en especial, SERVFAIL y REFUSED) deben incluir una opción de ECS que coincida con el alcance global /0.

      • Si un servidor de nombres autorizado intenta reducir la carga de un ataque DoS, puede mostrar un SERVFAIL sin datos de ECS. Si lo haces de forma repetida, el DNS público de Google dejará de enviar consultas con ECS (lo que puede reducir la cantidad de consultas legítimas que envían, pero no afectará las consultas de ataques aleatorios de subdominios). Reducir la carga de consultas legítimas durante un ataque de DoS puede o no mejorar la tasa de éxito de las consultas legítimas (aunque las respuestas se pueden entregar desde la caché para todos los clientes).

        Un enfoque de reducción de carga más eficaz es enviar todas las respuestas con alcance /0 global para que el DNS público de Google continúe enviando consultas de ECS. Esto permite que el DNS público de Google muestre respuestas ubicadas geográficamente mucho más tarde después de que se detenga el ataque, ya que no necesita volver a detectar la compatibilidad con ECS, solo para volver a realizar la consulta una vez que los TTL de respuesta del alcance global venzan.

    • Las respuestas de referencia (delegación) también deben tener datos de ECS que coincidan y DEBEN4 usar un alcance de /0 global. Ten en cuenta que las respuestas de delegación nunca se reenvían a los clientes cuyas direcciones aparecen en los datos de ECS, por lo que la dirección IP de cliente del agente de resolución debe seleccionar los registros NS, A o AAAA ubicados geográficamente, y no los datos de ECS.

  4. Los servidores de nombres autorizados que implementan ECS deben incluir una opción de ECS coincidente en las respuestas a todos los tipos de consultas recibidas con una opción de ECS. No es lo suficientemente bueno para responder a consultas de direcciones IPv4 (A) con datos de ECS; las respuestas a A, AAAA, PTR, MX o cualquier otro tipo de consulta deben tener datos de ECS o agentes de resolución que coincidan y pueden descartar la respuesta como una respuesta falsificada, y el DNS público de Google puede dejar de enviar consultas con datos de ECS.

    En particular, las respuestas de ECS para las consultas de SOA, NS y DS siempre deben usar el alcance global /0 a fin de mejorar el almacenamiento en caché y una vista coherente de la delegación (las respuestas ubicadas geográficamente a las consultas A/AAAA para nombres de host del servidor de nombres son correctas). Las respuestas a cualquier tipo de consulta (p. ej., TXT, PTR, etc.) que no cambian en función de los datos de ECS no deben usar un alcance equivalente a la longitud del prefijo de origen, sino un alcance global /0 para mejorar el almacenamiento en caché y la carga de consultas reducida.

  5. Los servidores de nombres autorizados que muestran respuestas CNAME habilitadas para ECS DEBEN5 solo incluyen el primer CNAME de la cadena, y el destino final de la cadena CNAME debe estar habilitado para ECS con la misma longitud de prefijo del alcance. Debido a la ambigüedad en la especificación de ECS, algunos agentes de resolución recurrentes (en particular, Unbound6) pueden mostrar una respuesta con el alcance del dominio final que no es CNAME (/0 si no está habilitado para ECS).

  6. Los datos de ECS pueden contener direcciones IPv6 incluso para servidores de nombres solo IPv4 (y viceversa), aunque son poco frecuentes.

    • Los servidores de nombres deben responder con datos de opción ECS válidos (el alcance /0 es correcto, pero la dirección de origen y la longitud de prefijo deben coincidir).

    • El ECS de una zona se puede habilitar por separado para las direcciones IPv4 y, también, IPv6.

  7. Los servidores de nombres autorizados que muestran respuestas habilitadas para ECS NO DEBEN7 superponer prefijos del alcance en sus respuestas. Un ejemplo de prefijos de alcance superpuestos sería el siguiente:

    • Consulta con el prefijo de origen 198.18.0.0/15: respuesta A con prefijo de alcance 198.0.0.0/8

    • Consulta con el prefijo de origen 198.51.100/24: respuesta B con el prefijo de alcance 198.51.0.0/16

    Si un cliente consulta un agente de resolución recurrente habilitado para ECS en el orden anterior, ambas consultas pueden obtener la respuesta A, porque el alcance de la respuesta A almacenada en caché incluye el alcance del prefijo de la segunda consulta. Incluso si las consultas de cliente se realizan en el orden opuesto, y ambas consultas se reenvían a servidores de nombres autorizados, las respuestas almacenadas en caché pueden vencer en momentos diferentes. Las consultas posteriores al agente de resolución recurrente en el prefijo superpuesto 198.51.100/24 podrían obtener la respuesta A o B.

  8. Cuando implementes la asistencia de ECS por primera vez en los servidores de nombres, usa direcciones IP nuevas para los servidores de nombres que entregan estas zonas habilitadas de ECS.

    • Cuando los servidores de nombres autorizados que implementaron ECS, pero mostraron resultados de alcance global, comienzan a mostrar respuestas habilitadas de ECS para una zona, el DNS público de Google comienza a mostrar respuestas con ubicación geográfica a consultas tan pronto como vencen los TTL de las respuestas de alcance global anteriores.

    • La detección automática de DNS público de Google de la compatibilidad con ECS casi nunca intenta realizar consultas de ECS para una dirección IP (o nombre de host del servidor de nombres) cuando no detecta de forma automática la compatibilidad con ECS (se agota el tiempo de espera, muestra FORMERR, BADVERS o envía respuestas que no son ECS). Las nuevas implementaciones de ECS en esas direcciones IP (o nombres de host de NS) se detectan de forma automática muy lenta, o no se detectan en absoluto.

  9. Asegúrate de que las conexiones de red sean confiables y que el límite de tasa de respuesta sea lo suficientemente alto como para que los servidores de nombres no descarten las consultas (o, peor aún, responda con errores que carezcan de una opción de ECS coincidente).

    • Para los servidores de nombres que implementan el límite de frecuencia de respuesta en consultas de ECS, la mejor respuesta es NODATA con el conjunto de marcas de truncamiento (TC) que contiene solo una sección de preguntas y una opción de ECS coincidentes.

  10. Envía respuestas oportunas a todas las consultas (idealmente en 1 segundo).

    • El uso de los servicios de búsqueda de IP geográficas en línea para las consultas de ECS no funcionará de manera confiable, ya que es poco probable que la latencia acumulativa de la consulta de DNS y el servicio de IP geográfica en línea esté dentro de un segundo. La detección automática de DNS público de Google de la compatibilidad con ECS considera que las respuestas retrasadas indican una compatibilidad con ECS deficiente o incompleta, y reduce la probabilidad de que se envíen consultas futuras con ECS. Si se retrasan suficientes respuestas, se dejan de enviar consultas de ECS.

Referencias de RFC 7871 y otras notas al pie

1 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.

2 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.

3 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.

4 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.

5 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.

6 https://unbound.net/pipermail/unbound-users/2015-may/003875.html

El uso del alcance del dominio final en una cadena CNAME es inofensivo en Unbound, ya que generalmente se implementa como stub local o agente de resolución de reenvío, en el que todos los clientes se encuentran en la misma subred y obtienen la misma respuesta.

7 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.