[GTER] DNS over HTTPS (DoH): fim dos recursivos locais e a Internet andando para trás?

[Douglas Fischer]

Um dos principais problemas decorrente dessas técnicas está na verdade na
inteligência de uso de conteúdos distribuídos na Internet.
A base da inteligência das CDNs está no DNS. Usar NameServers distantes
fatídicamente vai fazer os usuários buscarem conteúdos em Caches Distantes.

É inegável que exista uma vulnerabilidade sistêmica no mecanismo de DNS do
mundo.
Qualquer um pode interceptar e reescrever as respostas DNS.
 - A operadora Oi-BrT pratica/praticava essa interceptação há muito tempo.
 - Existem provedores MEQUETREFES que sobrem os IPs dos top responsivos
públicos(8.8.8.8/4.4.4.4/etc) nas loopbacks de seus NameServers recursivos

O mundo já está ciente disso há MUITOS ANOS, e a solução para isso foi
proposta também há muitos anos.
O problema é que a adesão ao DNSSEC ainda é muito baixa!


A forma mais efetiva de popularizar o DNSSEC seria deixar o usuário ficar
sabendo que ele não está tendo uma resposta segura.
 - Lembram da história "Se aparecer o cadeadinho fechado no cantinho do
Browser, você está seguro!".
Alguma coisa assim.

Mas para isso existem limitações:
O Browser recebe do Sistema operacional a resposta mastigada.
Não sabe se aquela resposta veio em DNSSEC ou não.
Me lembro de haver proposta de mudança nisso, mas que foi enfaticamente
rejeitada.


Uma ideia que na minha opinião é MUITO BOA é a de domínios específicos como
o "b.br" que só responderiam em DNSSEC.
Já imaginou a água batendo na bunda dos provedores que fazem Safadeza?
   "Estou tentando acessar o meu banco e quando eu uso o 4G funciona!"
O problema é que essa ideia do "b.br" não teve a adesão esperada...





Em 1 de abril de 2018 22:33, Tiago SR <listas at tiagosr.com> escreveu:

> Prezados,
>
> Parece que a obsessão por privacidade está levando a algumas bizarrices
> relacionadas a DNS.
>
> A Mozilla quer começar com isso testando DNS over HTTPS no Firefox Nightly
> de forma out-out, forçando o uso do servidor DoH recém lançado (juntamente
> ao 1.1.1.1) da CloudFlare. Provavelmente, após o teste vão dar a opção de
> configurar outros servidores DoH, mas não tem nada que automatize isso,
> como receber essa configuração pela rede, via DHCP ou PPPoE, por exemplo.
> Isso se deixarem em campo aberto, e não apenas listarem opções públicas que
> julgarem confiáveis. Como a maioria dos usuários não vai mexer nisso, vão
> usar o que vier. E os incentivos são de que toda aplicação adote isso.
>
> Com isso, depois de todo mundo montar recursivos locais, para reduzir
> problemas com servidores externos e diminuir tempo de resposta, vamos
> voltar a usar servidores hospedados na Internet, centralizados, e talvez
> até geridos por quem tem interesse em acessar os dados de navegação dos
> usuários, contrariando a justificativa da privacidade (Google também tem
> servidores DoH e deve forçar no Chrome, Android e tudo mais em breve, se já
> não o fez). E mais: provedores e operadoras de acesso não vão ter controle
> sobre um recurso de rede que impacta diretamente na qualidade da conexão de
> seus assinantes.
>
> Alguém mais não está gostando dessa direção que estão tomando?
>
> Por mim, a solução ideal seria DNS over TLS, - implementado pelas
> aplicações interessadas nessa segurança extra, sem precisar instalar daemon
> cliente, enquanto não é suportado nativamente pelo sistema operacional -
> com o uso de servidores definidos na configuração de rede (manualmente ou
> via DHCP ou PPPoE). Unbound e outros já suportam TLS.
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação