Não há suporte para IPv6 e DNSSEC no cc-TLD? (Implicações práticas)

Question

Estou precisando registrar alguns domínios que têm extensões de domínio com código de país, mas notei que esses TLDs não suportam oficialmente (A) IPv6 ou (B) DNSSEC ... Quais limitações ou armadilhas devo esperar encontrar porque disso?

(A) Não há suporte IPv6 para o TLD

Sei que isso significa que não poderei adicionar um registro AAAA ao domínio, mas o que isso significa para a acessibilidade / compatibilidade / visibilidade de outros servidores DNS compatíveis com IPv6?

(B) Não há suporte para DNSSEC para TLD

Eu entendo que o DNSSEC é de alguma forma importante para autenticar a resolução de DNS, mas não tenho idéia se / como sua implementação (ou falta dela) me afeta como desenvolvedor de aplicativos quando se trata de segurança.

OBSERVAÇÃO: Por favor, perdoe essa questão potencialmente rudimentar de um especialista móvel LAMP, MEAN, front-end e nativo que raramente teve que tomar decisões de arquitetura de rede em torno o de cima. Obrigado antecipadamente!

    

Answer 1

Se o ccTLD não tiver endereços IPv6 para seus servidores de nomes, talvez um usuário somente IPv6 não consiga resolver qualquer nome sob esse TLD, mesmo que esses nomes estejam em zonas compatíveis com IPv6 . Resolver segue uma cadeia abaixo da raiz, e se um link não funcionar, a coisa toda falha.

O DNSSEC fornece autenticação criptográfica de dados DNS. Como tudo no DNS, segue a árvore normal a partir da zona de raiz. E, novamente, se um link não funcionar, toda a cadeia falha. Portanto, qualquer nome sob um ccTLD que não seja DNSSEC estará vulnerável a spoofing (note: é uma técnica para acompanhar a cadeia neste caso, chamada DLV. É, no entanto, obsoleta e o apoio da ICANN para isso terminará em 2017).

Eu consideraria usar um TLD melhor: -)

    

Answer 2

Os registros AAAA podem ser entregues pelos resolvedores IPv4 e IPv6. Você pode adicionar endereços IPv6 ao seu domínio e eles serão entregues. As pessoas com resolvedores apenas do IPv6 (que, acredito, seriam relativamente raros) não conseguirão resolver seu domínio em nenhum caso.

A solução padrão para o DNSSEC é usar o DLV (DNSSEC Lookaside Validation). Isso tem sido usado há muito tempo e tem sido a única maneira de validar um número de TLDs por um longo tempo. Como os provedores de TLDs adicionam suporte a DNSSEC, o requisito DLV desaparece para esses TLDs.

A aceitação geral tanto do IPv6 quanto do DNSSEC tem sido muito lenta. Onde estou, ainda preciso de um túnel IPv4 para obter conectividade IPv6.

    

Answer 3

Se o TLD não suportar AAAA registros para os endereços dos servidores de nomes, isso não significa que você não pode ter AAAA registros para seus serviços subjacentes, isso significa que as pessoas não poderão usar o IPv6 para o próprio protocolo DNS para procurar seus endereços de serviço.

É uma configuração perfeitamente normal (consulte BCP 91, também conhecido como RFC 3901 ), para ter somente servidores de nomes somente IPv4 listados com o registro de domínio, com esses servidores de nomes publicando AAAA registros para entradas em seu domínio. Neste ponto, isso não quebrará nada - uma conexão somente IPv6 (sem NAT64) é praticamente inutilizável.

Para o DNSSEC, a maioria dos ccTLDs já o apóia e aqueles que não têm muitos planos para fazê-lo ou já estão em fase de implementação, embora a África seja a principal área de preocupação. O mais recente mapa da ISOC de alguns dias atrás mostra isso:

    

Answer 4

Um guia modestamente pragmático (mas reconhecidamente menos preciso ou permanente):

Se você se encontrar no apuro acima e por qualquer motivo TENHA que continuar com os TLDs em questão ...

(A) Não há suporte IPv6 para o TLD

A partir deste post (Jan / 2016), o IPv4 está longe de ser obsoleto, portanto, qualquer impacto prático na descoberta geral deve ser mínimo. Mas por causa da imprecisão dessa suposição, e ainda pode haver momentos em que o uso de um TLD específico seja inevitável para qualquer motivo de compra / transferência de marca ou de TLD em massa, etc., ...

1. Visite o banco de dados da zona raiz da IANA (um departamento da ICANN) no link e encontre os detalhes oficiais de contato técnico e administrativo para a organização patrocinadora correspondente do TLD e entre em contato para descobrir se / quando o IPv6 será suportado.

(B) Não há suporte para DNSSEC para TLD

Como os resolvedores com reconhecimento de DNSSEC verificam as assinaturas digitais antes que uma solicitação possa ser atendida em um esforço adicional (não muito diferente do SSL) para evitar ataques MITM, ignorar isso não é sábio. Se o seu TLD não suporta atualmente ...

1. Uma solução temporária é uma implementação de DNSSEC Lookaside Validation (DLV), que, nesse caso, teria que residir em um servidor de resolução ou de armazenamento em cache, não em um servidor de nomes autoritativo. Mas se você está simplesmente hospedando um site ou um aplicativo, você provavelmente não será o único a fazer isso no servidor de nomes de resolução em questão para começar, e como @ Calle-Dybedahl sugere, esta opção está chegando ao fim em ~ 2017 (Veja o plano oficial de suspensão aqui: link )

Então, semelhante a (A) acima ...

2. Visite o banco de dados da zona raiz da IANA (um departamento da ICANN) no link e encontre os detalhes oficiais de contato técnico e administrativo para a organização patrocinadora correspondente do TLD e entre em contato para descobrir se / quando o DNSSEC será apoiado.

Answer 5

I know this means that I won't be able to add an AAAA record to the domain,

Isso está errado. A incompetência do registro de domínio não tem relação com os tipos de registro que você pode usar (a menos que eles o obriguem a usar seus servidores como os namesevers oficiais, em cujo caso eu sugeriria correr longe).

but what does this mean for reachability/compatibility/visibility from other IPv6-capable DNS servers?

Se a zona para o tld não estiver disponível por ipv6, então os resolvedores apenas do ipv6 não poderão resolver o domínio.

Se a zona para o tld estiver disponível em ipv6, mas eles não permitirem que você forneça registros de cola IPv6, as coisas ficarão mais complexas. Se o seu servidor de nomes estiver sob o domínio em questão, será necessário um registro de cola IPv6 para suportar somente resolvedores IPv6. Se o seu servidor de nomes estiver em outro domínio, os registros de cola não serão necessários para o seu domínio (embora, obviamente, eles sejam necessários para algum domínio).

Os resolvedores de pilha dupla devem estar bem em qualquer caso. As chances são de que a maior parte dos resolvedores de DNS será compatível com IPv4 (apenas dual stack ou v4) para o futuro previsível.

I understand that DNSSEC is somehow important for authenticating DNS resolving, but have no idea if/how its implementation (or lack thereof) affects me as an application developer when it comes to security.

O Dnssec deve fornecer um mecanismo para verificar se os registros recebidos são genunine. No entanto

1. A grande maioria dos sistemas não o aplica neste momento.
2. verificar se os registros são legítimos não ajuda muito em registros A e AAAA. Um invasor que pode mexer com o DNS também pode mexer com o roteamento IP.

O DNSSEC com DANE é uma possível substituição ou suplemento futuro do atual sistema de CA. O atual sistema de CA é altamente falho do ponto de vista de segurança, porque efetivamente deixa você tão seguro quanto a pior CA.

Você não diz que tipo de aplicativos está desenvolvendo. Se é um aplicativo cliente que fala com um servidor que você possui, você deve proteger suas conexões usando tls com uma CA privada.

Para webapps, o sistema público de CA (porcaria como é) é realmente a única opção. Você pode querer considerar o HKP, que tenta reduzir o risco de certificados incorretos. Ter o DNSSEC / DANE funcionando forneceria melhor segurança, mas apenas para os poucos clientes que realmente o suportam.

Se você está projetando seu próprio protocolo, que permite o uso de servidores arbitrários, você pode considerar incluir um equivalente ao hkp.