você está aqui: Home → Colunistas → Sysadmin

MaraDNS, BIND ou djbDNS? Tropias & utopias

Colaboração: Jairo Willian Pereira

Data de Publicação: 23 de Novembro de 2007

1. INTRODUÇÃO

O Domain Name System - Sistema de Nomes de Domínios, ou simplesmente DNS é um sistema de gerenciamento de nomes hierárquico e distribuído. A implementação do DNS-Berkeley, foi desenvolvido originalmente para o sistema operacional BSD UNIX 4.3, em meados de 1984. Como a maioria das implementações de DNS teve suas raízes nas RFCs 882 e 883, e continuou sendo atualizado baseado nas RFCs 1034 e 1035. Sua principal função, atuando numa hierarquia cliente/servidor, é traduzir nomes para os endereços IP e endereços IP para nomes, permitindo a localização de hosts em um domínio determinado. Atualmente existem 13 servidores DNS raiz no mundo todo e sem eles a Internet não funcionaria. Por questões de implementação e história, destes, dez estão localizados nos Estados Unidos da América, um na Ásia e dois na Europa. Com intuito de aumentar a redundância e disponibilidade, foram criadas réplicas localizadas por todo o mundo, inclusive no Brasil a partir de 2003. Diante do tema, o objetivo deste artigo é apresentar alguns recursos oferecidos por este serviço de diretório hierárquico, apresentando algumas das implementações mais utilizadas e conhecidas, comparando-às em questões de recursos, funcionalidades, segurança, custo e benefício.

1.1. Recursos analisados

As características utilizadas para efeito comparativo, foram construídas considerando-se recursos úteis e dados relevantes na hora de optar pelo serviço de DNS, sendo que algumas particularidades e funções não muito utilizadas, não foram mensuradas neste pequeno documento. Todos os recursos apresentados, serão explanados para que o leitor possa ter uma base de teoria caso encontre algum recurso que não lhe seja familiar. O autor recomenda que para informações mais detalhadas sobre cada aplicação ou recursos exclusivos, seja consultada a página dos respectivos criadores das soluções.

2. PRODUTOS ENVOLVIDOS

Para seleção das aplicações motivo desse estudo, foram consideradas algumas particularidades dos produtos apresentados.

2.1. BIND

O BIND foi escolhido por ser a implementação mais utilizada quando o assunto é servidores de Internet e/ou serviços correlatos, além de seu valor histórico como precursor do serviço. Possui a maior base instalada da rede, e uma imensa plataforma de defensores e seguidores. Embora possua um histórico de problemas de implementação e segurança, ainda é a solução preferida quando o assunto é servidor de DNS.

2.2. djbDNS

Considerado a mais segura implementação de DNS, foi escolhido por ser atualmente um substítuto e concorrente a altura do BIND. Construído desde sua concepção visando ser uma aplicação segura, todos seus módulos, chamadas de sistema, inter-relacionamentos, maneira de execução e tratamento crítico de dados, presam pela segurança e controle dos eventos.

2.3. Microsoft DNS

Solução mais utilizada quando o assunto é plataforma Wintel. Embora tenha sofrido alterações que não o tornem mais compliance com as RFCs do serviço, possuí características específicas que tornam o processo de integração na plataforma Windows, extremamente fácil e transparente. Devido as particularidades do ambiente, possui implementação mais onerosa aos recursos do sistema.

2.4. MaraDNS

Uma implementação de DNS não muito conhecida, com características enxutas, algumas particularidades e segundo seu criador, mais segura que o djbDNS, três vezes mais rápida do que qualquer um de seus concorrentes apresentados neste documento. Binários do servidor são pequenos, leves, extremamente recomendado para dispositivos e equipamentos embarcados.

3. RECURSOS ANALISADOS

A tabela ilustra didaticamente a disponibilidade dos recursos oferecidos pelas soluções apresentadas:

0	CLI acrônimo para Command Line Interface e GUI Graphical User Interface (linha de comando e interface gráfica)
1	djbDNS usa programas separados para executar pesquisas recursivas/autoritativas e não podem compartilhar um IP.
2	djbdns provê facilidades na transferência de zonas, de modo que após essa transferência ele possa agir como autoritativo dessa zona.
3	Não default, manualmente ativado via registro suficiente para servidor slave/secondary. Disponível somente no Windows 2003 Server.
4	Disponível somente sob Windows Server 2003, e ativado via linha de comando.
5	Instalação inicial mais complicada que BIND. Após essa etapa a "manutenção" e administração do programa é mais fácil e tranquila.
6	Construção inicial visando segurança e performance. Módulos operam isoladamente em ambiente controlado com validação de dados.
7	Diretamente dependente do sistema operacional instalado.
8	Informações adicionais em http://www.rh.edu/~rhb/cs_seminar_2005/SessionA2/steniger.pdf
9	Acompanhado de documentação do servidor/serviço.
10	Não provê suporte direto a slave. Quando uma transferência de zona é preciso, age como autoritativo para essa zona.
11	Extremamente pequeno e leve, recomendado para dispositivos embarcados.
12	Informações adicionais em http://www.maradns.org/speed.comparison.html
13	Para requisições de alguns clientes não-triviais, MaraDNS trata uma requisição IXFR como fosse um pedido AXFR (completo).
14	MaraDNS suporte sintaxe SPF similar a BIND, bastando substituir as aspas duplas por aspas simples.

3.1. Explanação dos Recursos

As características apresentadas, serão explicadas para que o leitor possa optar por quais recursos são realmente relevantes durante seu processo de escolha. No final do documento, foi concebida uma mini-conclusão baseada nas informações coletadas e necessidades da análise.

3.1.1. Autoritativo

Modo de operação do DNS, se o mesmo pode prover função autoritativa. A maioria dos DNS provêm diversos recursos monoliticamente, mas alguns preferem isolar os recursos em aplicações diferentes, como forma de melhorar a performance ou por questões de segurança. Normalmente um servidor que provê uma resposta autoritativa sobre uma determinada zona, retorna ao cliente uma resposta com o bit de autoridade setado.

3.1.2. Recursivo

Esse recurso onera em muito ao servidor DNS, pois solicita que o mesmo apresente a resposta perfeita/correta sobre o IP solicitado. Numa consulta recursiva, caso o servidor não saiba a resposta, deverá sair questionando outros servidores até que consiga o resultado da solicitação pelo cliente e somente este. Difere da interativa porque neste tipo de solicitação, o servidor questionado tem obrigação de responder apenas com uma melhor resposta, devendo ser: eu não tenho sua informação, mas o servidor X pode ter pergunte a X.

3.1.3. Modo Slave

A capacidade de slave prove ao servidor a possibilidade de construir uma cópia de redundância do servidor principal (master), normalmente rodando a mesma versão da aplicação, mas co-existindo como uma cópia do servidor principal (master). Todas as parametrizações são executadas no servidor master, e o slave tem a simples missão de importar essas informações. Em caso de problemas com o principal, o slave pode suprir sua falta sem problemas, porém este opera em modo read-only e não poderá comportar novas mudanças.

3.1.4. Caching

Rodam o software de DNS mas não são fontes oficiais de informações a respeito do domínio. Tem função de obter respostas as perguntam solicitadas a partir de outros servidores, e armazenam estas respostas localmente para aumentarem a performance das próximas solicitações (uma vez que os próximos questionamentos já estarão cacheados e sendo respondidos a partir da estrutura local da rede, bem mais perto da origem anteriormente questionada).

3.1.5. DNSSec

Nome das três extensões de segurança propostas para o DNS (RFC 2065). As extensões oferecem distribuição de chaves, certificação de origem dos dados e certificação na transação/requisição. Os dados trafegados serão protegidos utilizando-se 3 novos Resources Records (KEY, SIG e NXT). Sua implementação garante uma camada adicional de segurança ao protocolo, que por concepção, é bem inseguro em sua versão original.

3.1.6. TSIG

