Arquivo

Posts Tagged ‘DNS’

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.

Bloqueando ou censurando domínios (Bind e Unbound)

Últimas atualizações:
02/06/2009 – 10:33

Introdução

Dia 18/05/2009, a Abranet, recebeu uma notificação judicial para bloquear uma série de domínios relacionados com pornografia infantil. Esse artigo dá uma dica sumária de como fazer isso, usando servidores de nomes. O uso dos servidores de nomes elimina a preocupação de estabelecer os bloqueios (ou censuras) em equipamentos de borda (roteadores, firewall, entre outros), como inicialmente pensei em fazer, quando perguntaram-me como. Cheguei a passar uma mensagem na lista da Abranet solicitando idéias aos participantes. Os equipamentos de borda não são muito hábeis para tratar domínios, como sabemos. Boa parte da relação de dominios apresentados à Abranet, estavam hospedados no Google. Mas, acabei eu mesmo respondendo meu próprio e-mail indicando a referência [1], que aponta uma solução simples e imediata.

Coincidentemente, um dos colaboradores da Pegasus me ligou, antes da mensagem da Abranet, abordando questão semelhante, em um cenário ampliado. Sua preocupação estava voltada para a demanda de seus clientes em censurar sítios da Internet, com o objetivo principal de manter funcionários e familiares, longe das armadilhas preparadas, geralmente em mensagens (“malware”, por exemplo) e, principalmene, longe de sítios indesejáveis. O cliente mal avisado sobrecarrega a rede interna de uma empresa ou provedor, quando algum programa de má-fé se instala em seu equipamento vulnerável. Também, gera constrangimentos para a empresa ou o provedor, que estão sempre sendo solicitados por terceiros (os CERTs, principalmente), a tomarem providências em relação a máquinas comprometidas de seus usuários.

Ponderações sobre o projeto

Conversa vai e conversa vem, com outros técnicos e amigos levaram-me a conduzir um experimento tendo como base a solução simples proposta em [1], um pouco mais ampliada. Experiencia bem sucedida e, as convesas, conduziram-me às seguintes abordagens e questões, que não se esgotam, por si:

  1. O usuário dos servidores de nomes da rede deve ser informado porque o domínio não estava acessível.
  2. Manter o DNSSEC intocável.
  3. Somente os recursivos devem ser alterados. Os autoritativos continuam exercendo o papel a eles destinado, de somente exibirem as zonas da rede. Os dominios censurados são respondidos com autoridade somente para as respectivas redes internas.
  4. Fácil utilização e, imediata disponibilidade, relativos ao bloqueio ou censura.
  5. Os domínios devem ser classificados e sub-classificados (2 níveis): malware, pornografia, pornografia infantil, etc.
  6. Manter histórico das atividades, por domínio, rede, segmento de rede e cliente.
  7. Aplicável hierarquicamente, no sentido de que dominios são bloqueados ou censurados pela administração da rede, pelo administrador de cada segmento de rede e por seus respectivos clientes. E o processo deve permitir a reversibilidade.
  8. Deve o cliente ser impedido de usar servidores recursivos externos (por exemplo, o openDNS)?
  9. A idéia deve ser exposta no sentido de permitir que servidores extenos à rede a implementassem?
  10. Se a resposta à questão anterior for sim, um outro nível hierárquico deve ser implementado?

A resposta ao item 9 é não e responde portanto o item 10. O item 8 foi deixado para cada rede decidir e, a solução está associada aos equipamentos de borda. Para a implementação escolheu-se a linguagem Python. A justificativa pela Python se deu pelo fato da TeleSA ter nos oferecido, como hospedeiro, a base de conhecimento do Sistema FaleOK e do VoIP Completo, implementada sob o Zope 3. Por outro lado há um conjunto de ferramentas na Python para trabalhar com DNS (unbound, principalmente) e DNSSEC .

O projeto envolvendo o pessoal de engenharia de software está em desenvolvimento. Será divulgado, para que possa ser implementado por redes de terceiros (item 9), exigência da TeleSA, que tem fornecido sitemático apoio à Infraestrutura da Internet de seus parceiros e disponibilizou sua equipe de desenvolvimento, para o desenho da proposta.

Considerações sobre a implementação

Além dos servidores recursivos, o Apache (2.2), também está envolvido. Em etapas, a implementação, supondo que o dominio a ser bloqueado é o exemplo.com.br. Suponha, ainda, a topologia de servidores de DNS conforme descrita aqui e o dominio para redirecionamento é o pegasus.sec3.br, já com DNSSEC. Embora os exemplos abaixo estejam aplicados a um único domínio a ser censurado, eles podem ser extendidos para mais de um domínio. Automatizadas ou não, as etapas estão descritas para serem feitas manualmente.

Etapa 1 (Bind): Criar a zona de redirecionamento para os dominios censurados, no master.

