O DNS (Domain Name System) é um sistema constituído por uma robusta, hierárquica e distribuída base de dados, cujo propósito é criar mapeamentos entre nomes de hosts com endereços IP (e vice versa).

Esse conteúdo faz parte do curso “Servidor de Nomes de Domínio no Linux“

Esta base utilizada pelo sistema é indexada a partir de nomes de domínios, representados por caminhos lógicos baseados em uma árvore invertida, conhecida como Domain Name Space. No topo desta árvore encontramos uma única raiz (denominada root domain), gerenciada pela ICANN (Internet Corporation for Assigned Names and Numbers) e representada pelo ponto (.).

Com isto, os nomes de domínios são sempre lidos a partir desta raiz. Observe na figura a seguir uma representação parcial do Domain Name Space:

No root domain são encontrados diversos root servers, localizados em diferentes localizações do globo e classificados em 13 grandes autoridades. 

Aliás é importante associar a idéia de “domínio” a um nome (facilmente assimilado por humanos) que possui como objetivo básico ser utilizado para disponibilizar algum recurso pela grande rede. Estes também podem ser categorizados, variando de acordo com o seu nível.

Os Top-Level Domains são categorizados de formas diferentes pela IANA (Internet Assigned Numbers Authority). Por exemplo, alguns daqueles considerados genéricos (gTLD) são descritos a seguir:

• com: utilizado principalmente por organizações comerciais.
• edu: utilizado por instituições de ensino superior.
• org: originalmente era utilizado por organizações não comerciais, mas, ainda durante a década de 1990, essa restrição foi removida.
• net: originalmente era utilizado por organizações relacionadas a infraestrutura de redes, mas, ainda durante a década de 1990, também encontra-se disponível para ser utilizado por organizações comerciais.
• mil: utilizado por organizações militares.
• gov: Uso governamental.

A IANA também classifica os TLDs segundo os códigos utilizados por países – esses são conhecidos como Country-Code TLD (ou ccTLD). Os caracteres utilizados para identificar os países são baseados no padrão ISO 3166. Daí entram em cena o br (Brasil), fr (França), de (Alemanha), uk (Reino Unido), us (Estados Unidos) dentre outros.

A gestão do br, por exemplo, é realizada pela associação NIC.br (Núcleo de Informação e Coordenação do PontoBR), criada por membros do CGI.br (Comitê Gestor da Internet no Brasil).

Curiosidade: No início da Internet, os mapeamentos entre nomes e endereços IP eram mantidos pelo Network Information Center (NIC) em apenas um único arquivo – conhecido como HOST.TXT. Este era distribuído através do protocolo FTP aos outros hosts conectados à grande rede mundial.

Os subdomínios diretos dos TLDs são conhecidos como First Level Domains (FLDs), destinados a organizações, indivíduos etc. Por exemplo, o TLD “com” possui subdomínios como “google.com”, “globo.com”, “redhat.com”, “linuxmint.com” dentre outros.

Através do processo conhecido como delegação de autoridade, a gestão do FLDs poderá ser realizada pelos seus próprios mantenedores. Dito isto, a responsabilidade pela gestão do domínio “standford.edu” é delegada à própria Standford University, por exemplo. 

Dentro de um FLD, o seu mantenedor poderá definir hosts a serem localizados de forma própria. Por exemplo, geralmente os servidores web são acessíveis através da definição do “host” www – ou utilizar, por exemplo, um “host” ftp para disponibilizar este serviço no domínio (como ftp.exemplo.com) etc.

O sistema de DNS pode ser subdividido em zonas diferentes. Essas zonas são partes do Domain Name Space que são gerenciadas por organizações específicas. Além disso, cada zona poderá possuir muitos domínios – da mesma forma que, no mesmo servidor de DNS, várias zonas poderão co-existir.

Os servidores de nomes (nameservers) atuantes em uma zona, conhecem todas as informações a respeito desta, já que esses detalhes são obtidos a partir de arquivos locais ou vindos a partir de outro nameserver. Nesse contexto, dizemos que tratam-se de nameservers autoritativos (Authoritatives).

Veja na figura anterior que o domínio com possui, em seu topo, a zona de mesmo nome. Dessa forma, a gestão do subdomínio “redhat.com”, por exemplo, não é de responsabilidade do com, mas sim da própria equipe do Red Hat. Porém, os nameservers atuantes no domínio com sabem como obter informações do “redhat.com”, já que trata-se de um dos seus subdomínios.

Os nameservers autoritativos também poderão assumir comportamentos diferentes em uma zona. Aquele que é utilizado para armazenar os arquivos originais a respeito da zona, é identificado como Master (ou Primary). No processo de definição da zona neste nameserver, a zona também é especificada como “master”.

Devido a possuir os registros “master” da zona, este deverá sempre estar presente.

Já quando um nameserver obtém as informações sobre uma zona a partir do Master, dizemos que trata-se de um nameserver Slave. Dessa forma, esse mantém uma cópia idêntica dos dados contidos no primeiro. O processo de transferência dessas informações é conhecido Transferência entre Zonas.

