Diretrizes de sub-rede de cliente EEC (ECS, na sigla em inglês)

Introdução

A RFC 7871 (sub-rede do cliente em consultas DNS) define um mecanismo para resolvedores recursivos, como o DNS público do Google, que envia informações parciais de endereço IP do cliente para servidores de nomes de DNS autoritativos. As redes de fornecimento de conteúdo (CDNs) e os serviços sensíveis à latência usam isso para fornecer respostas geográficas precisas ao responder a pesquisas de nomes provenientes de resolvedores de DNS públicos.

A RFC descreve os recursos do ECS que os servidores de nomes autoritativos precisam implementar, mas os implementadores nem sempre seguem esses requisitos. Há também problemas de operação e implantação de ECS que o RFC não resolve que podem causar problemas para resolvedores, como o DNS público do Google, que detectam automaticamente o suporte a ECS em servidores de nomes autoritativos, bem como para resolvedores que exigem listas de permissões do ECS, como o OpenDNS.

O objetivo dessas diretrizes é ajudar desenvolvedores e operadores autoritativos de DNS a evitar muitos erros comuns que podem causar problemas para ECS.

Definições dos termos

Usamos os termos a seguir para descrever as operações ECS:

  • Um servidor de nomes implementa (ou é compatível) com ECS se responde a consultas ECS com respostas ECS que têm opções de ECS correspondentes, mesmo que as opções ECS tenham sempre um comprimento de prefixo de escopo /0 global.

  • Uma zona será ativada se o ECS fizer consultas nos servidores de nomes enviados com um prefixo de origem diferente de zero e receber respostas do ECS com um escopo diferente de zero.

