DNS – Domain Name System

Todo SysAdmin 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.

Vamos falar hoje como o serviço funciona e suas principais características.

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[bb] é 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 .cooperati 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 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 cooperati.com.br. adm.cooperati.com.br. ( 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.cooperati.com.br.

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.cooperati.com.br.

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

CNAME – Especifica um apelido para um host da rede;

pop3 IN CNAME mail

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;
cooperati.net.br. IN DNAME cooperati.com.br.

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.cooperati.com.br. HINFO INTEL[bb]-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;
cooperati.com.br. IN DNSKEY 256 3 3 BOMbSz…

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;
cooperati.com.br 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.cooperati.com.br. IN MINFO suporte.cooperati.com.br.

PTR – Esse registro provê mapeamento indireto para registros do DNS, mapeia IP para nome;
254.1.16.172 IN PTR ftp.cooperati.com.br.

RP – Esse registro têm o e-mail da pessoa responsável pela zona ou host;

www.cooperati.com.br. IN RP dnsmaster.cooperati.com.br.

SRV – Esse registro permite a seleção de um servidor, muito usado pela Microsoft[bb] 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.cooperati.com.br.

TXT – Esse registro contém uma informação qualquer que queira ser passada para aqueles que consultarem a zona;
cooperati.com.br. 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.
cooperati.com.br. IN TXT “v=spf1 include:cooperati.net.br -all”

RRSIG – Registro de recurso assinado, utilizado em DNS com DNSSEC.

www.cooperati.com.br. 6 IN RRSIG A 5 3 60 20100723102502…

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.

DNS – Criando Zonas no BIND

Continuando nosso assunto sobre DNS, vou mostrar no artigo de hoje sobre como criar domínios (zonas) no BIND e
colocar nossos domínios para funcionar.

Criaremos dois domínios e as máquinas que fazem parte dessas zonas.

Primeiro devemos instalar os pacotes necessários para o funcionamento do serviço, o nome do pacote é bind tanto em
distribuições baseadas em Debian quanto em Red Hat.

As diferenças entre as distribuições está na localização dos arquivos, as variáveis e comandos são os mesmos. As
diferenças são as seguintes:

Red Hat:
Script de inicialização: /etc/init.d/named
Arquivos de Configuração: /etc/named.conf (Opções e domínios) /etc/named.rfc1912.zones (zonas padrão)
Diretório de database de zonas: /var/named

Debian:
Script de inicialização: /etc/init.d/bind9
Arquivos de Configuração: /etc/bind/named.conf.options (opções) /etc/bind/named.conf.local (domínios)
/etc/named.conf.default.zones (zonas padrão)
Diretório de database de zonas: /var/cache/bind
Os domínios (direto e reverso) devem ser criados no arquivo /etc/named.conf (Red Hat) ou /etc/bind/named.conf.local
(Debian), e as máquinas de cada domínio devem ser criadas nos arquivos de database de cada distribuição. Nos arquivos
com nome named os caracteres de // são os comentários, nos arquivos db. o caracter de ; é o comentário.

No DNS master edite o arquivo named correspondente, usando como exemplo os domínios empresa.net e exemplo.net
(domínios que existem, mas aqui serão usados como exemplo) e sendo nossa rede externa 172.16.1.10 a 172.16.1.20(eu
sei que é um endereço inválido mas usaremos para exemplo), com o seguinte conteúdo ao final:

zone "empresa.net" {
type master;
file "db.empresa.net";
allow-transfer { 172.16.1.11; };
};

zone "exemplo.net" {
type master;
file "db.exemplo.net";
allow-transfer { 172.16.1.11; };
};

zone "1.16.172.in-addr.arpa" {
type master;
file "db.172.16.1";
allow-transfer { 172.16.1.11; };
};

Onde:
zone – é o nome do domínio que será criado neste servidor
type – tipo de servidor DNS (master ou slave)
file – arquivo de database desta zona
allow-transfer – diretiva que permite transferência do arquivo de zona para o servidor slave.

As zonas diretas devem ser criadas uma para cada domínio, mas como a zona reversa é baseada na rede onde os hosts
existem, assim sendo, podemos ter uma única zona reversa em nosso DNS atendendo a vários domínios, desde que os
hosts destes domínios estejam na mesma rede.

Para checar se não houve erro na configuração usaremos o comando named-checkconf:

root@debian# named-checkconf /etc/named.conf
ou
root@debian# named-checkconf /etc/bind/named.conf

Com os arquivos named devidamente configurados, devemos criar agora o database de cada zona e da reversa.
Criaremos nos respectivos diretórios de database os arquivos com os seguintes conteúdos:

db.empresa.net

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS

@ IN SOA ns1.empresa.net. dns-admin.empresa.net. (
2011102701 ; serial para controle de atualizações entre master e slave
3600 ; tempo de atualizações entre master e slave (refresh)
1800 ; tempo de atualizações caso o refresh falhe
604800 ; tempo de expiração do slave caso não se contate com o master
3600 ) ; tempo de vida das repostas negativas do servidor
@ IN NS ns1.empresa.net.
@ IN MX 10 mail.empresa.net.
ns1 IN A 172.16.1.10
ns2 IN A 172.16.1.11
mail IN A 172.16.1.12
ftp IN A 172.16.1.13
www IN A 172.16.1.20
db.exemplo.net

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS

@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net. (
2011102701 ; serial para controle de atualizações entre master e slave
3600 ; tempo de atualizações entre master e slave (refresh)
1800 ; tempo de atualizações caso o refresh falhe
604800 ; tempo de expiração do slave caso não se contate com o master
3600 ) ; tempo de vida das repostas negativas do servidor
@ IN NS ns1.exemplo.net.
@ IN MX 10 mail.exemplo.net.
ns1 IN A 172.16.1.10
ns2 IN A 172.16.1.11
mail IN A 172.16.1.12
ftp IN A 172.16.1.14
www IN A 172.16.1.20

db.172.16.1

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS

@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net. (
2011102701 ; serial para controle de atualizações entre master e slave
3600 ; tempo de atualizações entre master e slave (refresh)
1800 ; tempo de atualizações caso o refresh falhe
604800 ; tempo de expiração do slave caso não se contate com o master
3600 ) ; tempo de vida das repostas negativas do servidor
@ IN NS ns1.exemplo.net.
;empresa.net
10 IN PTR ns1.empresa.net.
11 IN PTR ns2.empresa.net.
12 IN PTR mail.empresa.net.
13 IN PTR ftp.empresa.net.
20 IN PTR www.empresa.net.

;exemplo.net
10 IN PTR ns1.exemplo.net.
11 IN PTR ns2.exemplo.net.
12 IN PTR mail.exemplo.net.
14 IN PTR ftp.exemplo.net.
20 IN PTR www.exemplo.net.

Assim teremos um arquivo para cada domínio direto e um arquivo para todos os reversos.

Vamos testar os arquivos com o seguinte comando (estando no diretório onde os arquivos foram criados):

root@debian# named-checkzone empresa.net db.empresa.net

root@debian# named-checkzone exemplo.net db.empresa.net

root@debian# named-checkzone 1.16.172.in-addr.arpa db.172.16.1

Se não houver nenhum erro, basta iniciar o serviço:

Em Red Hat:
root@debian# /etc/init.d/named restart

Em Debian:
root@debian# /etc/init.d/bind9 restart

Monitore por erros no log do sistema /var/log/syslog (Debian) ou /var/log/messages (Red Hat).

No slave faremos a seguinte configuração no arquivo named correspondente:

zone "empresa.net" {
type slave;
file "db.empresa.net";
masters { 172.16.1.10; };
};

zone "exemplo.net" {
type slave;
file "db.exemplo.net";
masters { 172.16.1.10; };
};

zone "1.16.172.in-addr.arpa" {
type slave;
file "db.172.16.1";
masters { 172.16.1.10; };
};

Assim ao reiniciar o serviço o slave irá procurar o master (172.16.1.10) e irá fazer download (porta 53 TCP) dos arquivos
db. existentes no master e se manterá sincronizado, verificando a cada ciclo de tempo (refresh) se houve atualizações nos
arquivos no master.

DNS – Criando Views no Bind

Continuando nossa série de artigos sobre o Bind, hoje vamos criar views em nosso DNS, views são seções onde
podemos controlar quem pode ver qual parte de nosso DNS, assim podemos ter uma seção interna e outra
externa respondendo no mesmo servidor DNS.

Lembrando o artigo da semana passada, tínhamos o seguinte conteúdo no nosso arquivo named :

zone "empresa.net" {
type master;
file "db.empresa.net";
allow-transfer { 172.16.1.11; };
};

zone "exemplo.net" {
type master;
file "db.exemplo.net";
allow-transfer { 172.16.1.11; };
};

zone "1.16.172.in-addr.arpa" {
type master;
file "db.172.16.1";
allow-transfer { 172.16.1.11; };
};

Não tínhamos uma zona de máquinas locais e nem separação de quem podia ver cada zona. Vamos criar agora
nossas views, lembrando que todas as seções existentes nos arquivos named devem estar em uma view.

Vamos criar nossa zona local acrescentando uma entrada no final do arquivo:

zone "empresa.local" {
type master;
file "db.empresa.local";
allow-transfer { none; };
};
Criaremos o conteúdo de nossa zona no arquivo db.empresa.local no diretório correto e com o seguinte
conteúdo:

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS

@ IN SOA ns1.empresa.local. dns-admin.empresa.local. (
2011102701 ; serial para controle de atualizações entre master e slave
3600 ; tempo de atualizações entre master e slave (refresh)
1800 ; tempo de atualizações caso o refresh falhe
604800 ; tempo de expiração do slave caso não se contate com o master
3600 ) ; tempo de vida das repostas negativas do servidor
@ IN NS ns1.empresa.local.
@ IN MX 10 mail.empresa.local.
ns1 IN A 192.168.1.10
mail IN A 192.168.1.12
ftp IN A 192.168.1.13
www IN A 192.168.1.20

Assim vamos criar as nossas views com o seguinte conteúdo:

view "externa" {
match-clients { any; };
recursion no;
zone "empresa.net" {
type master;
file "db.empresa.net";
allow-transfer { 172.16.1.11; };
};

zone "exemplo.net" {
type master;
file "db.exemplo.net";
allow-transfer { 172.16.1.11; };
};

zone "1.16.172.in-addr.arpa" {
type master;
file "db.172.16.1";
allow-transfer { 172.16.1.11; };
};
};

view "interna" {
match-clients { 192.168.1.0/24; };
recursion yes;
zone "empresa.local" {
type master;
file "db.empresa.local";
allow-transfer { none; };
};
};

Assim teremos uma view chamada “externa” que será de acesso a todos (any) e não permitirá consultas
recursivas (recursion no), ou seja qualquer um pode consultar sobre os domínios que estão dentro dessa view,
mas não podem consultar sobre nenhum outro domínio.

Já a view “interna” é de acesso apenas para clientes da rede 192.168.1.0/24 e permite que clientes dessa rede
consultem sobre outros domínios mesmo que não estejam hospedados nesse servidor.

DNS – Melhorando a Segurança com o Bind

Continuando nossa saga do DNS perfeito ;-), vamos melhorar um pouco a segurança do Servidor Bind com
alterações na seção de Options e fazendo o serviço ser executado enjaulado.
Temos agora um servidor funcional com separação por views, mas o serviço ainda pode ficar melhor, primeiro
vamos editar o arquivo named correspondente( /etc/named.conf no Red Hat ou /etc/bind/named.conf.options no
Debian) e dentro da seção options acrescentar as seguintes opções:

