O Sistema de Nomes de Domínio (DNS) faz com que a navegação de recursos em rede muito simples. Caso você não tenha uma rede pequena, será necessário estabelecer meios de saber qual endereço IP pertence a cada máquina, para que não haja confusão na identificação de cada uma delas. O DNS permite mapear os nomes aos endereços IP, então você pode se referir aos computadores pelos seus nomes (hostnames) e o DNS fará o trabalho de traduzir novamente o endereço IP.
DNS é uma daqueles serviços que virtualmente todo mundo em uma rede com dispositivos conectados usa, não importa se o usuário faça questão disso. Os provedores de serviços na Internet usam o DNS, tanto que é incomum acessar sites pelo seu endereço IP. Mas ele também é muito usado dentro de redes particulares das empresas.
Por exemplo, é muito mais conveniente acessar à uma impressora conectada na rede local por epson-repeccao do que lembrar o seu endereço IP, tal como 10.1.1.25. O que permite uma identificação mais fácil aos dispositivos conectados à rede.
O nome dos pacotes, como geralmente ocorre, são diferentes entre as distribuições. Nos sistemas baseados em Debian é bind9. As distribuições que se baseiam no sistema da Red Hat (Fedora e CentOS, por exemplo) o chamarão de bind. O nome BIND vem de Berkeley Internet Name Domain, criado na Universidade da California em Berkeley, e é o sistema de nomes de domínio mais popular. Se você está usando o CentOS é recomendado instalar o pacote bind-utils, já que ele contém o comando dig (domain information groper), que é útil em diversas situações. Nos sistemas da Red Hat e Debian, ele vem instalado por padrão.
O primeiro passo é garantir que o BIND esteja executando, o que pode ser feito com esse comando, no Debian:
# systemctl status bind9
As distribuições que se baseiam no sistema da Red Hat iniciam o daemon do bind automaticamente, caso esteja usando essas distribuições do Linux, execute os comandos abaixo apenas para garantir o início automático e também a execução na sessão atual:
# systemctl enable named
# systemctl start named
Com isso feito, você tem um servidor DNS operando. Não é necessário nenhuma configuração adicional para executá-lo corretamente, e agora é possível adicionar registros dos IPs e os respectivos nomes de outras máquinas.
Em primeiro lugar, checaremos o arquivo de configuração padrão. Os sistemas baseados no Debian armazenam o arquivo em /etc/bind/named.conf, os sistemas da Red Hat em /etc/named.conf. Apenas atentar para essas diferenças.
Para que haja a inclusão de novas configurações, para seguir as instruções desse tutorial, crie um arquivo vazio name.conf em /etc/bind:
include “/etc/bind/named.conf.options”;
include “/etc/bind/named.conf.local”;
Nos sistemas Red Hat será necessário criar o diretório, antes de criar o arquivo vazio:
# mkdir /etc/bind
E então criar /etc/bind/named.conf.options file e customizá-lo, nesse caso com o DNS da OpenDNS (208.67.222.222; 208.67.220.220), mas pode ser algum outro à sua escolha:
options {
forwarders {
208.67.222.222; 208.67.220.220;
};
};
Estarão sendo criadas opções com um bom tanto de código unido entre chaves, que então incluirá um conjunto adicional de chaves aonde serão identificados os endereços de redirecionamento. Já que o servidor DNS é usado para localizar recursos dentro de nossa rede interna, os blocos de redirecionamento indicam para onde serão enviadas requisições, e ele seja capaz de encontrar o que se realizar de buscas localmente. O servidor DNS irá igualmente continuar funcionando perfeitamente sem isso, já que na maioria dos casos ele irá buscar outro servidor DNS além do que está na cadeia. Mas configurar os redirecionadores permitirá forçar consultas externas aos DNS listados. Nesse exemplo são usados os servidores DNS do OpenDNS. No entanto, você pode escolher um da sua preferência. Alguns servidores DNS de boa performance podem ser encontrados em http://www.opennicproject.org, que é também uma boa escolha se você está ciente se levar em conta a privacidade e rastreamento.
O próximo arquivo é /etc/bind/named.conf.local, que contém o seguinte código:
zone “local.lan” IN {
type master; file “/etc/bind/net.local.lan”;
};
zone “81.10.10.in-appr.arpa” {
type master; notify no; file “/etc/bind/revp.10.1.96”;
};
zone “82.10.10.in-appr.arpa” {
type master; notify no; file “/etc/bind/revp.10.1.97”;
};
zone “83.10.10.in-appr.arpa” {
type master; notify no; file “/etc/bind/revp.10.1.98”;
};
zone “84.10.10.in-appr.arpa” {
type master; notify no; file “/etc/bind/revp.10.1.99”;
};
Nesse arquivo, iniciaremos a identificação de nosso nome de domínio. Aqui, eu escolhi local.lan. Como esse servidor não é autoritativo de qualquer coisa na Internet, esse nome é útil. Dentro desse bloco, estamos chamando outro arquivo, /etc/bind/net.local.lan. Na verdade, como pode ser visto, há diversos arquivos sendo chamados aqui (5 no total). O primeiro é a zona DNS principal, e ela é a mais importante dentre elas. Os seguintes são os arquivos aonde serão configuradas as buscas reversas de DNS. Essencialmente, o DNS nos permite não somente mapear hostnames aos endereços IP, mas pode também fazer o contrário: retornar mapas de endereços IP aos hostnames. Você não deve precisar de todos esses arquivos que foram criados no exemplo, pois estão sendo criados um arquivo de busca reversa para cada uma das 4 sub-redes. Se você não está criando múltiplas sub-redes, você só precisará criar um arquivo. O nome que convencionou-se usar é revp, seguido da porção do endereço IP na rede. Então, por exemplo, a busca reversa pela rede10.1.1.0 é revp.10.1.99. Os arquivos serão armazenados em /etc/bind.
Agora veremos o arquivo mestre, o arquivo /etc/bind/net.local.lan:
;
; dns zone for for local.lan
;
$TTL 1D
@ IN SOA local.lan. hostmaster.local.lan. (
201910151 ; serial
8H ; refresh
4H ; retry
4W ; expire
1D ) ; minimum
IN A 10.1.96.1
;
@ IN NS chewbaca.local.lan.
darth IN A 10.1.98.1
luke IN A 10.1.97.4
yoda IN A 10.1.96.4
chewbaca IN A 10.1.96.1
star CNAME yoda
;
; dns zone for for local.lan
;
Primeiro, foram posicionados alguns comentários genéricos, com linhas no início e um ponto e vírgula. Se uma linha iniciar com um ponto e vírgula, ela é ignorada pelo bind. Comentários são um bom método de armazenar notas ou eventos sem levar em conta a configuração. No entanto, comentários não são usados com frequência pelo bind. E após isso, será configurado o Tempo de Vida (TTL) para um dia:
$TTL 1D
Esse valor controla o quanto os outros servidores DNS serão capazes de armazenar cada registro. Após esse período, quaisquer servidores que tenham armazenado um desses registros devem descartá-los. Para o propósito de configurar um servidor DNS interno, esse valor não interfere tanto. No entanto, ele é extremamente importante ao usar múltiplos servidores DNS. Um exemplo de porquê o valor de TTL pode se provar útil é alterar um endereço de registro para um IP diferente. Suponha que você está fazendo a troca do provedor de e-mail. Nesse caso você terá que trocar o e-mail adequadamente. No entanto, antes de você determinar essa mudança, você deve reduzir o TTL, para um tempo menor, tal como uma hora, e fazer isso antes de realizar a troca. Então, os servidores são forçados a descartar essa zona e atualizá-lo, causando que a mudança seja aplicada o mais rápido possível nos servidores. Quando tiver terminado, você poderá mudá-lo novamente. Com a seguinte linha identifica-se um Início de Autoridade (SOA):
@ IN SOA local.lan. hostmaster.local.lan. (
Nesse caso, estamos identificando que esse servidor DNS tem autoridade sobre o domínio local.lan, que hostmaster.local.lan é o responsável. Embora não pareça, hostmaster.local.lan é um endereço de -e-mail no formato que o bind escolher. No entanto, é óbvio que é um endereço fake , o que não importa para o servidor DNS desse tutorial. No final da linha, estará sendo aberto um bloco de configuração com parênteses. A seguinte linha representa o serial, e é um conceito importante a se entender para que o servidor DNS opere adequadamente:
201910151 ; serial
Cada vez que o daemon do bind é reiniciado, ele irá recarregar o arquivo. Mas quando isso é feito, o númeo de série é a primeira coisa a ser examinada. Se ele for o mesmo, ele não terá carregado qualquer atualização. Mas quando ele for alterado, é o primeiro a ser examinado já que algo nos arquivos de configuração das zonas. Nesse exemplo, a data atual está sendo usada sem hífens ou espaços. O último dígito é somente um número de revisão para aquele dia, se o arquivo for alterado múltiplas vezes em um dia. Você pode usar qualquer esquema que prefira. Mas usar a data é uma forma bem comum de esquema. Sem levar em conta o formato que você usa, sempre garanta que o o incremento ocorra no serial, toda vez que a mudança ocorrer. Assim evita frustações de não saber a razão pela qual novos registros foram criados.
8H ; refresh
4H ; retry
4W ; expire
1D ) ; minimum
Esses valores determinam quantas vezes as checagens de atualização serão requisitadas aos servidores-escravo DNS. O primeiro valor exige a atualização dos registros de zona do servidor-mestre a cada 8 horas. Ao invés de realizar novas tentativas, os servidores-escravo serão configurados para considerar que ocorreu um problema na tentativa de conexão, e chequem novamente após um período de tempo. E por último, configurou-se o período mínimo de registros de zona por dia, e o máximo a cada 4 semanas. Configurando o servidor-escravo DNS está além do objetivo desse tutorial, e ter essa configuração concluída posteriormente não causa dano algum, caso decida configurá-los.
@ IN NS chewbaca.local.lan.
Aqui, estamos identificando esse nome do servidor. Nesse exemplo está sendo chamado de hermes e o seu nome de domínio completo échewbaca.local.lan.
yoda IN A 10.1.1.30
chewbaca IN A 10.1.96.1
Finalmente, nesse exemplo, quadro registro de endereços são mostrados. Isso basicamente significa que qualquer ver que alguém está olhando para um dessas máquinas, a requisição é mapeada para o nome de domínio listado. Esses podem estar entre múltiplas sub-redes ou uma única sub-rede. Nesse exemplo, essas máquina estão em diferentes sub-redes:
star CNAME yoda
A linha final dessa configuração contém um registro de Nome Canônico (CNAME). Basicamente, isso nos permite referir-se ao servidor por outro nome. Nesse exemplo, star é também usado para um software também conhecido por yoda, e o registro CNAME foi desenvolvido para isso. Desse modo, se alguém tentar acessar yoda.local.lan ou star.local.lan, essa requisição poderia resolver o mesmo endereço (10.1.1.30). Um registro CNAME pode ser muito útil se um servidor único provê mais que um serviço para a rede.
Anteriormente, foram realizadas quadro consultas reversas a registros /etc/bind/revp.10.1.96, /etc/bind/revp.10.1.97, /etc/bind/revp.10.1.98, e revp.10.1.99. Abaixo um exemplo de configuração para a rede 10.10.96.0:
$TTL 1D
@ IN SOA chewbaca.local.lan. hostmaster.local.lan. (
201910151 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
;
@ NS chewbaca.local.lan.
1 PTR chewbaca.local.lan.
3 PTR galaxy.local.lan.
4 PTR yoda.local.lan.
Com essa configuração, iniciam-se os registros de autoridade, assim como uma zona mestre, e tendo um número serial. A mesma ideia se aplica aqui. Seja qual for a atualização do registro (incluindo registros de consulta reversos), você deverá atualizar o número serial do arquivo. O início da autoridade opera como antes, sem novidades. O que difere nesse arquivo é como as máquinas serão chamadas. Ao invés de chamar por um número IP inteiro, será identificado apenas o último octeto já que o arquivo inteiro é dedicado a buscas reversas da rede 10.1.96.0. Para cada uma das sub-redes, você terá que criar um arquivo similar. No exemplo dado nessa configuração há quatro sub-redes, mas não é necessário tantas assim. Isso foi provido de forma a prover um exemplo de como separar sub-redes distintas, conforme for necessário ser feito.
Com essa configuração finalizada, é possível reiniciar o serviço bind no servidor DNS e testá-lo.
Para os sistemas Debian, use o seguinte comando:
# systemctl restart bind9
Para os sistemas da Red Hat, use o seguinte comando:
# systemctl restart named
Pelo comando dig é possível testar o servidor DNS, já que ele requisita informações do servidor DNS:
dig myhostname.local.lan
Se o servidor DNS retornar a mensagem SERVER na saída, então o seu servidor está funcionando coretamente. Se isso não ocorrer algo não foi configurado corretamente.
Com essas instruções a configuração de nós adicionais e outros registros podem ser realizados adequadamente dentro do servidor DNS. Asegure que os hostnames e endereços IPs contidos dentro dos arquivos de configuração em relação àqueles que correspondam aos da sua rede. Adicionalmente, se certifique que você ligou suas sub-redes, ou remova menções à outras sub-redes se você não tem alguma. Para estar seguro, ao invés de copiar a configuração diretamente desse tutorial, é mais interessante digitar manualmente, dependendo o caso.
Dicando Software 