Diretrizes para servidores de nomes autoritativos

  1. Todos os servidores de nomes autoritativos para uma zona ativada para ECS precisam ativar o ECS para a zona.

    • Mesmo que um único servidor de nomes não implemente o ECS nem o ative na zona, ele rapidamente se torna a origem da maioria dos dados armazenados em cache. Como as respostas têm escopo global, elas são usadas (até o TTL expirar) como a resposta a todas as consultas para o mesmo nome (independentemente da sub-rede do cliente). As respostas dos servidores que implementam o ECS e as ativam são usadas somente para consultas de clientes no escopo específico. Portanto, elas são muito menos propensas a serem usadas do que as respostas de escopo global.

  2. Servidores de nomes autoritativos que implementam o ECS PRECISA2 enviar respostas ECS às consultas ECS para todas as zonas exibidas de um endereço IP ou nome do host NS, mesmo para zonas que não estiverem ativadas por ECS.

    • O DNS público do Google detecta automaticamente o suporte a ECS por endereço IP em vez de nome do host do servidor de nomes ou zona DNS, porque o número de endereços é menor que o número de nomes de host do servidor de nomes e é muito menor que o número de zonas DNS. Se um servidor de nomes autoritativo não sempre enviar respostas ECS às consultas ECS (mesmo para zonas que não sejam ativadas para ECS), o DNS público do Google poderá parar de enviar consultas ECS a ele.

  3. Os servidores de nomes autoritativos que implementam o ECS precisam responder a todas as consultas do ECS com respostas do ECS, incluindo respostas negativas e de referência.

    • Os mesmos problemas com a detecção automática do suporte do ECS também se aplicam aqui.

    • As respostas negativas (NXDOMAIN e NODATA) Devem3 usar o escopo global /0 para melhorar o armazenamento em cache e a compatibilidade com o RFC 7871.

    • Além de NXDOMAIN e NODATA (NOERROR com seção de resposta vazia), outras respostas de erro para consultas ECS (especialmente SERVFAIL e REFUSED) precisam incluir uma opção ECS correspondente com escopo /0 global.

      • Se um servidor de nomes autoritativo estiver tentando desistir da carga de um ataque DoS, ele poderá retornar um SERVFAIL sem dados ECS. Fazer isso faz com que o DNS público do Google pare de enviar consultas com ECS, o que pode reduzir o número de consultas legítimas enviadas, mas não afetará consultas aleatórias de ataque de subdomínio. Reduzir a carga de consulta legítima durante um ataque de DoS pode ou não melhorar a taxa de sucesso das consultas legítimas, embora as respostas possam ser exibidas a partir do cache de todos os clientes.

        Uma abordagem mais eficaz para a perda de carga é enviar todas as respostas com escopo global /0 para que o DNS público do Google continue enviando consultas ECS. Isso permite que o DNS público do Google retorne respostas geolocalizadas muito mais depressa após a interrupção do ataque, já que não é necessário detectar novamente o suporte do ECS, apenas para consultar novamente quando os TTLs de resposta de escopo global expirarem.

    • As respostas de referência (delegação) também precisam ter dados de ECS correspondentes e Devem4 usar um escopo global /0. As respostas de delegação nunca são encaminhadas para os clientes cujos endereços aparecem nos dados ECS. Por isso, qualquer registro NS, A ou AAAA localizado geograficamente precisa ser selecionado pelo endereço IP do cliente resolver's, não pelos dados ECS.

  4. Os servidores de nomes autoritativos que implementam o ECS precisam incluir uma opção de ECS correspondente em respostas para todos os tipos de consulta recebidos com uma opção ECS. Ele não é bom o suficiente para responder a consultas de endereço IPv4 (A) com dados ECS. As respostas A, AAAA, PTR, MX ou qualquer outro tipo de consulta precisam ter dados do ECS ou resolvedores correspondentes que possam descartar a resposta como uma resposta possivelmente forjada, e o DNS público do Google pode parar de enviar consultas com dados ECS.

    Em particular, as respostas ECS para consultas SOA, NS e DS precisam sempre usar o escopo global /0 para melhorar o armazenamento em cache e uma visão consistente de delegação. Respostas geográficas a consultas A/AAAA para nomes de host do servidor de nomes são adequadas. As respostas a qualquer tipo de consulta (por exemplo, TXT, PTR etc.) que não mudam com base nos dados ECS não devem usar um escopo igual ao comprimento do prefixo de origem, eles devem usar um escopo global /0 para melhorar o armazenamento em cache e a carga de consulta reduzida.

  5. Os servidores de nomes autoritativos que retornam respostas CNAME ativadas para ECS SHOULD5 incluem apenas o primeiro CNAME na cadeia, e o destino final da cadeia CNAME deve ser ativado para ECS com o mesmo tamanho de prefixo de escopo. Devido à ambiguidade na especificação do ECS, alguns resolvedores recursivos (especialmente Unbound6) podem retornar uma resposta com o escopo do domínio final que não é CNAME (/0 se ele não estiver ativado para ECS).

  6. Os dados ECS podem conter endereços IPv6 mesmo para servidores de nomes somente IPv4 (e vice-versa, embora os servidores de nomes somente IPv6 sejam raros).

    • Os servidores de nomes precisam responder com dados de opções de ECS válidos. O escopo /0 é aceitável, mas o comprimento do prefixo e o endereço de origem precisa ser igual.

    • O ECS de uma zona pode ser ativado separadamente para endereços IPv4 e IPv6.

  7. Os servidores de nomes autoritativos que retornam respostas ativadas para ECS NÃO PODE7 sobrepor os prefixos do escopo nas respostas. Veja um exemplo de prefixos de escopo sobrepostos:

    • Consulta com o prefixo de origem 198.18.0.0/15: resposta A com prefixo de escopo 198.0.0.0/8

    • Consulta com o prefixo de origem 198.51.100/24: resposta B com prefixo de escopo 198.51.0.0/16

    Se um cliente consultar um resolvedor recursivo ativado pelo ECS na ordem acima, as duas consultas poderão receber a resposta A, porque o escopo da resposta em cache A inclui o escopo do prefixo da segunda consulta. Mesmo que as consultas do cliente sejam feitas na ordem oposta e as duas consultas sejam encaminhadas para servidores de nomes autoritativos, as respostas em cache podem expirar em momentos diferentes. As consultas subsequentes para o resolvedor recursivo no prefixo sobreposto 198.51.100/24 podem receber a resposta A ou B.

  8. Ao implementar o suporte do ECS pela primeira vez em servidores de nomes, use novos endereços IP para servidores de nomes que atendem a essas zonas ativadas do ECS.

    • Quando os servidores de nomes autoritativos que implementaram o ECS, mas retornaram resultados de escopo global, começaram a retornar respostas ativadas do ECS para uma zona, o DNS público do Google começou a retornar respostas geolocalizadas às consultas assim que os TTLs das respostas anteriores do escopo global expirarem.

    • A detecção automática de DNS público do suporte a ECS raramente tenta fazer consultas ECS para um endereço IP (ou nome do host do servidor de nomes) quando detecta automaticamente a falta de suporte ECS (tempo limite, retorno de FORMERR, BADVERS ou envio de respostas que não são de ECS). Novas implementações do ECS nesses endereços IP (ou nomes de host da NS) são detectadas automaticamente de maneira muito lenta ou não são detectadas.

  9. Verifique se as conexões de rede são confiáveis e se qualquer limitação de taxa de resposta está definida o suficiente para que os servidores de nomes não façam consultas (ou, pior, respondem com erros sem uma opção de ECS correspondente).

    • Para servidores de nomes que implementam a limitação de taxa de resposta em consultas ECS, a melhor resposta é NODATA com a sinalização de truncamento (TC) definida, contendo apenas uma seção de pergunta correspondente e uma opção ECS correspondente.

  10. Envie respostas em tempo hábil para todas as consultas (o ideal é em até um segundo).

    • O uso dos serviços de consulta on-line de Geo-IP para consultas de ECS não funcionará de forma confiável, já que a latência cumulativa da consulta de DNS e o serviço de Geo-IP on-line provavelmente não estará dentro de um segundo. A detecção automática de DNS público do suporte do ECS considera respostas atrasadas como uma indicação de suporte insuficiente ou incompleto do ECS e reduz a probabilidade de futuras consultas serem enviadas com o ECS. Se houver respostas suficientes, o envio de consultas ECS é interrompido.

Referências RFC 7871 e outras notas de rodapé

1 https://tools.helpcenter.org/html/rfc7871#page-12 (em inglês)

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.helpcenter.org/html/rfc7871#section-7.2.1 (em inglês)

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.helpcenter.org/html/rfc7871#section-7.4 (em inglês)

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.helpcenter.org/html/rfc7871#section-7.4 (em inglês)

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.helpcenter.org/html/rfc7871#page-12 (em inglês)

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 (em inglês)

Usar o escopo do domínio final em uma cadeia CNAME é inofensivo no Unbound, porque ele geralmente é implantado como um stub local ou resolvedor de encaminhamento, em que todos os clientes estão na mesma sub-rede e receberiam a mesma resposta.

7 https://tools.helpcenter.org/html/rfc7871#page-13 (em inglês)

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.