No decorrer do curso conheceremos algumas variações que poderão ser assumidas por um nameserver. Aliás, esses também se diferenciam pela forma em que manipulam as requisições de consultas que lhes são enviadas pelos resolvedores (resolvers) do sistema operacional.

Ao ser configurado para manipular consultas iterativas (ou não-recursivas) o nameserver não se responsabiliza por oferecer uma resposta completa à consulta do cliente – ele devolve uma referência  de outros servidores de DNS que poderão ser usados na busca aplicada pelo resolver (caso o nameserver não possua a resposta para a pergunta, obviamente).

Um resolver é um programa ou rotina responsável por formular uma consulta de DNS (também conhecido como cliente de DNS).

Quando configurado para atender consultas recursivas o processo é inverso: o nameserver irá realizar todos os procedimentos até conseguir atender à requisição que lhe fôra passada. Neste cenário, ele poderá até mesmo consultar os outros servidores:

Alguns comandos oferecidos pelo Linux são bastante úteis ao trabalharmos com DNS. O primeiro a ser destacado é o nslookup. Apesar de ser considerado obsoleto, ainda costuma ser utilizado para efetuar consultas aos nameservers.

Por exemplo, se desejamos obter detalhes a respeito do domínio “centos.org“, lançamos o nslookup da seguinte forma:

[root@curso8 ~]#  nslookup centos.org
Server:           192.168.0.1
Address:          192.168.0.1#53

Non-authoritative answer:
Name:             centos.org
Address:          81.171.33.201

Name:             centos.org
Address:          81.171.33.202

Name:             centos.org
Address:          2001:4de0:aaae::201

Name:             centos.org
Address:          2001:4de0:aaae::202

Note que o campo Server indica o IP do servidor que foi utilizado para manipular o procedimento de consulta. Note também que os resultados exibidos são antecedidos pela string Non-authoritative answer. Isto significa que o nameserver local não possui qualquer autoridade sobre o nome de domínio que lhe fora passado – as informações exibidas foram obtidas a partir de nameservers externos.

Desta forma, podemos por exemplo informar agora ao comando nslookup para que use um servidor de DNS específico (ao contrário daquele disponível em /etc/resolv.conf):

[root@curso8 ~]#  nslookup centos.org 8.8.4.4
Server:         8.8.4.4
Address:        8.8.4.4#53

Non-authoritative answer:
Name:   centos.org
Address: 81.171.33.201

Name:   centos.org
Address: 81.171.33.202

Name:   centos.org
Address: 2001:4de0:aaae::201

Name:   centos.org
Address: 2001:4de0:aaae::202

Outro comando simples porém bastante objetivo é o host:

[root@curso8 ~]#  host centos.org
centos.org has address 81.171.33.201
centos.org has address 81.171.33.202
centos.org has IPv6 address 2001:4de0:aaae::202
centos.org has IPv6 address 2001:4de0:aaae::201
centos.org mail is handled by 10 mail.centos.org.

Note que, ao contrário do nslookup, por padrão o comando também exibe informações a respeito do servidor responsável por manipular e-mails no domínio especificado. Da mesma forma que o anterior, também podemos especificar um determinado servidor de DNS a ser consultado:

[root@curso8 ~]#  host centos.org 8.8.8.8
Using domain server:

Name: 8.8.8.8
Address: 8.8.8.8#53

Aliases:
centos.org has address 81.171.33.201
centos.org has address 81.171.33.202
centos.org has IPv6 address 2001:4de0:aaae::201
centos.org has IPv6 address 2001:4de0:aaae::202
centos.org mail is handled by 10 mail.centos.org.

Já o comando dig (Domain Information Groper) é aquele que apresenta as mais diversas possibilidades de uso. Bastante flexível e robusto, o comando é um dos mais utilizados em procedimentos de troubleshooting relacionados a DNS:

[root@curso8 ~]#  dig centos.org @8.4.4.4
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> centos.org @8.8.4.4
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30874
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;centos.org.                    IN      A
;; ANSWER SECTION:
centos.org.             576     IN      A       81.171.33.202
centos.org.             576     IN      A       81.171.33.201
;; Query time: 32 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Fri Jan 17 18:50:43 -03 2020
;; MSG SIZE  rcvd: 71

Note que o comando exibe no campo Query time o tempo total que a consulta demorou para ser concluída, além de também informar o servidor que foi utilizado no processo.

Veja também que, através da seção Authority Section, o comando informa os nomes dos servidores que foram utilizados para oferecer respostas autoritativas a respeito do domínio que foi informado. Na seção seguinte, são exibidos os seus endereços IP.

Iremos explorar bastante esses três comandos no decorrer do curso. A sugestão é que você abra agora mesmo as páginas de seus manuais e já inicie a leitura, já que isso eleverá bastante o seu desempenho para o exame.

O BIND (Berkeley Internet Name Domain) é a solução open source mais utilizada para implementar o serviço de DNS. Devido a sua importância, o LPI espera que você saiba manipulá-lo devidamente, atentando-se a conceitos-chave e aspectos configurativos. Nosso foco se recairá sobre a versão 9.x.

