Todo mundo precisa lidar com o DNS, um DNS bem configurado é a base de uma rede onde serviços são executados. Entender como o DNS funciona e como podemos melhorá-lo é importante para fazer o serviço funcionar corretamente e de forma segura.
Um pouco da história do DNS:
Os servidores de DNS são os principais servidores na internet, pois permitem que através de nomes possamos acessar os endereços. Já que toda a internet é baseada em IP, para acessarmos uma página precisaríamos conhecer número IP dela, mas como é mais fácil lembrar de vários nomes que vários números, o DNS permite que esses nomes sejam resolvidos para números, facilitando assim o uso da internet.
No início da internet, como foi pensada para pouco uso, havia um arquivo hosts.txt que continha todos os IP e nomes de máquinas que existiam na internet, o arquivo era mantido pela NIC (Network Information Center) e distribuído por um único host, o SRI-NIC. Os administradores da Arpanet enviavam ao NIC, por e-mail, quaisquer mudanças que tivessem sido efetuadas e periodicamente SRI-NIC era atualizado, assim como o arquivo hosts.txt. As mudanças eram aplicadas em um novo hosts.txt uma ou duas vezes por semana. Com o crescimento da Arpanet, entretanto, este esquema tornou-se inviável. O tamanho do arquivo hosts.txt crescia na proporção em que crescia o número de máquinas na internet.
Além disso, o tráfego gerado com o processo de atualização crescia em proporções ainda maiores uma vez que cada host que era incluído não só significava uma linha a mais no arquivo hosts.txt, mas um outro host atualizando a partir do SRI-NIC. Com o uso do TCP/IP pela Arpanet a rede cresceu exponencialmente o que tornou a atualização do arquivo algo quase impossível de ser mantido.
Os administradores da Arpanet tentaram outras configurações que resolvessem o problema do hosts.txt. O objetivo era criar um sistema que resolvesse os problemas em uma tabela única de hosts. O novo sistema deveria permitir que um administrador local tornasse os dados mundialmente disponíveis. A descentralização da administração resolveria o problema do gargalo gerado por um único host e diminuiria o problema do tráfego. Além disso, o fato da administração ser local faria com que atualizar os dados se
tornasse uma tarefa bem mais simples. O esquema deveria usar nomes em hierarquia para garantir a exclusividade dos nomes.
Paul Mockapetris, do USC’s Information Science Institute, foi o responsável pela arquitetura do sistema. Em 1984 ele lançou as RFCs 882 e 883, que descreve o “Domain Name System”, ou DNS. Estas RFCs foram sucedidos pelas RFCs 1034 e 1035, que possuem as especificações atuais do DNS.
O DNS é foi criado para ser hierárquico, distribuído e recursivo, além de permitir o cache de suas informações. Assim nenhuma máquina teria que saber todos os endereços de Internet, apenas os que estão abaixo dela diretamente. Os principais servidores de DNS são os Root Servers, servidores raiz de Internet (.). São servidores que sabem quais são as máquinas responsáveis pelos domínios de primeiro nível. Ao todo existem 13 Root Server. Resumindo:
– Hierárquico: Divide a resolução de nomes em Níveis;
– Distribuido: Ninguém mais sabe tudo, cada um sabe apenas uma parte do endereço;
Para melhor entendermos podemos exemplificar a busca por um domínio da seguinte forma:
Um cliente pede ao DNS de seu provedor por um IP de um domínio, faz com o o DNS siga o seguinte caminho:
Então quando você não tem um DNS de cache e precisa resolver um endereço, o resolvedor (cliente) solicita ao servidor Root Server o endereço. Como o Root Server só conhece os domínios de primeiro nível (.com .org .br .uk), ele repassa para o servidor que ele conhece que está ligado ao pedido do cliente, no caso o .br, que passa pra quem sabe a resposta o .com que passa pra quem sabe a resposta .vagnerfonseca que indica qual host tem a informação pedida.
O DNS trabalha com as portas 53 (UDP e TCP) e 953 (TCP) para seu funcionamento e controle, respectivamente. A porta 53 UDP é usada para consultas entre Servidor e Cliente, e a porta 53 TCP geralmente é usada para sincronia (troca de arquivos de database de zonas) entre Master (Primário) e Slave(Secundário), a porta 953 é usada para programas externos se comunicarem com o BIND, por exemplo um DHCP que queira adicionar o nome dos hosts que receberam IP dentro da zona do DNS, lógico que isso só deve ser feito se estabelecermos uma relação de confiança entre eles, a fim de evitar que o DNS tenha dados sobrescritos por qualquer software.
O BIND:
O BIND foi criado por quatro estudantes de graduação, membros de um grupo de pesquisas em ciência da computação da Universidade de Berkeley e foi distribuído pela primeira vez com 4.3BSD. O programador Paul Vixie(criador da vixie-cron), enquanto trabalhava para a empresa DEC, foi o primeiro mantenedor do BIND. Atualmente o BIND é suportado e mantido pelo Internet Systems Consortium (ISC).
O desenvolvimento do BIND 9 foi realizado através de uma combinação de contratos comerciais e militares. A maioria das funcionalidades do BIND 9 eram promovidas por empresas fornecedoras de sistemas Unix que queriam garantir que o BIND se manteria competitivo com as ofertas de servidores DNS da Microsoft. Por exemplo, a extensão de segurança DNSSEC foi financiada pelos militares dos EUA que perceberam a importância da segurança para o servidor DNS.
Entendendo o BIND:
A configuração do BIND é feita em duas etapas:
– Primeiro criamos os domínios (zonas) dentro do arquivo named.conf, isso faz com o o BIND saiba que existe um ou mais domínios por quem ele deve responder, cria-se nesse arquivo as zonas diretas e reversa. As seções criadas no arquivo named.conf especificam que tipo de DNS estamos configurando (Master ou Slave), qual arquivo de database contém as máquinas que pertencem a cada domínio e alguns parâmetros de acesso ou segurança.
– Em segundo lugar devemos criar o arquivo da zona, o arquivo de database que contém os dados de autoridade sobre o domínio e que contém os nomes e IP de cada máquina que pertence a esse domínio, tanto da zona direta quanto da reversa, que é importante principalmente quando se trata de servidores de E-mail que verificam a existência de mapeamento inverso de IP (IP para nome) confirmando assim a identidade de um emissor de email.
Nos arquivos de configuração de zonas utilizamos o RR (Resource Record), ou seja registro de recursos, que são os registros de dados do DNS. São usados para descrever os hosts e recursos utilizados pelo DNS para uma determinada zona. Esses recursos são utilizados tanto para consulta de IP quanto para consulta de chaves, informações sobre o servidor, informações sobre o email, informações sobre dados adicionais, etc.
Segundo as especificações das RFC: 1035, 1876, 2535, 2672, 2782, 2930, 2931, 3445, 3596, 3658. Os principais RR são:
SOA – Geralmente o primeiro registro de uma zona, contém dados do domínio, email do responsável pelo domínio e os intervalos de tempo para manutenção da zona;
@ IN SOA 82c.bd8.myftpupload.com. adm.82c.bd8.myftpupload.com. ( 2011102001; 3600; 7200; 86400; 3600; )
NS – Mapeia os servidores de nome com autoridade desta zona, têm sempre um registro A associado a ele, muito importante para o funcionamento da zona;
@ IN NS ns1.82c.bd8.myftpupload.com.
MX – Especifica o servidor de E-mail associado ao domínio e qual a prioridade dele, quanto menor o número associado mais importante é o servidor, têm sempre um registro A associado a ele;
@ IN MX 10 mail.82c.bd8.myftpupload.com.
A – Especifica um endereço associado a um nome, em IPv4;
ftp IN A 172.16.1.254
AAAA – Especifica um endereço associado a um nome, em IPv6;
ftp IN AAAA 2002:0a14:01dc::1
PTR – Esse registro provê mapeamento indireto para registros do DNS, mapeia IP para nome;
254.1.16.172 IN PTR ftp.82c.bd8.myftpupload.com.
SRV – Esse registro permite a seleção de um servidor, muito usado pela Microsoft para informar os servidores do AD para os clientes. A RFC 1700 define alguns dos dados utilizados neste registro, ele informa: serviço, protocolo, nome, prioridade, importância, porta, destino;
_ldap._tcp._msdcs SRV 0 0 389 ldap.82c.bd8.myftpupload.com.
CNAME – Especifica um apelido para um host da rede;
pop3 IN CNAME mail
TXT – Esse registro contém uma informação qualquer que queira ser passada para aqueles que consultarem a zona;
82c.bd8.myftpupload.com. IN TXT “Site muito bom, só com Feras e tem um tal de Vagner também…”
SPF – Esse registro define o servidor de email autorizado a enviar mensagens pelo domínio. É consultado por servidores de email para confirmar autoridade sobre um domínio.
82c.bd8.myftpupload.com. IN TXT “v=spf1 include:vagnerfonseca.com.br -all”
DNAME – Mapeia um apelido para um domínio inteiro, permite que ao apontar para um determinado host seja redirecionado para toda uma subárvore de domínio;
vagnerfonseca.com.br. IN DNAME 82c.bd8.myftpupload.com.
HINFO – Um registro HINFO fornece informações sobre tipo de CPU e sistema operacional para um host do domínio. Nomes de CPU e SO podem ser obtidos em http://www.iana.org/protocols:
molde_mestre.82c.bd8.myftpupload.com. HINFO INTEL – 386 Linux
KEY – recurso de chave pública pública associada a uma zona. Utilizada pelo DNSSEC para autenticar os registros de recursos SIG recebidos de zonas assinadas, as informações são exibidas na ordem: protocolo, assinatura da chave, chave publica;
82c.bd8.myftpupload.com. IN DNSKEY 256 3 3 BOMbSz…
RRSIG – Registro de recurso assinado, utilizado em DNS com DNSSEC.
82c.bd8.myftpupload.com. 6 IN RRSIG A 5 3 60 20100723102502…
LOC – Esse registro fornece a possibilidade de especificar as informações sobre localização de computadores, sub-redes e redes no mundo. As opções são: latitude, longitude, altura, tamanho, precisão horizontal, precisão vertical;
82c.bd8.myftpupload.com IN LOC 43 01 04.012 S 19 32 01.210 W 832.40m 1.10m 11003.00m 11.00m
MINFO – Esse registro fornece uma lista de servidores para uma caixa de correio ou lista de correio, o primeiro ponto faz o papel de @ (arroba);
admin.82c.bd8.myftpupload.com. IN MINFO suporte.82c.bd8.myftpupload.com.
RP – Esse registro têm o e-mail da pessoa responsável pela zona ou host;
82c.bd8.myftpupload.com. IN RP dnsmaster.82c.bd8.myftpupload.com.
Os arquivos também podem incluir as diretivas de zona:
$ORIGIN – Guarda o nome da zona.
$INCLUDE – Inclui um arquivo dentro da zona.
$TTL – Tempo de vida das consultas de DNS.
Para maiores informações sobre outros recursos consulte as RFC mencionadas acima. Para informações sobre recursos mais utilizados em português consulte a rnp.br.
No próximo artigo falarei sobre como configurar um domínio usando o Bind e posteriormente em como melhorar a segurança do mesmo.
Não se esqueça de se inscrever no meu canal do Youtube nem de me seguir no Instagram.
Entre no nosso grupo do Telegram e vamos falar muito sobre Linux.
Aqui ainda não comenta sobre MX no bind, como seria ?