Atualizado em: 31/05/2011.
Artigo originalmente escrito em 28/05/2009.

Introdução

É um artigo redundante. Mas, com o objetivo de deixar alguns pontos ainda não bem compreendidos. Além de dar ênfase à necessidade de implementação do DNSSEC.

Sob o ponto de vista de uma empresa, instituição ou de um provedor, existem dois tipos de servidores de DNS:

• Autoritativo
• Recursivo

Resolvedor não é um servidor de DNS. É um cliente (p. ex.: o navegador), de um servidor recursivo. Os servidores autoritativos não atendem a consultas do resolvedor. O resolvedor, geralmente fica no sistema operacional ou nos programas tipo ftp, ssh e, muitos outros que provocam o sistema operacional pesquisar os resolvedores. Servidores root são sevidores que informam aos recursivos a quem recorrer para encontrar o autoritativo que responda pelo domínio, em consulta. São servidores muito especializados e pode ser desprezado neste debate.

Existem inúmeros bons programas que implementam servidores de DNS: bind, unbound, djdns, etc. São ótimos! Cada um com suas vantagens e desvantagens. Por exemplo, o djdns, pelo menos até pouco tempo não implementava o DNSSEC. O bind é um dos mais completos, pois é autoritativo, recursivo e implementa o DNSSEC. O unbound somente implementa servidor recursivo e trata, eficientemente, o DNSSEC.

Quem precisa de um servidor autoritativo?

Somente quem precisar difundir dominios na Internet. O autoritativo é o servidor que está autorizado a responder por um domínio. A autoridade para que um servidor de DNS (autoritativo) responda pelo domínio é dada pelos registros de domínios, oficiais, de uma determinada região do mundo. No nosso caso, Brasil, quem fornece a autoridade para que um ou mais servidores autoritativos respondam por um domínio é o Registro.br. Como já falamos, a autoridade do Registro.br é reconhecida pelos servidores root, pois o Registro.br é um NIR (National Internet Register) responsável pelo Brasil e autorizado pelo LACNIC, que é um dos cinco RIRs (Regional Internet Register), do mundo. O Registro.br exige, no mínimo, dois autoritativos para repassar a autoridade. O Registro.br não faz nenhuma exigência em relação aos recursivos, em outras palavras, nem dá bola para eles.

Por ser o autoritativo autorizado pelo Registro.br, a responder por um domínio, ele é um servidor que deve ficar disponível para qualquer consulta feita na Internet. Ou seja, ele é um servidor aberto, sob o ponto de vista de consultas aos domínios sob sua jurisdição. Aqui mora o perigo! Se o servidor autoritativo não estiver muito bem preparado e, não usar o DNSSEC, sua vulnerabilidade passa a ser enorme! Ele está suscetível à chamada poluição de DNS (comprometimento, envenenamento), segundo os comprovados argumentos de Dan Kaminsky, cujos artigos e experimentos podem ser vistos em [1]. A era pós-Kaminsky felizmente trouxe melhoras sinificativas nos sistemas que implementam o autoritativo, principal alvo de ataques.

Se você possui poucos dominios, não se meta a perder tempo em estabelecer um servidor autoritativo. Use o serviços de empresas especializadas, garantindo algumas premissas básicas: (a) possuir pelo menos 2 autoritativos em redes diferentes e, preferencialmente, possuir o(s) servidor(es) autoritativo(s) principais, escondido(s), (b) implemente o DNSSEC, (c) possua mecanismos de criptografia para o tráfego relativo às transferência de zonas e, (d) seja de fácil utilização. Achar a empresa que forneça os serviços com tais características é uma tarefa razoavelmente complicada. Depois de achar, tudo fica bem melhor. Todo cuidado é pouco, contudo. Recentemente ouvimos histórias de envenenamento de servidores da Telefônica, Embratel, etc.

Quem precisa de um servidor recursivo?

Todos aqueles que possuem usuários ou máquinas com acesso à Internet, na rede sob seu controle. Por exemplo, tenho o Speedy na minha casa. Com cerca de 5 equipamentos. Implementei um recursivo por lá? Não! Uso o openDNS. Se ele falhar, uso o DNS da Telefônica. Ou seja, não possuo atividades sensíveis.

E na minha empresa? Ah, nela sim! A estrutura de meu sistema de servidores DNS está definida à semelhança da topologia mostrada aqui, onde em cada rede colocamos um ou mais recursivos.

O servidor recursivo tem uma característica interessante, diferentemente do autoritativo. Ele consulta o autoritativo, mas não está liberado para toda a Internet. Isto é, não deveria! Somente está liberado para as demandas de sua rede. Entretanto, ele traz as informações de domínios vindas de todos os autoritativos do mundo. Se algum autoritativo está comprometido, ele passará tais informaçoes para frente. Nesse caso, somente o DNSSEC poderá aliviar a tensão do comprometimento, já que é impossível criptogafar o tráfego entre recursivos e autoritativos, pelo menos por enquanto.

Porque tráfego criptografado entre os servidores autoritativos?

