Arquivo

Posts Tagged ‘topologia’

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

Idéias sobre o que fazer com um bloco /32 do IPv6-I

Última atualização: 15/03/2011.

Prólogo

O acaso favorece a mente preparada.
Louis Pasteur.

Ando observando que depois do IPv6, voltou à moda, binários e hexadecimais, com a intensidade do passado. Há quase 40 anos atrás, quando comecei a tatear em computação, os sistemas binário e hexadecimal, faziam parte da minha mente. Sempre que ensinava em um curso de uso do computador (ou de alguma linguagem, como o Fortran), era mandatório ensinar binário e hexadecimal. Depois, com o passar dos anos, já não era um pré-requisito tão fundamental. Para mostrar aqui, o quanto binário e hexadecimal eram importantes, guglei “assembler do IBM 1130”, meu primeiro computador, na esperança de achar uma listagem qualquer do Assembler do 1130, para exibir aqui. Fiquei alegremente surpreso ao encontrar [3]. O IBM 1130, naturalmente, não era meu, mas era como se fosse meu. Afinal fui a segunda pessoa a ter a chave do CPD da Universidade Federal de Viçosa. Por volta de 1968/1969, o BNDES comprou alguns IBM 1130 e espalhou por algumas instituições (não foram muitas, na época). Por acaso, um deles foi para a UFV, então muito conhecida pela sua especialidade em agronomia. O acaso favoreceu o Prof. Fábio Ribeiro Gomes. Uma mente reconhecidamente privilegiada, que fez com que um daqueles poucos IBM 1130s fosse parar no interior de Minas. No dia da inauguração do equipamento, entrei no CPD (a sala mais “chique” da UFV!) com um punhado de folhas de codificação, contendo um programa em Fortran escrito, para calcular áreas sob curvas de equações de regressão, através do método de Monte Carlo (acho que era o exercício final dos textos de instrução programada da IBM). De lá para cá, não parei mais.

Introdução

À memória dos sete grandes geômetras cristãos ou agnósticos: Descartes, Pascal, Newton, Leibnitz, Euler, Lagrange, Comte, (Allah se compadeça desses infiéis), e à memória do inesquecível matemático, astrônomo e filósofo muçulmano, Buchafar Mohamed Abenmusa Al Kharismi, (Allah o tenha em sua glória!), e também a todos os que estudam, ensinam ou admiram a prodigiosa ciência das grandezas, das formas, dos números, das medidas, das funções, dos movimentos e das forças, eu, el-hadj xerife Ali Iezid Izz-Edim ibn Salim Hank Malba Tahan (crente de Allah e de seu santo profeta Maomé), dedico esta desvaliosa página de lenda e fantasia.
De Bagdá, 19 da Lua de Ramadã de 1321.

Dedicatória feita por Malba Tahan, em seu livro, “O homem que calculava”, [4].

Os NIRs, como o Registro.br estão distribuindo blocos /32 para quem solicita IPv6 (ou para os LIRs), com algumas recomendações vindas dos RIRs (no nosso caso, o LACNIC), afagando as expectativas do ICANN (coordenador central da distribuição de IPs), [5]. Blocos /32, significam nada menos, nada mais do que 79.228.162.514.264.337.593.543.950.336 IPs!. Uma das recomendações é: distribuam blocos /64 para os usuários finais (incluíndo os usuários caseiros)! Algo como 18.446.744.073.709.551.616 (~264) IPs.

É importante fixar, em nossa mente, a dimensão dos números que rondam o IPv6. Por exemplo, compare-os com o espaço de endereçamento de todo o IPv4! Um outro exemplo, mais intuitivo pode-se tirar do “O homem que calculava”. Trata-se do famoso problema do Jogo de Xadrez. O lendário rei Iadava, prometeu ao Lahur Sessa, inventor do jogo de xadrez, uma quantidade de grãos de trigo, obtida pela seguinte sequencia 1 grão para a primeira casa do tabuleiro de xadrez, 2 grãos pela segunda casa, 4 grãos pela terceira casa e, assim sucessivamente até a casa 64 do tabuleiro. A razão dessa promessa, fica à deriva até a leitura do livro [4]. O resultado é o número acima, menos 1. Uma avaliação do resultado, em grãos de trigo, conduzem às seguintes curiosidades:

  • Se toda a Terra fosse semeada em grãos de trigo, o rei precisaria de colher durante 450 séculos, para cumprir a promessa.
  • Se fôssemos contar os grãos de trigo prometidos, à razão de 5 por segundo (um tempo razoável), um ser humano ou, um robô, trabalhando dia e noite sem parar, levaria 1.170 séculos, para finalizar a contagem.

Nos habituando aos exageros do IPv6, podemos partir para avaliar as alternativas para segmentar um bloco /32. Este primeiro artigo irá se concentrar no entendimento do endereçamento IPv6.

Vale, nesse momento, um pequeno comentário sobre o livro de Simon Singh, em [9]. Simon é um belíssimo escritor e em Big Bang ele reproduz grandezas numéricas (grandes e pequenas), igualmente imensas, pois o livro trata de cosmologia. Mas, Simon, citando o exemplo acima, do Malba Tahan na página 443, deixa pela metade a quantidade de grãos na última casa do tabuleiro e, lamentavelmente, não lembra o autor carioca da fábula que, curiosamente, nunca foi às Arábias.

O espaço de endereçamento do IPv6. Necessidade da mudança de paradigma.

Linhas gerais sobre a alocação de IPv6 pelos IRs podem ser vistas em [5] e diversos outros locais, cuja mais importante referência está em [8]. Uma preocupação constante na literatura, principalmente no início do aparecimento do IPv6 é em relação a agregação, em particular, nas alocações subsequentes. Para permitir a agregação de informações de roteamento e, consequentemente, diminuir a expansão das tabelas de roteamente, a sugestão é distribuir os IPv6s de maneira hieráquica, respeitando a topologia da infraestrutura da rede. Vamos começar olhando na Figura 1, que segue. É uma tabela simples, proposta pelo RIPE NCC, onde a primeira coluna discrimina blocos de IPv6, do /16 ao /56. A segunda e terceira colunas discriminam, respectivamente os blocos /48 e /56 (espera-se, os mais usados na distribuição de quem tem um /32). A última coluna representa os números de bits necessários para atingir os 128 bits do endereçamento. Por exemplo, a primeira linha, representando o bloco /16. Um /16 pode ser subdivididos em 4G redes de blocos /48 e em 1T de redes com blocos /56. Como podemos ver, números incríveis. O que se pode fazer com 1T redes /56?

cidr_working4-1

Figura 1. RIPE NCC IPv6 Chart. Fonte [2].

Dividir para conquistar! Vamos usar essa máxima e, construir uma tabela mais palatável, já que os LIRs recebem blocos /32. A simplificação da Figura 1 está na Figura 2, abaixo. A estrutura é a mesma. Na primeira linha, por exemplo, começa com o bloco /32. Com um /32, podemos obter 65.536 redes com bloco /48. A conta é muito simples: 48-36=16 bits, que nos dá 64K (216). São mais de 16 milhões de redes com blocos /56! Blocos /56 implicam em 272. Muito maior, mas muito maior mesmo, do que os grãos do tabuleiro de xadrez! Tá mais para as medias cosmológicas.

TabelaIPv6-Reduzida

Figura 2. Tabela do RIPE NCC reduzida.

Há um outro quadro mais esperto. O Nic.br, tem oferecido cursos presenciais do IPv6 e produzido um material muito bom [10]. Nas Figuras 3 e 3A, que seguem, quadros produzidos pelo pessoal do Nic.br são, realmente, um Guia Didático de Endereçamento IPv6, perfeito! Por razões históricas, foi mantida a Figura 3. Recomenda-se o foco na Figura 3A, que é a última atualização (Dez 2010). Bits, bytes, binário e hexadecimal se misturam sem, absolutamente, nenhuma complicação.

GuiaDidaticodeEndereçamento

Figura 3. Guia do Nic.br.

Figura 3A. Guia do Nic.br (Versão Dez 2010: Guia didático de endereçamento IPv6 – Nic.br).

As escolhas de como dividir o bloco /32 são imensas. Alguns parâmetros devem orientar, como exemplo o tamanho das redes de nossos clientes e as respectivas estimativas de crescimento, entre outras. A perspectiva da escalabilidade de nossos clientes é, também, uma previsão difícil, [11]. Algumas abstrações aqui, outras acolá e, o conhecimento do negócio, podem nos ajudar a decidir.

Endereços IPv6

Vamos acompanhar, inicialmente a RFC4291, citada em [12]. Tentaremos qualificar o mecanismo de enderaçamento IPv6, atento aos detalhes que são relevantes tendo em vista esse texto. De imediato seria interessante conhecer o significado de “nó” no contexto do IPv6. “Nó” é um dispositivo que implementa o IPv6. Um “roteador” é um nó que encaminha pacotes IPv6, não explicitamente endereçados a ele. Também, “host” é um nó que não é um “roteador”. Tais definições estão em [13]. Continuando, existem três tipos de endereços IPv6, discriminados e caracterizados como segue:

  • Unicast: É o identificador de uma única interface de um nó. Um pacote enviado para um endereço unicast é entregue à interface identificada por aquele endereço.
  • Anycast: É o identificador de um conjunto de interfaces (geralmente pertencentes a nós diferentes). Um pacote enviado para um endereço anycast é entregue a uma das interfaces identificadas por aquele endereço (a mais próxima, segundo os protocolos de roteamento).
  • Multicast: É o identificador de um conjunto de interfaces (tipicamente pertencentes a nós diferentes). Um patote enviado para um endereço multicast é entregue a TODAS as interfaces identificadas por aquele endereço.

Devemos ter em mente as seguintes informações importantes sobre os endereços IPv6:

  • Representação textual dos endereços:
    • A representação preferida é x:x:x:x:x:x:x:x, onde “x” são quatro dígitos hexadecimais. Por exemplo:

      CAFE:CA5A:DAD0:F0CA:ABCD:EF01:2345:6789
      2001:0DB8:0:0:8:800:200C:417A

    • Pode-se usar :: com o objetivo comprimir grupos de zeros hexadecimais, no meio, à esqueda ou à direita da representação textual, desde que somente seja usado uma única vez. Exemplos:

      2001:DB8:0:0:8:800:200C:417A ~ 2001:DB8::8:800:200C:417A
      FF01:0:0:0:0:0:0:101 ~ FF01::101
      0:0:0:0:0:0:0:1 ~ ::1
      0:0:0:0:0:0:0:0 ~ ::

  • Pode-se representar um endereço através do tradicional prefixo CIDR ou seja endereço-ipv6/prefixo.
  • O tipo do endereço é identicado pelos bits de mais alta ordem. Abaixo uma tabela com tal classificação:

    Tipo de endereço Prefixo binário Notação IPv6
    Multicast 11111111 FF00::/8
    Unicast Todo o resto Não aplicável
    Anycast Parte do espaço do Unicast Não distinguível sintáticamente
  • Uma questão que pode ficar confusa é o fato do endereço unicast estar aparecendo como todo o restante do endereçamento, exceto o multicast. Para resolver esse impasse de interpretação, foi definido o escopo de um endereço IPv6. Nesse caso, o tipo de endereço anycast, define um escopo no espaço de endereçamento unicast. E, para fixar a presença dos endereços unicast que são roteáveis na Internet, existe o escopo global, denominado Unicast Global. A referência correta para a especificação dos escopos do unicast é [14] e, constantemente atualizada.
  • Tipos especiais de endereços, qualificados pelo escopo, podem ser visualizados na tabela que segue, incluindo sua definição:

    Nome Notação IPv6 Significado
    Não especificado ::/128 Não deve ser usado para identificar uma interface. Roteadores não roteiam pacotes para este endereço
    Loopback ::1/128 Identifica a interface do host local.
    Link local FE80::/10 São os endereços privativos. Não roteáveis para a Internet.
    Local único FC00/7 Usado somente em ambientes desconectados da Internet.
    Mapeamento IPv4 ::FFFF:0:0/96 Usado nos mecanismos de transição
    Tunelamento Teredo 2001::/32 Tecnologia de transição. É um mecanismo de atribuição de endereço IPv6 sob IPv4.
    Endereçamento 6to4 2002::/16 Será usado no período de transição no 6to4
    ORCHID 2001:10::/28 Não roteável. Usado para CHI (Criptographic Hash Identifiers).

Embora pareça um pouco complicado a lembrança de todas as alternativas de representação de endereços, tudo é uma questão de se acostumar. Para facilitar a descoberta do tipo e escopo de endereços IPv6 está em evolução, aqui, uma facilidade para descobrir, rapidamente, algumas informações sobre um número IPv6 específico.

Atualização em 15/03/2011: O documento [15] é uma recente tradução do RIPE, que vale a pena dar uma olhada.

Referências

[1] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., Hahn, C., IPv6 Unicast Address Assignment Considerations. RFC5375, December 2008.
[2] RIPE NCC, Understanding IP Addressing.
[3] Aleks, N. & Knittel, B., IBM 1130.
[4] Tahan, M., O homem que calculava. Edição completa em .pdf, aqui!
[5] RIPE NCC, IPv6 Address Allocation and Assignment Policy, June 2009. pdf.
[6] Hinden, R., Deering, S., IP Version 6 Addressing Architeture, RFC3513 (Standards Track), February 2006.
[7] Tsuchiya, P., On the Assignment of Subnet Numbers, RFC1219, April 1991.
[8] IANA, Number Resources => IP Address Allocations => Internet Protocol Version 5 (IPv6).
[9] Singh, S., Big Bang, Tradução de Jorge Luiz Calife, Record, 2006.
[10] Projeto IPv6.br, Guia didático de endereçamento IPv6, http://www.ipv6.br. Curso IPv6 Básico (Presencial).
[11] Blanchet, M., A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block, RFC3531, April 2003.
[12] Hinden, R., Deering, S., IP Version 6 Addressing Architecture, RFC4291, February 2006.
[13] J. Loughney, Ed., IPv6 Node Requirements, RFC4294, April 2006.
[14] IANA, Internet Protocol Version 6 Address Space, http://www.iana.org/assignments/ipv6-address-space/.
[15] Preparing an IPv6 Addressing Plan Manual, December 2010: Original text, March 2011: Translation provided by RIPE NCChttp://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf.

Categorias:IPv6, TCP/IP Tags:, , , , , , ,

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: