Arquivo

Posts Tagged ‘registro.br’

Tipos de DNS e suas aplicações

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.

Anúncios

DNSSEC II

O Registro.br, acaba de colocar no ar, uma ferramenta denominada DNSSHIM – DNS Secure Hidden Master, que promete facilitar nossa vida. Para quem possui uma topologia equivalente à mostrada aqui, certamente ficará agradecido. O melhor a fazer é testar a ferramenta e, esperar um pouco mais, pelo Free DNSSEC hosting anunciado na lista dnssec-deployment. Também, é de se esperar algumas mudanças para tornar o uso popular: “We don’t expect people to implement clients for it, we are providing a library and a shell like client for them.”, escreve o Frederico Neves e, na sequência ele ainda diz: “… So their provisioning system will talk EPP with the registry and the “simple” protocol with the DNS hosting back-end (DNSSHIM), instead of the hundreds of scripts magics they currently does…”. Essa última, a melhor velha notícia [3]. O Registro.br, nota-se pelas mensagens nas listas internacionais, faz inveja a outos NIRs do mundo. Eis as referências para o DNSSHIM, que inclui uma lista de debates:

[1] http://registro.br/dnsshim/.
[2] https://eng.registro.br/mailman/listinfo/dnsshim.
[3] libepp-nicbr: Biblioteca para cliente EPP do NIC.br.

Soluções simples para melhorar a Internet

Algumas coisas básicas, me incomodam como administrador de sistemas associados à Internet. E nada posso fazer, pois depende de atitudes de terceiros. A maior parte delas, depende dos RIRs ou do nosso NIR. Abaixo, algumas sugestões que, na medida do possível e por sugestões de colaboradores, serão incrementadas. Nenhuma delas agride o espírito da Internet.

  1. O reverso deve ser obrigatório. Quem não tiver o reverso deve ser punido.
  2. O Registro.br deve permitir a renúncia de blocos IPs, pelos ID Técnicos. Essa facilidade é pré-requisito para a proposta do item anterior. Atualmente, os responsáveis técnicos por blocos de IPs de terceiros, não conseguem se livrar deles, a partir do momento que não são mais responsáveis.
  3. O DNSSEC deve ser obrigatório para todos as DPNs. Quem não fizer isso, deverá ser punido. Quem não atualizar as chaves na época do vencimento, também será punido. O Registro.br deveria indicar nos avisos em que houver quebra de respostas no DNSSEC, QUAIS os servidores de DNS envolvidos, assim como ele fazia quando não havia respostas de servidores de DNS. Esse problema não é grave para quem possui, somente dois servidores de DNS, mas é complicado para quem possui o máximo permitido (5). Se a identificação do servidor específico de DNS não for possível, por alguma razão, então que informe aos administradores que eles devem cuidar dessa questão, monitorando cada um deles. O estado do domínio com DNSSEC implementado, também poderia aparecer por lá, o que nos ajudaria bastante.
  4. ASN deve ser liberado, livremente. Para quem provar que tem uma rede. As restrições somente para a liberação de blocos IPv4. Blocos IPv6 deveriam ser liberados para os ASs, mesmo sem IPv4. Isso anteciparia as implementações de IPv6. Muitos ASs com IPv6 estimulariam os fornecedores a implementar tal funcionalidade, já que o mercado estaria disponível. Por outro lado, o LACNIC deveria rever os preços relativos ao IPv6, que pretende cobrar no futuro.
  5. Instalação de uma base do IRR espelhada na RADB. De graça e com suporte a IPv6! E o Nic.br (ou LACNIC) pode criar, à semelhança do RIPE NCC, orientações de uso, inclusive das ferramentas disponíveis (IRRTools, p. ex.).
  6. Propostas para o tratamento das punições. Sempre haverá avisos, antecedendo a punição. As punições, após os avisos, não devem ser brandas. Os critérios de punição deveriam considerar a reincidência. Quem possui um ID Técnico, pressupõe-se que seja um administrador, conhecedor dos fundamentos da Internet. Os avisos e punições, podem se estender aos outros IDs.

