Registro Apex ANAME / ALIAS no Gerenciador de DNS do Windows Server 2012 R2

Question

Alguns hosts DNS oferecem uma maneira de ter um registro A que serve um endereço IP que é determinado imediatamente (ou com frequência suficiente por meio de um trabalho agendado), resolvendo algum outro nome de host nos bastidores. Isso é usado quando example.com (e não um subdomínio como www.example.com) DEVE apontar para um host cujo endereço IP muda de tempos em tempos, sem exigir intervenção humana toda vez que ele muda. O resultado é que a resolução example.com produz um registro A, em que o endereço IP de um registro é determinado dinamicamente pelo servidor de nomes, procurando o endereço IP de outro.exemplo.com, que pode ser um CNAME.

DNS Made Easy e easyDNS chamam de "registro ANAME", o Route 53 chama de "registro de recurso de alias", CloudFlare chama de "CNAME Flattening", DNSimple chama de "registro ALIAS". Independentemente do que eles chamam, um registro padrão A é retornado ao resolver o nome do host.

Eu não encontrei uma publicação sobre como alguém poderia implementar isso, embora seja um conceito bastante óbvio. Eu pretendo replicar esse comportamento no meu nameserver, que é o Gerenciador de DNS no Windows Server 2012 R2. Existe um plugin para o DNS Manager para fazer isso?

EDIT: Para evitar o problema XY eu vou fornecer fundo completo, começando com O problema em termos de sintomas, e percorrendo as dependências, uma vez que são uma indicação de quais soluções foram e não foram tentadas.

Sintomas

As conexões SSL / TLS com o domínio apex (example.com) geram uma incompatibilidade de certificado. Essas conexões não são tentadas com muita frequência, mas cada vez mais, devido a coisas como a detecção automática de hosts por clientes de email. Por exemplo, colocamos o Exchange como servidor de e-mail voltado para o cliente e, ao adicionar [email protected] como uma conta do Exchange no Android ou Mac Mail, a descoberta do host automático aparentemente deriva nomes de host "típicos", como example.com, mail.example.com, exchange.example.com, etc., e dá ao usuário um aviso assustador que o CN no certificado em example.com não é example.com. Na verdade, usamos exchange.example.com que tem um certificado correspondente, mas a detecção automática deve estar experimentando example.com primeiro.

O aviso de incompatibilidade também ocorre quando um navegador da Web é apontado para o link , mas isso é atenuado pelo fato de que a maioria das pessoas digita example.com em sua barra de endereço, não prefixada com https: //, então eles acabam sendo atualizados para o link com um redirecionamento quando necessário. Como www.example.com tem um CNAME, é possível apontar para um host no qual não há incompatibilidade de CN.

Por que há apenas um certificado correspondente em www.example.com e não em example.com?

O servidor com nosso certificado correspondente (que, por sinal, pode facilmente ter entradas de SAN para corresponder a example.com e * .example.com, sem problemas) está localizado em um ELB (balanceador de carga elástico) da AWS para qual Amazon adverte que o endereço IP pode mudar a qualquer momento. Devido ao endereço IP dinâmico, o ELB só deve ser referido através do seu nome de host, o que significa CNAME / ANAME / Flattening / etc. É por isso que podemos apontar www.example.com para o ELB, mas não para example.com. A Amazon sugere o uso do Route 53 para superar quaisquer limitações. Quando isso não for possível, a única solução é ter o ponto de registro A do example.com não no ELB, mas sim no servidor upstream para o qual normalmente os proxies reversos do ELB.

Por que não colocar o certificado correspondente nesse servidor upstream?

Apenas o próprio ELB é dedicado a mim, portanto, somente o ELB pode ter meu certificado curinga instalado. O servidor upstream é compartilhado entre a clientela do provedor de hospedagem. Eu poderia ter a empresa de hospedagem adicionar example.com à sua lista de lavanderia de SANs em seu certificado e não haveria uma incompatibilidade, mas em vez disso estou interessado em fazer pleno uso do ELB por várias razões.

Restrição

Estamos determinados a executar o DNS internamente no Win2012R2, enquanto todos os hosts da WWW devem estar na AWS para resiliência.

    

Answer 1

Dadas as circunstâncias exatas do problema, eu diria que a solução ideal seria apontar o ápice em um servidor da Web que redireciona as solicitações HTTP de example.com para www.example.com . www.example.com pode, por sua vez, ser um CNAME para o registro DNS gerenciado pela AWS.

• Embora seja possível configurar uma solução em seus servidores que atualiza automaticamente o registro A do apex para "perseguir" a AWS, isso apresenta uma grande complexidade desnecessária e cria dependências adicionais em seu infra-estrutura interna para que as coisas funcionem como esperado. Eu tentaria o meu melhor para evitar isso.
• A execução deste servidor da Web obviamente introduziria seu próprio conjunto de desafios e dependências, portanto, seria natural desviar sua atenção. Um exemplo de um serviço comercial que resolve seu problema (https inclusive) seria wwwizer.com . Note que eu não estou ligando ao seu produto livre e não-SSL.
• Um compromisso entre simplicidade e disponibilidade seria configurar um servidor da Web simples na nuvem que você executa que realiza esse redirecionamento. Você ainda está preso à execução do servidor da Web, mas pelo menos não há dependências na infraestrutura local da sua empresa e você tem um SLA para sua disponibilidade.

No final do dia, você tem que se perguntar como é importante que seu registro do ápice esteja sempre funcionando corretamente. Na sua situação, deve ser apenas uma proteção para os usuários que digitarem esse registro manualmente. Certifique-se de que seus servidores e aplicativos estejam configurados com isso em mente e o risco deve ser bastante atenuado. Também deve ser observado em seus documentos de design (se aplicável) para garantir que as coisas permaneçam assim.

    

Answer 2

A resposta de Andrew é absolutamente correta; um pequeno servidor para o único propósito de empurrar as pessoas para a WWW resolve bem o problema do navegador da Web.

Para a descoberta automática de email, você investigou SRV registros? Como você está executando o Windows, dou um salto e acho que você está executando o Exchange. Em caso afirmativo, o Outlook será autoconfigurado com base no SRV e, portanto, desistirá do cenário de incompatibilidade de CN do certificado.

Passando para opções ortogonais, usar uma nuvem melhor permitiria que você perdesse completamente essa bobagem (porque eles sabem como lidar com IPs fixos anycast), enquanto usar um CDN de nível superior vem com essa habilidade embutida. Eu trabalho para um provedor de nuvem que oferece serviços de alta disponibilidade.]