version “Não te interessa” ;

datasize 256M;

Assim esconderemos a versão do Bind, isso evita que descubram a versão do nosso servidor o utilizem algum
exploit que explore alguma vulnerabilidade do Bind, e limita o uso de memória RAM para 256 MB para que o
DNS quando em muito uso não esgote os recursos da máquina.

Vamos incrementar a segurança fazendo nosso DNS rodar em uma jaula. O concento de chroot, ou ser
executado em jaula, é de que o programa ao ser executado entenda que o diretório onde ele está sendo
executado é o raiz do sistema (/), assim ele “esquece” qualquer coisa que seja fora de seu diretório de
funcionamento. No Red Hat podemos na instalação já colocar o Bind em chroot.

Ao configurar o Bind para funcionar em chroot no diretório /var/named:

/
├── bin
├── boot
├── dev
├── etc
├── home
├── lib
├── lib32
├── lib64
├── lost+found
├── media
├── mnt
├── opt
├── proc
├── root
├── run
├── sbin
├── selinux
├── srv
├── sys
├── tmp
├── usr
└── var
├── bind
├── dev
├── etc
└── var
├── cache
└── run
└── bind
└── run

O Bind entende que apenas do diretório /var/bind para frente é que “existe” o sistema, como ele desconsidera o
resto, ainda que um atacante conseguisse derrubar o Bind e ganhasse acesso à área de memória não teria acesso
ao Sistema real, apenas ao que o Bind “acreditar” ser o sistema, ou seja, apenas do /var/bind para frente.