Estamos, nesse caso, seguindo a proposta em [1] com pequenas modificações. Para isto, criamos uma zona denominada censurado, simplesmente assim:


$TTL 1w
@ IN SOA sn01.pegasus.sec3.br. suporte.pegasus.sec3.br. (
     2008070308 ; Versao
     3600       ; refresh (1 hora)
     1800       ; retry (30 minutos)
     604800     ; expire (7 dias)
     1800 )     ; default TTL (30 minutos)

     IN NS sn01.pegasus.sec3.br.
     IN NS sn02.pegasus.sec3.br.
     IN NS sn03.pegasus.sec3.br.
     IN NS sn04.pegasus.sec3.br.
     IN NS sn05.pegasus.sec3.br.
     IN NS sn06.pegasus.sec3.br.
     IN A 192.168.1.1
www IN CNAME censurado.

Etapa 2 (Bind): Criar a referência à zonas do domínio de redirecionamento e para o exemplo.com.br, no master.

Para facilitar o manuseio futuro, manual ou não, adicionamos no named.conf:


. . .
include “/algum_caminho_de_diretorio/includes/censurado.inc”;
. . .

Como estamos falando do master, geralmente escondido, não há necessidade de usar “view”. Em seguida, construimos o censurado.inc, com as referêncas às zonas censurado, exemplo.com.br e, todas os domínios que desejamos censurar, assim:


zone “censurado” {
  type master;
  file “diretorio_da_zona/censurado.zone”;
};
zone “exemplo.com.br” {
  type master;
  file “diretorio_da_zona/censurado.zone”;
};

Qualquer domínio a ser censurado será referenciado como o exemplo.com.br, isto é, sempre apontando para a zona censurado.zone.

Etapa 3 (Bind): Criar a referência à zonas do domínio de redirecionamento e para o exemplo.com.br, nos secundários.

Considere que a resposta ao domínio exemplo.com.br é somente para IPs da rede. Assim, sua implementação nos Binds secundários, deverá ser feita sob um “view” recursivo, exclusivo para tais IPs, no named.conf. A seguir construa as referências no include censurado.inc, para os respectivos primáros.


zone “censurado” {
  type slave;
  file “diretorio_da_zona/censurado.zone”;
  masters {
    IP_do_primario;
  };
};
zone “exemplo.com.br” {
  type slave;
  file “zonas/censurado.zone”;
  masters {
    IP_do_primario;
  };
};

Etapa 4 (Unbound): Garantir que os recursivos façam o redirecionameto do domínio.

No Unbound, a solução é mais simples. Basta acrescentar as linhas seguintes, ao unbound.conf, onde as duas últimas devem ser repetidas para cada domínio censurado:

local-zone: “censurado” redirect
local-data: “censurardo A IP_do_servidor_Apache”

local-zone: “exemplo.com.br” redirect
local-data: “exemplo.com.br A IP_do_servidor_Apache”

O Unbound irá redirecionar tanto o exemplo.com.br como o http://www.exemplo.com.br para o Servidor Apache.

Etapa 5 (Apache): Preparando servidor Apache para o receber o redirecionamento.

A configuração, também é bastante simples, dependendo da implementação do Apache. No meu caso, o Apache possui VirtualHost e um domínio principal. Então, dentro do VirtualHost do domínio principal, coloquei:

Redirect permanent / http://www.pegasus.sec3.br/

Finalmente, no arquivo httpd.conf, ou equivalente, inseri a seguinte indicação para o domínio censurado:


ServerAdmin email_do_administrador
DocumentRoot “/data/wwwroot/www.pegasus.sec3.br”
ServerName http://www.pegasus.sec3.br
ServerAlias http://www.censurado http://www.pegasus.sec3.br
ServerAlias censurado http://www.pegasus.sec3.br
AddType application/x-httpd-php .php
ErrorLog …
CustomLog …

Comentários adicionais sobre a implementação

  • Consider-se a configuração do bind supondo-o um servidor recursivo ou, recursivo e autoritativo. Nesse caso, o recursivo é um view acessível somente à rede interna.
  • Os comentários da Introdução e o item que a seguem mostram que há muitas outras aplicações além das restrições impostas pela Justiça. Criatividade, inovaçao e sugestões podem melhorar as propostas.
  • Para quem usa servidores de DNS com IPs não públicos, certos cuidados não são necessários, tornando mais simples, ainda, a implementação.
  • Há diversas formas de redirecioamento no Apache. Um bom começo pode ser visto em [2] e nos manuais do Apache, em particular sobre o mod_rewrite, em [3].

Referências

[1] Simpson, J. M., Blocking domain names with bind.
[2]
yolinux.com, Apache Web Server Configuration for Web Site Redirection.
[3] Apache 2.2, Módulo mod_rewrite.

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: