Arquivo

Archive for maio \31\-03:00 2011

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.

Atributos do BGP

 

Introdução

Antes de avançarmos a outros tópicos do BGP é interessante uma abordagem mais efetiva sobre atributos no BGP (atributos de caminho). O significado de atributo e sua categorização estão definidos na RFC42711. Mas, o BGP é uma complexidade em constante movimento. Outros atributos foram aparecendo, recomendados, incorporados em novas implementações, e assim excedendo-se ás especificações da RFC principal. Como veremos, a importância de tais mudanças é relativa.

Como novos atributos são incorporados ao BGP

O IANA11 (Internet Assigned Numbers Authority) é o órgão que coordena e garante que qualquer código ou número utilizado pelos protocolos da Internet seja único12. Inclui nessa relação, IPv4, IPv6, números de portas e todos os outros valores necessários. Em particular, ele é responsável pelos códigos referentes aos atributos do BGP. As novas implementações de atributos foram regulamentadas pela RFC170010 e depois, atualizada pela RFC32329. Quando a RFC42711 substituiu a RF1771, haviam 7 atributos especificados para o BGP (códigos de 1 a 7). A RFC204213 informa a maneira como novos tipos de atributos podem ser registrados e exibe 13 atributos registrados até sua publicação (1997):

Value      Code 

   1       ORIGIN  
   2       AS_PATH
   3       NEXT_HOP
   4       MULTI_EXIT_DISC
   5       LOCAL_PREF
   6       ATOMIC_AGGREGATE
   7       AGGREGATOR
   8       COMMUNITY
   9       ORIGINATOR_ID
  10       CLUSTER_LIST
  11       DPA 
  12       ADVERTISER
  13       RCID_PATH / CLUSTER_ID
  ...
 255       reserved for development

Da lista acima, o valor 11 (DPA) é um atributo proposto por Chen & Bates em http://tools.ietf.org/html/draft-ietf-idr-bgp-dpa-05 e nunca definido ou aceito, embora tenha sido caracterizado na RF19987. Já os valores 12 e 13, foram caracterizados pela RFC1683, que foi reclassificada como histórica pela RFC4223. Por tais razões, somente iremos nos concentrar naqueles atributos mais usados ou bem qualificados pela literatura. Também, é interessante observar, que novos atributos podem não estar presentes, ainda, nas implementações de BGP e, um bom exemplo, são as comunidades extendidas, que permitem o uso de ASN de 64 bits, entre outras facilidades5. A relação completa dos atributos registrados no IANA pode ser consultada aqui, na qual há referências específicas sobre cada atributo, inclusive, qualificando o estado atual de cada um.

Uma curiosidade é o weight, que na literatura às vezes aparece como atributo do BGP. Se olharmos na relação do IANA, weight não aparece. Realmente, ele não é um atributo do BGP. É apenas um mecanismo, muito importante, que impacta a seleção de rotas locais e, não afeta as decisões de roteamento em outros ASes do empareamento.

O presente trabalho, de natureza prática, tem como objetivo caracterizar os atributos do BGP, sem a preocupação dos detalhes, mas com foco nas referências, até porque, o uso está sendo apresentado na série de artigos que começam em https://juliaobraga.wordpress.com/category/mikrotik/page/8/.

Categorização dos atributos

Os atributos do BGP são encaminhados entre os BGPs que falam, através das mensagens de UPDATE. A RFC42711, classifica os atributos em quatro categorias a saber:

  1. Conhecido obrigatório (Well-known mandatory): São atributos que devem estar presentes em TODAS as implementações do BGP (conhecido) e, também, presentes em TODAS as mensagens de UPDATE (obrigatório).
  2. Conhecido discricionário (Well-known discretionary): São atributos que devem estar presentes em TODAS as implementações do BGP (conhecido) e NÃO NECESSARIAMENTE presentes em mensagens de UPDATE (discricionário).
  3. Opcional transitivo (Optional transitive): São atributos que podem ou não estar presentes em implementações de BGP (opcional). Se estiver presente, ele deve ser reencaminhado (transitivo) a outros BGPs que falam e empareados, também, via mensagens UPDATE.
  4. Opcional não-transitivo (Optional non-transitive): São atributos que podem ou não estar presentes em implementações de BGP (opcional). Ao receber um atributo nesta categoria, o BGP que fala não deve reencaminhá-lo (não-transitivo) a outros BGPs que falam empareados.

Detalhes específicos, em particular, aqueles relacionados com a transitividade envolvem comportamentos importantes do BGP, que não estão sendo ditos neste texto. Os interessados devem recorrer às página 22/23 da RFC42711, item 5. A mesma RFC especifica erros que podem ocorrer em cada etapa da mensagem de UPDATE, sem afetar diretamente o funcionamento normal das políticas de roteamento.

Atributos do BGP representam um importante recursos/facilidade, diretamente associada às políticas de roteamento, como falamos. A categorização dos atributos é suficientemente inteligente para permitir versões competitivas entre os diversos fabricantes de roteadores. Ao mesmo tempo oferece ao administrador uma confortável posição de escolha, sob a ótica da compatibilidade.

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [January 2006] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).

  2. RFC5701, IPv6 Address Specific BGP Extended Community Attribute Y. Rekhter [November 2009] (TXT = 9626) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: l3vpn)

  3. RFC5668, 4-Octet AS Specific BGP Extended Community Y. Rekhter, S. Sangli, D. Tappan [October 2009] (TXT = 9017) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: l3vpn)

  4. RFC4384, BGP Communities for Data Collection D. Meyer [February 2006] (TXT = 26078) (Also BCP0114) (Status: BEST CURRENT PRACTICE) (Stream: IETF, Area: ops, WG: grow)

  5. RFC4360, BGP Extended Communities Attribute S. Sangli, D. Tappan, Y. Rekhter [February 2006] (TXT = 24145) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)

  6. RFC3765, NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control G. Huston [April 2004] (TXT = 16500) (Status: INFORMATIONAL) (Stream: INDEPENDENT)

  7. RFC1998, An Application of the BGP Community Attribute in Multi-home Routing E. Chen, T. Bates [August 1996] (TXT = 16953) (Status: INFORMATIONAL) (Stream: IETF, Area: rtg, WG: idr)

  8. RFC1997, BGP Communities Attribute R. Chandra, P. Traina, T. Li [August 1996] (TXT = 8275) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)

  9. RFC3232, Assigned Numbers: RFC 1700 is Replaced by an On-line Database J. Reynolds [ January 2002 ] (TXT = 3849) (Obsoletes RFC1700) (Status: INFORMATIONAL) (Stream: Legacy)

  10. RFC1700, Assigned Numbers J. Reynolds, J. Postel [ October 1994 ] (TXT = 458860) (Obsoletes RFC1340) (Obsoleted-By RFC3232) (Status: HISTORIC) (Stream: Legacy)

  11. IANA, Number Resources. Disponível em http://www.iana.org/numbers/. Acessado em: 11/05/2011.

  12. IANA, Protocol Registries. Disponível em http://www.iana.org/protocols/. Acessado em: 11/05/2011.

  13. RFC2042, Registering New BGP Attribute Types B. Manning [ January 1997 ] (TXT = 4001) (Status: INFORMATIONAL) (Stream: Legacy)

  14. RFC4456, BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates, E. Chen, R. Chandra [ April 2006 ] (TXT = 23209) (Obsoletes RFC2796, RFC1966) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr)

  15. Cisco, Border Gateway Protocol. Disponível em http://docwiki.cisco.com/wiki/Border_Gateway_Protocol#BGP_Attributes. Acessado em: 06/05/2011.

  16. Cisco, BGP Best Path Selection Algorithm. Disponível em http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml. Acessado em: 06/05/2011.

Categorias:Atributos, BGP, Mikrotik, TCP/IP