Transaction SIGnature. Um protocolo para garantir autenticação em comunicações DNS criptografadas usando chaves compartilhadas e função hash de mão única (secre keys & one-way hashing), garantindo o reconhecimento dos end-points envolvidos na comunicação. Utiliza um timestamp baseado no uso de NTP para dificultar que respostas não possam ser reaproveitadas/montadas a partir de pacotes capturados.

3.1.7. IPV6

Capacidade do servidor prover suas funcionalidades e estar preparado para uma rede baseada na nova versão do Protocolo Internet IPV6, cuja versão pretendia resolver algumas problemas da versão anterior (IPV4), entre eles, segurança e maior capacidade de fornecimento de números IPs.

3.1.8. Wildcard

Capacidade de lidar com caracteres especiais, metadados e/ou expressões regulares. Diz respeito a capacidade do servidor em lidar com variáveis que podem ser inseridas/utilizadas para facilitar o processo de configuração e/ou parametrização do serviço.

3.1.9. Suporte à Views

View fornece uma espécie de confinamento das informações armazenadas no servidor. Provê a capacidade de identificar que informação podem ser públicas ou privadas, de forma que somente quem participar desse grupo poderá consultar ou questionar informações dessas áreas de confinamento.

3.1.10. Segurança

Neste quesito, foram analisadas as características de cada aplicação, desde sua implemementação, desenvolvimento até a maneira como a mesma se instala e é executada quando está em operação. Modularização, nível de atualização, histórico de bugs, continuidade, problemas conhecidos, comunicação, foram alguns dos itens relevados. Neste item especificamente, djbdns e MaraDNS foram considerados ótimas soluções atualmente disponíveis.

3.1.11. Round-Robin

Mecanismo de balanceamento de carga burro (pois não analisa a carga real dos hosts envolvidos), na qual as solicitações DNS para um dado hostname, passam por um processo de rotação, de forma que a cada requisição para um mesmo destino, um IP diferente configurado no pool de atendimento seja repassado para o solicitante. São respostas alternativas para a mesma consulta DNS.

3.1.12. Multi-Threading/Processor

Capacidade do serviço rodar em ambiente multi-processados ou com capacidade de thread. Uma thread é um fluxo seqüêncial de execução, e ambientes multi-threading possuem a capacidade de executar (ou parecer que estão sendo executadas) mais que uma linha/bloco de códigos simultaneamente. Sua capacidade de execução, está diretamente ligada ao sistema operacional em uso e método ou linguagem de construção.

3.1.13. Processamento & Memória

Quanto cada aplicação consome em questão de processamento da máquina e uso adequado de memória. Algumas URLs e testes de benchmark foram consultadas para validar testes nas mais diversas aplicações servidoras. Bastante impressionado pelos números oferecidos pela solução MaraDNS, cujos testes consultados mostraram ser uma solução extremente leve, eficaz e eficiente.

3.1.14. Performance de Cache & Queries

Capacidade de lidar com elementos cacheados e solicitações corretas ou não. Neste quesito fica claro que entre os analisados, quando mais modular a solução, maior o foco em tarefas específicas, melhor o tempo de resposta e performance associada. Mais uma vez, números apresentados pelo MaraDNS impressionaram nos tempos, cujo valores próximos eram 3 vezes mais rápidos que os concorrentes mencionados.

3.1.15. SPF Sender Policy Framework

Extensão do SMTP que facilita a identificação de spam com endereços de origem forjados. Cada domínio interessado em combater spam, acrescenta uma linha de texto padronizada a configuração do DNS, descrevendo quais servidores de email estão autorizados a gerar mensagens naquele domínio. Quem possuir o suporte ao SPF, basta consultar o DNS para saber que para o dominio X, somente os servidores Y podem distribuir mensagens na rede.

3.1.16. Split DNS

Útil quando servidores devem responder consultas DNS específicas a segmentos específicos (como rede pública (Internet) e questionamentos internos (privado)). O recurso permite que servidores DNS possam dividir o tráfego durante processo de resolução de nomes, além de aumentar a segurança com essa divisão lógica.

3.1.17. Transferência Incremental (IXFR)

Capacidade de transferir entre os servidores participantes somente a diferença entre a última informação enviada e o estado corrente/atual (delta). Dependendo da quantidade de entradas e dinamismo do servidor, pode economizar uma boa quantidade de banda para o serviço.

3.1.18. Atualização Dinâmica

Possibilidade de intergrar-se de forma automática ao serviço de DHCP. Com esse recurso, através de informações passadas pelo DHCP, o DNS pode inserir, remover, atualizar e manter sua base de acordo com equipamentos realmente em operação.

4. ADENDOS & EXTRAS

Devido ao alto índice de problemas com SPAM, a técnica de SPF vem sendo amplamente utilizada em função de sua facilidade de implementação e benefícios relacionados ao combate desta praga.

A técnica de Split Horizon consiste em respostas baseadas na origem da consulta, ou seja, se um servidor DNS está conectado a duas ou mais redes (internas, backbones distintos, etc.), a resposta a requisição do cliente será de acordo com sua origem. Esta técnica garante uma maior velocidade no tempo de resposta porque o servidor DNS fala diretamente para a rede a qual é consultado. A Microsoft recomenda que para a solução, seja implementado servidores isolados, quantos forem necessários, com o recurso de conditional-forward habiltado para o tratamento das requisições e segmentação de tráfego.

5. CONCLUSÃO

O BIND continua sendo o mais completo oferecedor de recursos avançados, de forma que suas implementações durante todos esses anos tentaram contemplar quase todos os requisitos sugeridos pelas RFCs relativas/amarradas ao serviço de DNS. Continua sendo a maior base instalada, principalmente quando o assunto são serviços de Internet (talvez se for comparado a quantidade de servidores DNSs já embutidos nas diversas instalações de Windows pelo mundo, esse número fique mais próximo). Sua concepção monolítica de oferecimento de serviços torna-o um produto pesado, difícil de configurar/administrar, com imenso histórico de problemas nos diversos recursos oferecidos pelo pacote, tornando sua classificação no quesito segurança, o principal motivo ao qual os experts no assunto andam trocando-o pelo concorrente djbdns. Se sua preocupação não é segurança, e precisa de compatibilidade com os mais diversos recursos, acreditamos ser a solução preferencial.

Contruído de forma modular, preocupando-se com performance, segurança de sua implementação e operação, o djbdns atualmente é a solução de substituição preferencial quando o administrador precisa substituir o BIND, movido pela preocupação em performance e pela constante divulgação de bugs. Seu criador, o mesmo do servidor de email mais seguro atualmente (Qmail), é admirado por uns e odiados por outros, visto sua radicalidade em tentar sanar problemas conhecidos construindo suas próprias bibliotecas e ferramentas. Excetuando algumas particularidades, a qualidade de sua arquitetura e concepção, provê a maior parte das funções oferecidas pelo BIND, tendo como aliado sua melhor propaganda: segurança, performance e alta-disponibilidade. Se o leitor não precisa de todos os features oferecidos pelo BIND, segurança, performance e disponibilidade é sua preocupação, a solução tem sido massivamente testada e mencionada como uma excelente opção.

Como o artigo visa soluções abertas, a solução da MS foi apresentada somente para efeito comparativo a uma plataforma bem utilizada. É recomendada para ambientes onde o fator integração Wintel seja realmente necessário em todos os recursos. Sua principal desvantagem está atrelada a parte financeira, cujo custo está embutido na solução de servidor comprada pelo usuário.

Finalizando, o autor gostaria de deixar a cargo do leitor uma comparação entre o djbdns e MaraDNS (a zebra do artigo). O autor leu quase que o site inteiro do criador e encontrou algumas referencias de benchmark que afirmavam que a solução era mais segura e três (3) vezes mais rápida que os concorrentes mencionados. Links e informações foram encontrados e analisados, mas em função do tempo disponível para suas análises, gostaria de deixar o veredito final a cargo do leitor.