19.11. DNS

19.11.1. Visão Geral

O FreeBSD usa, por padrão, uma versão do BIND (Berkeley Internet Name Domain), que é a implementação mais comum do protocolo DNS. O DNS é o protocolo pelo qual nomes são mapeados para endereços IP e vice-versa. Por exemplo, uma pergunta por www.FreeBSD.org receberá uma resposta com o endereço IP do servidor web do Projeto FreeBSD, ao passo que, uma pergunta por ftp.FreeBSD.org retornará o endereço IP da máquina FTP correspondente. Da mesma forma, o oposto pode ocorrer. Uma pergunta pelo endereço IP pode resolver seu nome de sistema. Não é necessário rodar um servidor de nomes para efetuar pesquisas DNS em um sistema.

O DNS é coordenado através da Internet através de um sistema um tanto complexo de servidores de nome raiz autoritativos, e outros servidores de nome de menor escala que abrigam e fazem cache de informações de domínios individuais.

Este documento refere-se ao BIND 8.x, como ele é a versão estável usada no FreeBSD. O BIND 9.x no FreeBSD pode ser instalado através do port net/bind9.

As RFC1034 e RFC1035 ditam o protocolo DNS.

Atualmente, o BIND é mantido pelo Internet Software Consortium (www.isc.org).

19.11.2. Terminologia

Para compreender este documento, alguns termos relativos ao DNS precisam ser entendidos.

Exemplos de zonas:

• . é a zona raiz

• org. é a zona sob a zona raiz

• exemplo.org é a zona sob a zona org.

• foo.exemplo.org. é um subdomínio, uma zona sob a zona exemplo.org.

• 1.2.3.in-addr.arpa é a zona referenciando todos os endereços IP que recaem sob o espaço IP 3.2.1.*

Como se pode ver, a parte mais específica de um nome de sistema aparece à sua esquerda. Por exemplo, exemplo.org é mais específico que org., como org. é mais específico que a zona raiz. O esboço de cada parte de um nome de sistema é muito parecido com um sistema de arquivos: o diretório /dev fica sob o raiz, e assim por diante.

19.11.3. Razões para Rodar um Servidor de Nome

Servidores de nome normalmente aparecem em duas formas: como servidor de nome autoritativo e, como um servidor de nome para fazer cache.

Um servidor de nome autoritativo é necessário quando:

• alguém quer servir informação DNS para o mundo, respondendo de forma autoritativa a pesquisas.

• um domínio, como exemplo.org, é registrado e endereços IP precisam ser designados a nomes de sistemas sob ele.

• um bloco de endereços IP requerem entradas DNS reversas (IP para nomes de sistema).

• um servidor de nome de segurança, chamado de escravo, precisa responder a pesquisas quando o primário está fora do ar ou inacessível.

Um servidor de nome para fazer cache é necessário quando:

• um servidor DNS local pode fazer cache e responder mais rapidamente do que pesquisar em um servidor de nome externo.

• uma redução no tráfego de rede de uma forma geral é desejada (o tráfego DNS foi contabilizado como 5% ou mais do tráfego total da Internet).

Quando alguém pesquisa por www.FreeBSD.org, o resolver normalmente pesquisa o servidor de nomes do provedor de nível superior e recupera a resposta. Com um servidor DNS local fazendo cache, a pesquisa precisa ser feita uma vez para o mundo exterior. Cada pesquisa adicional não vai precisar buscar fora da rede local, uma vez que há uma cópia local da informação no cache.

19.11.4. Como Funciona

No FreeBSD, o daemon BIND é chamado named por razões óbvias.

Arquivos de zona normalmente pertencem ao diretório /etc/namedb, e contém a informação de zona DNS fornecida pelo servidor de nomes.

19.11.5. Iniciando o BIND

Uma vez que o BIND é instalado por padrão, configurá-lo é relativamente simples.

Para assegurar que o daemon named é executado durante a inicialização, coloque as seguintes modificações no /etc/rc.conf:

named_enable="YES"

Para iniciar o daemon manualmente (após configurá-lo)

# ndc start

19.11.6. Arquivos de Configuração

# cd /etc/namedb
# sh make-localhost

// $FreeBSD$
//
// Consulte a página de manual do named(8) para detalhes.  Se você
// alguma vez for configurar um servidor primário, certifique-se de
// que compreendeu os detalhes cabeludos de como o DNS está
// funcionando.  Mesmo com simples enganos, você pode quebrar a
// conectividade de grupos atingidos, ou causar enormes quantidades de
// tráfego inútil na Internet.

options {
    directory "/etc/namedb";

// Adicionalmente à cláusula "forwarders", você pode forçar seu
// servidor de nomes a nunca iniciar pesquisas por conta própria, mas
// sempre consultar somente seus despachantes, ativando a linha
// abaixo:
//
//      forward only;

// Se você tem um servidor DNS por perto em seu provedor de acesso,
// entre seu endereço IP aqui, e ative a linha abaixo.  Isto fará com
// que você se beneficie de seu cache, reduzindo o tráfego DNS na
// Internet em geral.

/*
    forwarders {
        127.0.0.1;
    };
*/

   /*
     * Se existe um firewall entre você e os servidores de nome
     * com os quais deseja falar, você pode precisar remover os
     * comentários da diretiva query-source abaixo.  Versões
     * anteriores do BIND sempre fizeram pesquisas usando a porta
     * 53, mas o BIND 8.1 usa uma porta não priviliegada por
     * padrão.
     */
    // query-source address * port 53;

    /*
     * se estiver executando em um ambiente restrito (sandbox),
     * você pode ter que especificar uma localização diferente
     * para o arquivo de despejo de memória (dumpfile).
     */
    // dump-file "s/named_dump.db";
};

// Nota: os comandos a seguir serão suportados em uma versão futura.
/*
host { any; } {
    topology {
        127.0.0.0/8;
    };
};
*/

// Configurar secundários é muito mais fácil e um esboço da
// configuração é explicado a seguir.
//
// Se você ativar um servidor de nome local, não esqueça de colocar o
// 127.0.0.1 no seu /etc/resolv.conf para que este servidor seja
// consultado primeiro.
// Também certifique-se de ativá-lo no /etc/rc.conf.

zone "." {
    type hint;
    file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
    type master;
    file "localhost.rev";
};

zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
    type master;
    file "localhost.rev";
};

// Nota: Não use os endereços IP abaixo, eles são apenas exemplos e
// servem somente para propósitos de demonstração e documentação!
//
// Exemplo de entradas de configuração de servidor secundário.  Pode ser
// interessante se tornar o secundário pelo menos da zona de seu
// próprio domínio.  Solicite a seu administrador de rede o
// endereço IP do servidor primário responsável.
//
// Nunca esqueça de incluir a zona de busca reversa (IN-ADDR.ARPA)!
// (Estes são os primeiros bytes do respectivo endereço IP, em ordem
// invertida, com ".IN-ADDR.ARPA" anexado.)
//
// Entretanto, antes de iniciar a configurar a zona primária, é bom ter
// compreendido completamente como o DNS e o BIND trabalham.  Algumas
// vezes, existem ciladas ocultas.  Em comparação, é mais fácil
// configurar um secundário.
//
// NB: Não ative cegamente os exemplos abaixo. :-)  Ao invés, use
// nomes e endereços reais.
//
// NOTA!!! O FreeBSD roda bind em uma sandbox (veja named_flags no
// rc.conf).  O diretório contendo as zonas secundárias devem possuir
// acesso de gravação permitido para o bind.  É sugerida a seguinte
// seqüência:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s

/*
zone "exemplo.com" {
    type slave;
    file "s/exemplo.com.bak";
    masters {
        192.168.1.1;
    };
};

zone "0.168.192.in-addr.arpa" {
    type slave;
    file "s/0.168.192.in-addr.arpa.bak";
    masters {
        192.168.1.1;
    };
};
*/

zone "exemplo.org" {
    type master;
    file "exemplo.org";
};

zone "exemplo.org" {
    type slave;
    file "exemplo.org";
};

$TTL 3600

exemplo.org.  IN SOA ns1.exemplo.org.  admin.exemplo.org. (
            5    ; Serial
            10800    ; Refresh
            3600     ; Retry
            604800   ; Expire
            86400 )  ; Minimum TTL

; Servidores DNS
@            IN NS      ns1.exemplo.org.
@            IN NS      ns2.exemplo.org.

; Nomes de Máquinas
localhost    IN A       127.0.0.1
ns1      IN A       3.2.1.2
ns2      IN A       3.2.1.3
mail         IN A       3.2.1.10
@        IN A       3.2.1.30

; Apelidos (aliases)
www      IN CNAME   @

; Registro MX (MX Record)
@        IN MX  10  mail.exemplo.org.

nomedoregistro      IN tipodoregistro  valor

exemplo.org.  IN SOA ns1.exemplo.org.  admin.exemplo.org. (
            5    ; Serial
            10800    ; Atualizar após 3 horas
            3600     ; Tentar novamente após 1 hora
            604800   ; Expirar após 1 semana
            86400 )  ; TTL mínimo de 1 dia

@       IN NS     ns1.exemplo.org.

localhost    IN A    127.0.0.1
ns1      IN A    3.2.1.2
ns2      IN A    3.2.1.3
mail         IN A    3.2.1.10
@        IN A    3.2.1.30

www         IN CNAME   @

@         IN MX   10      mail.exemplo.org.

$TTL 3600

1.2.3.in-addr.arpa.  IN SOA ns1.exemplo.org.  admin.exemplo.org. (
            5     ; Serial
            10800     ; Refresh
            3600      ; Retry
            604800    ; Expire
            3600 )    ; Minimum

@       IN NS   ns1.exemplo.org.
@       IN NS   ns2.exemplo.org.

2       IN PTR  ns1.exemplo.org.
3       IN PTR  ns2.exemplo.org.
10      IN PTR  mail.exemplo.org.
30      IN PTR  exemplo.org.

19.11.7. Servidor Cache de Nomes

Um servidor de nome para cache é um tipo de servidor de nome que não é autoritativo autoritativo para nenhuma zona. Ele simplesmente efetua buscas por conta própria e se recorda delas para uso futuro. Para configurar um, apenas configure o servidor de nome normalmente, omitindo quaisquer inclusões de zonas.

19.11.8. Rodando o named Restrito a Um Diretório (Sandbox)

Para segurança adicional, você pode querer rodar o named(8) com um usuário não privilegiado e configurá-lo para fazer chroot(8) dentro de um diretório restrito (sandbox). Isto torna tudo fora da sandbox inacessível para o daemon named. Caso o named seja atacado, isto ajudará a reduzir os danos que podem ser causados. Por padrão, o FreeBSD tem um usuário e um grupo chamados bind, planejado para este uso.

Uma vez que o named não será capaz de acessar nada fora da sandbox, (como bibliotecas compartilhadas, sockets de logs e assim por diante), há uma série de passos que devem ser seguidos para permitir o correto funcionamento do named. Na seguinte lista de verificação, é assumido que o caminho para a sandbox é /etc/namedb e que você não fez modificações prévias ao conteúdo deste diretório. Execute os seguintes passos como usuário root.

• Crie todos os diretórios que o named espera encontrar:

  # cd /etc/namedb
  # mkdir -p bin dev etc var/tmp var/run master slave
  # chown bind:bind slave var/*
  

  

  O named precisa de acesso para gravação somente nestes diretórios, então é tudo que vamos lhe fornecer.

• Rearrume e crie uma zona básica e arquivos de configuração:

  # cp /etc/localtime etc
  # mv named.conf etc && ln -sf etc/named.conf
  # mv named.root master
  # sh make-localhost && mv localhost.rev localhost-v6.rev master
  # cat > master/named.localhost
  $ORIGIN localhost.
  $TTL 6h
  @   IN  SOA localhost.  postmaster.localhost. (
              1   ; serial
              3600    ; refresh
              1800    ; retry
              604800  ; expiration
              3600 )  ; minimum
      IN  NS  localhost.
      IN  A   127.0.0.1
  ^D
  

  

  Isto permite ao named registrar a hora correta ao syslogd(8)

