O DNS público do Google ativou silenciosamente o suporte ao DNS por TLS

De repente, sem um anúncio preliminar, o DNS sobre TLS começou a trabalhar no 8.8.8.8 . Anteriormente, o Google anunciava suporte apenas para DNS sobre HTTPS.

O resolvedor público do CloudFlare com endereço IP 1.1.1.1 suporta DNS sobre TLS desde o início do projeto.

Por que isso é necessário?

Usando o esquema DNS clássico, os provedores podem rastrear suas patas sujas em seus pacotes DNS, procurar em quais domínios você solicita e trocar respostas conforme desejar. Os golpistas fazem o mesmo, substituindo os resolvedores nos roteadores invadidos, a fim de direcionar o usuário para um servidor falso.

Com o DNS sobre TLS / HTTPS, as solicitações são enviadas dentro de um túnel criptografado para que o provedor não possa substituir ou exibir a solicitação.

E com o advento da criptografia de nome de domínio nos certificados X.509 ( ESNI ), será impossível bloquear via DPI via SNI (Server Name Indication), um campo especial em que o nome de domínio é transmitido no primeiro pacote TLS), que agora é usado por alguns grandes provedores.

Como isso funciona

Uma conexão TLS é feita com o TCP: 853 e o certificado do resolvedor é verificado usando certificados raiz do sistema, assim como HTTPS em um navegador. Isso elimina a necessidade de adicionar qualquer chave manualmente. Dentro do túnel, uma consulta DNS regular é realizada. Isso cria menos sobrecarga do que o DNS sobre HTTPS, que adiciona cabeçalhos HTTP à solicitação e resposta.

Infelizmente, atualmente apenas no Android 9 (Pie), o suporte ao DNS sobre TLS está incorporado no resolvedor do sistema. Instruções de configuração para o Android 9 .

Para outros sistemas, propõe-se usar um daemon de terceiros e enviar o resolvedor do sistema para o host local (127.0.0.1).

Configuração no macOS

Vamos analisar o DNS sobre TLS na versão mais recente do macOS, usando o resolvedor de nó como exemplo

Instalação

brew install knot-resolver 

Por padrão, o nó funcionará como um resolvedor recursivo regular, como o dnsmasq.

Editando a configuração

 nano /usr/local/etc/kresd/config 

E adicione ao final do arquivo:

 policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} }))) 

Como resultado, minha configuração fica assim:

Lançamento do Daemon

 sudo brew services start knot-resolver 

Você pode verificar se o daemon foi iniciado com êxito usando o comando:

 sudo lsof -i -P -n | grep kresd 

O processo kresd deve escutar na porta 53 no host local.

Se algo der errado, veja o log de erros:

 cat /usr/local/var/log/kresd.log 

Verificando a operação do resolvedor

 dig @127.0.0.1 habr.com 

Verifique se o resolvedor local responde corretamente.

Instalação como um resolvedor do sistema

Se tudo funcionar corretamente, você poderá atribuir um resolvedor do sistema nas propriedades do adaptador de rede:



UPD

Qual é a diferença entre DNSCrypt, DNSSEC, DNS sobre TLS / HTTPS.

DNSCrypt pode funcionar em UDP e TCP. Conexão à porta 443. Para criptografia, é usado seu próprio protocolo, que difere do HTTPS. Pode ser facilmente destacado usando DPI. É um rascunho, que foi testado antes da introdução do DNS sobre TLS / HTTPS, já que não possui RFC, ou seja, não é um padrão oficial da Internet. Muito provavelmente, em breve, será completamente substituído por este último.

DNS sobre TLS (DoT) - a conexão TCP ocorre na porta 853, uma solicitação DNS regular é transmitida dentro do túnel. O provedor vê que essa é uma consulta DNS, mas não pode interferir nela. Em outras situações, no DNS sobre TLS deve haver um pouco menos sobrecarga para cada solicitação do que no HTTPS.

DNS sobre HTTP (DoH) - conexão TCP à porta 443, semelhante ao HTTPS normal. Dentro há um formato de solicitação diferente, com cabeçalhos HTTP. No entanto, para o provedor, essa solicitação será vista como uma conexão HTTPS normal. Suponho que esse protocolo tenha sido inventado caso as consultas DNS a servidores estrangeiros sejam bloqueadas para ocultar o tráfego normal da Web. E também, para que os navegadores possam resolver os próprios domínios e não criar tráfego anormal.

De fato, o DNS sobre HTTPS e sobre TLS é a mesma coisa, com um formato de solicitação ligeiramente diferente. Ambos os protocolos são aceitos como padrões e possuem uma RFC. Muito provavelmente, em um futuro próximo, veremos a distribuição em massa de ambos.

DNSSEC é um protocolo para assinar digitalmente registros DNS. Não está relacionado à criptografia, pois todas as solicitações são transmitidas em texto não criptografado. Ele pode funcionar tanto no antigo protocolo DNS clássico, ou seja, UDP / TCP na porta 53, quanto dentro do DNS através de TLS / HTTPS. O objetivo do DNSSEC é autenticar um registro DNS. Um proprietário de domínio pode adicionar uma chave pública aos servidores raiz da zona de domínio e assinar todas as entradas no assistente do servidor NS. De fato, a cada registro DNS, por exemplo, registro A ou registro MX, é adicionado outro registro do tipo RRSIG que contém a assinatura. O procedimento de validação DNSSEC em um resolvedor recursivo permite estabelecer se esse registro foi realmente criado pelo proprietário do domínio.

Uma comparação mais detalhada de todos os protocolos dnscrypt.info/faq (parágrafo Outros protocolos)