Entretanto, existem outras soluções que agem como alternativas ao BIND e que você precisa ter ciência no dia exame.

A primeira que poderá ser destacada é o djbdns, escrita por Daniel J. Bernstein para ir de encontro às brechas de segurança que ele encontrava no BIND. Na verdade, o djbdns é uma suíte composta por diferentes soluções, que inclui o tinydns e o dnscache. O projeto foi abandonado no início da década de 2000. Apesar disso, outros programas surgiram como um fork do djbdns, como é o caso do dbndns, do Debian.

O dnsmasq é outra solução bastante leve e de fácil configuração, utilizada como um nameserver Forwarder, ou seja, sua finalidade é encaminhar consultas de DNS a outros servidores de nome. Dito de outra forma, eles “terceirizam” o processo de resolução de nomes. O dnsmasq também consegue atuar como um servidor de DHCP. Por essas características, esta solução costuma ser bastante utilizada em roteadores.

O PowerDNS é outra solução modular open source bastante utilizada, lançada no início da década de 2000 sob a licença GPL. Apesar de original ser lançado como um software proprietário, posteriormente seus códigos se tornaram públicos. Além de trabalhar com os tradicionais arquivos de zona, esta solução também consegue interagir com sistemas de gerenciamento de bancos de dados complexos, como o Oracle, MySQL e MariaDB.

Como o nosso foco será o BIND, vamos utilizar um host CentOS para a sua instalação. Este host será identificado nos exemplos tanto pelo seu IP (192.168.0.15) quanto pelo seu hostname (LAP1). Sendo assim, vamos instalar o pacote “bind”:

[root@curso8 ~]#  yum install bind

O principal arquivo de configuração do BIND é identificado como named.conf, contendo as instruções globais aplicadas ao serviço.

No CentOS, ele encontra-se posicionado diretamente sob o diretório /etc. Como veremos mais a frente, no Debian este mesmo arquivo encontra-se sob /etc/bind. Atente-se para essa questão no dia do exame.

Por padrão, este arquivo é disponibilizado com diversos comentários – seja de apenas uma linha (iniciando com os caracteres “//” ou de um conjunto de linhas (iniciando com os caracteres “/*” e finalizando com “*/”. Vamos visualizar o seu conteúdo vindo por padrão:

options {

listen-on port 53 { 127.0.0.1; };

      listen-on-v6 port 53 { ::1; };

      directory       "/var/named";

      dump-file       "/var/named/data/cache_dump.db";

      statistics-file "/var/named/data/named_stats.txt";

      memstatistics-file "/var/named/data/named_mem_stats.txt";

      recursing-file  "/var/named/data/named.recursing";

secroots-file   "/var/named/data/named.secroots";

      allow-query     { localhost; };

recursion yes;

      dnssec-enable yes;

      dnssec-validation yes;

      bindkeys-file "/etc/named.root.key";

      managed-keys-directory "/var/named/dynamic";

      pid-file "/run/named/named.pid";

      session-keyfile "/run/named/session.key";

};

logging {

            channel default_debug {

            file "data/named.run";

            severity dynamic;

};

};

zone "." IN {

        type hint;

        file "named.ca";

};

include "/etc/named.rfc1912.zones";

include "/etc/named.root.key";

Ao manipularmos os nameservers no decorrer do curso, iremos estudar muitas das instruções que estão contidas neste arquivo.

---

Se você quer aumentar sua empregabilidade e se tornar um profissional especialista em Linux não deixe de completar nossa trilha “Profissional Especialista Linux” que cobre todo o conteúdo que você precisa para conquistar as certificações LPIC-1 e LPIC-2.

Confira os cursos da trilha.

Total de horas: 260h

Certificações LPIC-1 e LPIC-2

Provas: LPI 101-500, 102-500, 201-450, 202-450

Prova 101-500

Arquitetura do Sistema Linux (12h) | Instalação do Linux e Gerenciamento de Pacotes (12h) | Comandos GNU Linux e Unix (16h) |Dispositivos, Sistemas de Arquivos do Linux e FHS (12h)

Prova 102-500

Shells e Scripts do Shell para Linux (12h) | Interface de Usuários e Desktops Linux (8h) | Tarefas Administrativas no Linux (12h) | Serviços Essenciais do Sistema no Linux (12h) | Fundamentos de Redes para Linux (12h) |Segurança em Linux (12h)

Prova 201-450

Planejamento da Capacidade no Linux (8h) | O Kernel Linux (8h) | Inicialização do Sistema no Linux (8h) | Sistemas de Arquivos e Dispositivos no Linux (8h) | Administração Avançada de Dispositivos de Armazenamento no Linux (8h) | Configuração de Rede no Linux (12h) |Manutenção do Sistema Linux (8h)

Prova 202-450

Servidor de Nomes de Domínio no Linux (12h) | Serviços Web no Linux (12h) | Compartilhamento de Arquivos no Linux (12h) | Gerenciamento de Clientes de Rede no Linux (20h) | Serviços de Email no Linux (12h) | Segurança do Sistema no Linux (12h)