Vamos à criação da jaula:

Primeiro vamos parar o serviço:

root # /etc/init.d/bind9 stop

Depois edite o arquivo de opções do script de inicialização, e altere a variável OPTIONS de:
OPTIONS=”-u bind”
Para:
OPTIONS=”-u bind -t /var/bind”

Agora vamos criar os diretórios que o Bind vai precisa para funcionar dentro da jaula:

root# mkdir -p /var/bind/{dev,etc,var/{cache,run/bind/run}}

Criados os diretórios devemos mover as configurações que temos dentro do /etc e do /var/cache para o diretório
da jaula:
root# mv /etc/bind /var/bind/etc
root# mv /var/cache/bind /var/bind/var/cache/

Para continuar a manter o DNS nos mesmos diretórios que usávamos antes, vamos criar links simbólicos para
que os novos diretórios com os nomes dos diretórios antigos:
root# ln -s /var/bind/etc/bind /etc/bind
root# ln -s /var/bind/var/cache/bind /var/cache/bind

Agora vamos criar os dispositivos do dev para que o Bind possa descartar informações (/dev/null) e
sobrescrever dados com caracteres aleatórios (/dev/random):
root# mknod /var/bind/dev/null c 1 3
root# mknod /var/bind/dev/random c 1 8

Agora vamos corrigir as permissões e as propriedades dos diretórios para o usuário e grupo bind:
chmod 666 /var/bind/dev/null /var/bind/dev/random
chown -R bind:bind /var/bind/var/*
chown -R bind:bind /var/bind/etc/bind

Basta agora que editemos o servidor de Log para que possa capturar os logs gerados pelo Bind, já que mudamos
o diretório de funcionamento do serviço ele não usa mais o /dev/log, usa agora o /var/bind/dev/log. Edite o
arquivo /etc/rsyslog.conf e coloque esta linha abaixo da linha $ModLoad imuxsock:

$imuxsock /var/bind/dev/log

Feito isso basta reiniciar os serviços:

root# /etc/init.d/rsyslog restart
root# /etc/init.d/bind9 restart

Pronto temos agora um servidor que roda isolado no sistema, assim ele vai ser mais seguro mesmo em caso de
ataques ou invasões pelo serviço.

Testando o DNS

Para finalizar essa série de posts sobre DNS, vou mostrar alguns comandos para que você teste o seu e outros
servidores DNS. Com isso podemos verificar erros na configuração, na propagação ou erros de segurança.

WHOIS
O comando whois exibe informações sobre um determinado domínio ou IP. Permite não somente consultar a
respeito do proprietário, dns, data de um domínio/IP, como também verificar a origem de um endereço
descoberto em um possível ataque. O comando whois consulta o órgão ou empresa responsável de cada país
para exibir as informações.

Sintaxe do comando:
whois

Exemplo:
root:~# whois www.google.com.br
HOST
O comando host é utilizado para verificar o funcionamento de um domínio, ele mostra se a resolução de nomes
e apelidos está funcionando, seja na zona direta ou inversa.

Sintaxe do comando:
host

Exemplo:
root:~# host www.uol.com.br
root:~# host -t NS uol.com.br
root:~# host -t MX uol.com.br
root:~# host 200.147.36.15

NSLOOKUP
O comando nslookup faz pesquisa sobre domínios de internet de forma interativa (em um shell próprio) e não
interativa, faz consultas que podem ou não ter uma resposta de um DNS de autoridade sobre um domínio.

Sintaxe do comando:
nslookup

Consulta sobre o domínio ig.com.br através do seu servidor DNS, consulta não autoritativa.

root:~# nslookup ig.com.br

Consulta sobre o domínio ig.com.br através do próprio DNS do domínio ig.com.br, uma consulta autoritativa,
pois quem respondeu foi o próprio DNS do domínio.
root:~# nslookup ig.com.br dnssec1.ig.com.br

DIG
O comando dig permite fazer resoluções diretas de nomes ou indiretas de endereços, e retorna muito mais
informação do que o comando host. Mostra dados do cabeçalho dos arquivos db do DNS, mostra a query time
que é o tempo de duração da consulta, etc.

Sintaxe do comando:
dig

Exemplo:
Consultando informações de um DNS.
root:~# dig empresa.net

Consultando os servidores de DNS de um domínio:

root:~# dig NS empresa.net

Consultando apenas os servidores de DNS de um domínio:

root:~# dig NS empresa.net +noall +answer

Consultando os servidores MX de um domínio:

root:~# dig MX empresa.net

Consultando apenas os servidores MX de um domínio:

root:~# dig MX empresa.net +noall +answer

Consultando um apelido de um host:

root:~# dig CNAME www.empresa.net
Consultando uma chave pública do DNSSEC:
root:~# dig +dnssec ig.com.br DNSKEY @dnssec1.ig.com.br

Consultando a versão do bind:

root:~# dig @eliot.uol.com.br version.bind txt chaos

Consultando sobre o registro SOA:

root:~# dig ig.com.br +nssearch

Consultando sobre a vulnerabilidade de um domínio, onde (POOR é vulnerável e GREAT é com melhor
segurança):
root:~# dig +short @ns1.empresa.net porttest.dns-oarc.net TXT

Consultando a rota utilizada para resolver um nome:

root:~# dig www.google.com.br +trace

Atualizando a lista de Root Server

root:~# dig @a.root-servers.net. ns . > /etc/bind/db.root

Com esses comandos você pode consultar como está o registro de um domínio, quais as informações ele
fornece, quais os servidores descritos no DNS e como estão as informações de segurança.