• Se você estiver rodando a versão de FreeBSD anterior à 4.9-RELEASE, construa uma cópia estaticamente compilada do named-xfer e a copie na sandbox:

  # cd /usr/src/lib/libisc
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/lib/libbind
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/libexec/named-xfer
  # make cleandir && make cleandir && make depend && make NOSHARED=yes all
  # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
  

  Após a instalação do seu named-xfer compilado estaticamente, uma faxina se faz necessária, para evitar deixar cópias envelhecidas de bibliotecas ou programas na sua árvore de fontes:

  # cd /usr/src/lib/libisc
  # make cleandir
  # cd /usr/src/lib/libbind
  # make cleandir
  # cd /usr/src/libexec/named-xfer
  # make cleandir
  

  

  Já houveram relatos de que este passo pode ocasionalmente falhar. Se isto acontecer com você, então use o comando:

  # cd /usr/src && make cleandir && make cleandir
  

  and delete your /usr/obj tree:

  # rm -fr /usr/obj && mkdir /usr/obj
  

  Isto limpará quaisquer ``restos'' de sua árvore de fontes, e, tentar novamente os passos acima deverá funcionar.

  Se você está rodando o FreeBSD versão 4.9-RELEASE ou posterior, então a cópia do named-xfer em /usr/libexec é compilada estaticamente por padrão, e você pode simplesmente usar cp(1) para copiá-la dentro da sua sandbox.

• Crie um dev/null o qual o named possa ver e escrever:

  # cd /etc/namedb/dev && mknod null c 2 2
  # chmod 666 null
  

• Crie um link simbólico /var/run/ndc para /etc/namedb/var/run/ndc:

  # ln -sf /etc/namedb/var/run/ndc /var/run/ndc
  

  Nota: Isto evita, de forma simples, ter que especificar a opção -c para o ndc(8) cada vez que você executá-lo. Uma vez que o conteúdo do /var/run são apagados na inicialização (boot), se isto for algo que você considera útil você pode adicionar este comando ao crontab do root, usando a opção @reboot. Veja crontab(5) para mais informações a este respeito.

• Configure syslogd(8) para criar mais um socket de log no qual o named pode gravar. Para isto, adicione -l /etc/namedb/dev/log na variável syslogd_flags no /etc/rc.conf.

• Configure para que o named seja inicializado e restrinja-se com chroot à sandbox adicionando o seguinte ao /etc/rc.conf:

  named_enable="YES"
  named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
  

  Nota: Note que o arquivo de configuração /etc/named.conf é declarado por um caminho completo relativo à sandbox, p.ex.: na linha acima, o arquivo referenciado é, na verdade, /etc/namedb/etc/named.conf.

O próximo passo é editar o /etc/namedb/etc/named.conf de forma que o named saiba quais zonas carregar e onde encontrá-las no disco. A seguir, um exemplo comentado (qualquer coisa não especificamente comentada aqui não é diferente da configuração de um servidor DNS que não está rodando dentro de uma sandbox):

options {
    directory "/";
    named-xfer "/bin/named-xfer";
    version "";     // Não revele a versão do BIND
    query-source address * port 53;
};
// socket de controle ndc
controls {
    unix "/var/run/ndc" perm 0600 owner 0 group 0;
};
// Zones a seguir:
zone "localhost" IN {
    type master;
    file "master/named.localhost";
    allow-transfer { localhost; };
    notify no;
};
zone "0.0.127.in-addr.arpa" IN {
    type master;
    file "master/localhost.rev";
    allow-transfer { localhost; };
    notify no;
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
    type master;
    file "master/localhost-v6.rev";
    allow-transfer { localhost; };
    notify no;
};
zone "." IN {
    type hint;
    file "master/named.root";
};
zone "private.example.net" in {
    type master;
    file "master/private.example.net.db";
    allow-transfer { 192.168.10.0/24; };
};
zone "10.168.192.in-addr.arpa" in {
    type slave;
    masters { 192.168.10.2; };
    file "slave/192.168.10.db";
};

Após completar os passos acima, reinicie seu servidor ou o syslogd(8) e inicie o named(8), certificando-se de usar as novas opções especificadas em syslogd_flags e named_flags. Você agora deve estar rodando uma cópia restrita do named!

19.11.9. Segurança

Apesar do BIND ser a implementação mais comum do DNS, sempre há a questão da segurança. Furos possíveis e exploráveis de segurança são encontrados de vez em quando.

É uma boa idéia assinar CERT e freebsd-security-notifications para se manter atualizado sobre as atuais questões de segurança na Internet e do FreeBSD.

19.11.10. Leitura adicional

Páginas de manual do BIND/named: ndc(8) named(8) named.conf(5)

• Página Oficial do ISC Bind

• BIND FAQ

• O'Reilly DNS and BIND 4th Edition

• RFC1034 - Domain Names - Concepts and Facilities

• RFC1035 - Domain Names - Implementation and Specification