Para dificultar a vida do “homem do meio”, técnica muito usada para capturar tráfego entre servidores na Internet. Ele irá conseguir, mas terá de descobrir e adicionar a mesma técnica de criptografia e decriptografia. O DNSSEC adiciona, por outro lado, uma dificuldade a mais, nas tentativas de comprometimento dos servidores. É importante lembrar, que o DNSSEC não criptografa o tráfego nas transferências de zonas entre os autoritativos. Existem técnicas no bind para fazer isso. O DNSSEC garante a integridade dos dados, nesse caso, importantíssimo durante as consultas de recursivos, cujo procedimento recebe o nome de “cadeia de confiança” ou “cadeia de autenticação”.

Uma pergunta final

Ah, se meus servidores de DNS são seguros? Uai, espero que sim … Servidores de DNS são, provavelmente, os mais importantes componentes da infraestrutura da Internet. Talvez não seja suficiente, diante da competência dos “bad boys”. É preciso monitorá-los e ficar atento às recomendações constantes e avaliações dos melhores especialistas repassadas em listas técnicas nacionais e internacionais. Além de usar, efetivamente, os recursos inerentes ao próprio servidor de DNS.

O DNSSEC nos tranquiliza porque confere ao DNS, três garantias fundamentais, repetindo algumas que já falamos: (a) a identidade da origem ou, a autenticidade do recursivo (consulta) ou autoritativo (transferência de zonas), que está buscando a informação, (b) a integridade dos dados, através de chaves públicas de criptografias associadas ao dominio e, (c) o reconhecimento da não existência de um nome ou tipo de registro de DNS. Três pontos tão importantes, que não se pode imaginar porque DNSSEC não está implementado em todos os domínios. Veja as referências do artigo DNSSEC I, nesse blogue.

Por fim, algumas empresas, com grande número de domínios para publicação, implementam um outro tipo de DNS, denominado forwarder (reencaminhador), como forma de evitar a exposição direta de seus recursivos. Elas recuam os servidores para trás do firewall e colocam o encaminhador em uma DMZ, por exemplo, acessível a todos os equipamentos que consultam por domínios. Trataremos desse tipo de servidor de DNS, em outra oportunidade.

Imperdível, no e-learning do RIPE NCC (o RIR europeu), [2], sobre como se relacionam os dois tipos de DNS tratados acima, os resolvedores clientes e os servidores root.

Autoritativos do Registro.br

O Registro.br disponibiliza servidores autoritativos gratuítos, com DNSSEC incluído. Vale a pena usá-los, como o objetivo de eliminar os servidores autoritativos locais e, assim reduzir, enormemente, o esforço de manutenção. Há uma restrição de no máximo 40 registros (ou apontamentos), por zona. Usando tais servidores pode-se manter somente os recursivos, localmente, e reduzindo o esforço de manutenção, drasticamente. Uma boa alternativa é usar o unbound, como recursivo. Naturalmente, a recomendação é de que o recursivo seja compatível com o IPv6, também. Uma outra restrição dos autoritativos do Registro.br é o fato de não suportarem zonas reversas.

Cenário futuro para o DNS

Os autoritativos do Registro.br possuem restrições. Imagina-se que há uma motivação para isso. O Registro.br não dá maiores informações à comunidade, sobre as razões das restrições. Paul Vixie, que mantem um blogue interessante em [4], escreveu um recente artigo, [3], no qual, comenta (subliminarmente), a iniciativa do ISC (que produz e distribui o bind) em cobrar para a instalação de secundários, [5]. O principal argumento, sempre é o de que o funcionamento adequado do DNS é demasiadamente importante para a Infraestrutura da Internet. O Registro.br, ao implementar sua disponibilidade restrita, de autoritativos, talvez se justifique sob o mesmo argumento. Mas, a limitação do Registro.br, em 40 RRs, poderia viabilizar o futuro, sob um modelo muito parecido com o do ISC, [5].

À luz de tais movimentos é preciso pensar, bastante, antes de decidir sobre o modelo de servidores de DNS a ser escolhido. Assim como a sociedade, classificada pelos filósofos contemporâneos, sob um modelo sociocultural pós-moderno^*, a Infraestrutura da Internet está, também, em forte transformação!

^* Os filósofos contemporâneos estão atentos aos debates orientados às mudanças de nossas atuais condições culturais, sociais e existenciais. Pós-modernidade não parece ser um conceito adequado. Então estão propondo modelos alternativos, tais como, hipermodernidade, de Gilles Lipsovetsky, ou modernidade líquida, de Zygmunt Bauman, entre outros. Há uma entrevista muito interessante de Zygmunt Bauman, na revista “filosofia”, Ano V, No. 58, página 6, onde há um destaque para: “A propensão a mudar de forma sob a influência de mínimas, fracas e ligeiras pressões é apenas o traço mais óbvio da atual condição sóciocultural“.

Referências

[1] Dan Kaminsky, Sobre envenamento do DNS e artigos correlatos.

[2] RIPE-NCC, DNS Basics.

[3] Paulo Vixie, Anycast, Unicast, or Both?, Disponível em: http://www.circleid.com/posts/20110531_anycast_unicast_or_both/. Acessado em 31/05/2011.

[4] Paulo Vixie, vixie’s blog, Disponível em: http://www.isc.org/blogs/vixie. Acessado em 31/05/2011.

[5] ISC, SNS@ISC: ISC’s Name Service. Disponível em: https://www.isc.org/solutions/sns. Acessado em 31/05/2011.