DNS: Um exemplo de topologia

DNS, ninguém tem dúvida representa para a Internet, o mesmo que o ar para o ser humano. Embora esse fato seja reconhecido, as preocupações com os servidores de DNS são relegadas a um último plano. Eis alguns exemplos do que se vê por ai, inclusive em provedores de médio e grande porte:

  1. Usam dois servidores de DNS (o mínimo exigido), em uma mesma máquina.
  2. Usam dois servidores de DNS, na mesma rede.
  3. Não se preocupam com o TTL das zonas.
  4. Ignoram a importância do reverso, achando que o reverso reproduz uma transparência indesejável, o que é uma falácia.
  5. Não estão preocupados com o DNSSEC. Qualquer dia desses, o Registro.br irá dar um prazo para implementar o DNSSEC (espera-se).

Seria bom pensar a respeito dos itens acima. O Itinera, desde seu inicio segue a seguinte topologia em seus servidores de DNS:

Antes da primeira versão do Itinera, a topologia acima existia e mantida manualmente. Nas primeiras versões do Itinera, não se usava o conceito de base de dados. Agora, com o Itinera ad futurum as bases de dados são usadas para cada grupo de servidores. A topologia acima, com ou sem base de dados pode, sem muito trabalho, existir com manutenção manual, trazendo grandes vantagens, em particular sob o ponto de vista da segurança. Mesmo que se venha a usar o DNSSEC, o qual exigirá um esforço de manutenção mais sistemática nos servidores (há ferramentas disponíveis para tratar o DNSSEC manualmente.

Eis algumas características importantes, que permitem implementações de variações do modelo acima:

  • É usado o BIND nos autoritativos e Unbound nos recursivos. Para ambos, há uma preocupação, firme, em manter atualizado com a última versão.
  • Todos servidores autoritativos estão rodando em FreeBSD. Nem todos os recursivos estão sob FreeBSD.
  • Os servidores primários (P) são em número de dois, para permitir redundância. São atualizados via rsync.
  • Os servidores primários são escondidos, aos quais, somente os servidores do tipo master (M) possuem acesso. Além das restrições naturais do BIND, são impostas regras de “firewall” locais e nos “gateways”. Isso torna o conjunto seguro? Provavelmente, não. Mas torna-o menos vulnerável.
  • Todos os servidores estão em redes distintas e remotamente localizados, exceto os recursivos (R), distribuídos a critério dos donos das redes que usam o Itinera.
  • Os servidores M, embora redundantes, não estão disponíveis. Somente um cuida dos servidores autoritativos (A).
  • Não há base de dados local ativa, em nenhum servidor (PE, M, A ou R). Há replicação da base de dados, mantendo uma simples cópia atualizada diante de qualquer alteração.
  • Todo o tráfego na direção das bases de dados e suas cópias, usa openSSL.
  • A cada duas horas, se houve alteração em algum dos servidores um backup é automaticamente acionado, sobre o servidor que sofreu a alteração, exceto nos A e R.
  • Todos os servidores são monitorados, para efeito de verificação em suas atividades.
  • Não há estatísticas de tráfego e/ou utilização geral do servidor. Está na pauta para incluir. Periodicamente, é feito manualmente, usando as ferramentas do BIND e outras disponíveis.
  • Embora testado, não foi implementado o procedimento automático de gerenciamento do DNSSEC. Entretanto, toda a estrutura dos PEs foram alteradas para facilitar a implementação do DNSSEC. Em outro artigo, falarei sobre o DNSSEC, especificamente.
  • Todos os servidores estão com NTP. Três deles integrados aos servidores do Nic.br. O restante são clientes destes três e servem como clientes para máquinas das redes locais.
%d blogueiros gostam disto: