Cliente DNS para pesquisar registros CNAME automaticamente

Question

Acabamos de migrar para um novo resolvedor DNS interno e descobrimos uma limitação que afeta nossa capacidade de pesquisar registros específicos.

Nosso domínio oficial interno (privado) é example.net.. Temos um registro CNAME service.example.net.que resolvename-1234567890.region.elb.amazonaws.com.

name-1234567890.region.elb.amazonaws.com.resolve para vários registros A, cujos valores são gerenciados pela AWS. Não gerenciamos a zona pública amazonaws.com, nem os registros dentro desta zona.

Nosso resolvedor DNS anterior "perseguiria" registros CNAME, portanto, uma pesquisa de service.example.net.poderia retornar isto:

$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net.    300 IN  CNAME   name-1234567890.region.elb.amazonaws.com.
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.3
name-1234567890.region.elb.amazonaws.com. 26 IN A 10.1.2.4

A resposta inclui os IPs dos registros A para os quais o CNAME aponta. Tudo certo.

Nosso novo resolvedor de DNS não “persegue” registros CNAME. A mesma pesquisa com o novo resolvedor é semelhante a esta:

$ dig service.example.net
...
;; ANSWER SECTION:
service.example.net.    300 IN  CNAME   name-1234567890.region.elb.amazonaws.com.

... observe os registros A ausentes. As tentativas de contato service.example.netvia solicitações de ping, curl, python, etc. resultam em falhas de "Host desconhecido".

Não podemos alterar o comportamento do nosso novo resolvedor de DNS. Existe alguma opção no kernel do Linux ou em algum resolvedor de DNS local para "perseguir" registros CNAME do cliente, da mesma forma que nosso antigo resolvedor de DNS fazia no lado do servidor?

Para contextualizar, nosso novo resolvedor de DNS é o cloud-dns do GCP, quedocumentosesse comportamento.

Algumas respostas adicionais de contexto/comentário:

• exemplo.net. é uma zona privada gerenciada internamente no cloud-dns de nossa propriedade.
• amazonaws. com. é uma zona pública, gerenciada pela AWS.
• iirc, uma política de servidor de saída com servidores de nomes adicionais enviarátodosconsultas a esses servidores de nomes, substituindo cloud-dns
• iirc, os registros ALIAS estão disponíveis apenas em zonas públicas, não em zonas privadas.
• serviço.exmaple.net. é um registro CNAME na zona privada e gerenciada de DNS em nuvem example.net.
• não temos presença na AWS, portanto não podemos usar o route53.

Answer 1

Em vez de apontar diretamente para os ips internos do balanceador de carga, você precisa apontar para o nome DNS público do balanceador de carga

name-1234567890.region.elb.amazonaws.com

Portanto, remova os registros a e altere o valor cname para o nome DNS público do balanceador de carga

Answer 2

Eu queria fornecer uma atualização sobre esta questão. Desde que descobriu esse problema, o GCP começou a lançar um recurso experimental para cloud-dns que busca registros CNAME públicos. No momento em que este artigo foi escrito (abril de 2024), esse recurso precisava ser solicitado explicitamente ao suporte do GCP. Não tenho certeza de quando será GA.

Antes de esse recurso ser disponibilizado para nós, contornamos o problema criando uma zona de encaminhamento privada, por exemplo: amazonaws.comem nosso cloud-dns, que encaminha para resolvedores DNS públicos (usamos 8.8.8.8, 1.1.1.1, etc). Isso funciona, pois a perseguição de CNAME está habilitada no cloud-dns entre zonas privadas. Como amazonaws.comagora é considerada uma zona privada pelo cloud-dns, as solicitações de perseguição CNAME agora são resolvidas normalmente.

Answer 3

Para resolver registros aws, eu recomendaria examinar o route53 do aws. você pode deixar seu servidor DNS interno encaminhar para o route53, por exemplo, unbound é um revólver dns que pode fazer isso

Amazon Route 53 é um serviço web de sistema de nomes de domínio (DNS) escalável e altamente disponível fornecido pela Amazon Web Services (AWS). Ele traduz com eficácia nomes de domínio fáceis de usar, como example.com, em endereços IP que os computadores usam para se identificarem na Internet. Aqui está uma visão geral de alguns recursos e conceitos principais do Route 53:

• Registro de domínio: o Route 53 permite registrar e gerenciar nomes de domínio. Você pode comprar novos domínios ou transferir os existentes para o Route 53.
• Serviço DNS: O Route 53 atua como um provedor de serviços DNS, permitindo que você gerencie os registros DNS do seu domínio. Os registros DNS incluem itens como registros A (que mapeiam nomes de domínio para endereços IP), registros CNAME (que mapeiam nomes de domínio para outros nomes de domínio), registros MX (que especificam servidores de e-mail) e muito mais. Verificações de integridade e failover: o Route 53 pode execute verificações de integridade em seus endpoints, como servidores web, e direcione automaticamente o tráfego de endpoints não íntegros para endpoints íntegros. Esse recurso é frequentemente usado para implementar soluções de failover e recuperação de desastres.
• Gerenciamento de tráfego: o Route 53 oferece recursos de gerenciamento de tráfego, permitindo controlar como as consultas DNS são roteadas com base em vários fatores, como latência, geolocalização, roteamento ponderado e muito mais. Isso permite otimizar o desempenho e a disponibilidade de seus aplicativos.Integração com serviços da AWS: o Route 53 integra-se perfeitamente com outros serviços da AWS, como Amazon S3, Elastic Load Balancing (ELB) e Amazon CloudFront. Por exemplo, você pode usar o Route 53 para rotear o tráfego para seus balanceadores de carga ELB ou distribuições do CloudFront.
• DNSSEC: o Route 53 suporta extensões de segurança DNS (DNSSEC), que adicionam uma camada extra de segurança à sua infraestrutura DNS assinando digitalmente registros DNS. No geral, o Route 53 é um serviço DNS versátil e confiável que fornece a base para rotear o tráfego para seus aplicativos e serviços na internet. Oferece recursos avançados para gerenciar DNS, melhorar o desempenho e garantir alta disponibilidade.