Tag: dns

Escolha de um servidor de DNS pode trazer algumas vantagens. A Cloudflare, por exemplo, oferece publicamente os endereços de servidores de DNS 1.1.1.2, que filtra domínios com maior potencial de malware, e o 1.1.1.3, que adicionalmente filtra domínios de conteúdo adulto. O Pi-hole é um servidor de DNS instalável em dispositivos Raspberry Pi que bloqueia anúncios na sua rede.

Ter um servidor de DNS pode resolver alguns problemas ou trazer algumas melhorias, como direcionar pra serviços internos e filtrar o que for desejado de forma flexível. Duas situações específicas tornam isso interessante no meu ambiente:

• Mesmo quando um computador está na mesma rede que o servidor Nextcloud, o DNS resolve para o IP do proxy reverso, hospedado em uma VPS, de forma que tráfego sai da rede local, passa pela internet e retorna para o servidor na mesma rede local. Isso é lento e ineficiente comparado ao acesso direto via IP privado, o que pode ser chato para a transferência de muitos arquivos como pode ocorrer no meu script de backup com Rclone.
• Eventualmente em ambientes de testes pode ser necessário fazer o acesso para configuração de uma plataforma interna através do nome de domínio a ser utilizado externamente, e o registro de DNS externo não pode ser alterado ou a aplicação ainda não pode ser exposta à internet.

Em ambos os casos, um servidor de DNS com registros apontando para o IP privado da máquina na rede local resolveria o problema.

Berkeley Internet Name Domain, conhecido como BIND é o servidor de DNS mais utilizado na internet, especialmente em ambientes tipo Unix, e tem uma configuração relativamente simples. A instalação em um servidor Debian 13 fica:

# apt install bind9

Para verificar que o serviço está em habilitado e em execução:

$ systemctl status bind9

Por padrão ele é configurado no modo recursivo, em que ele, quando ele não tem um registro de DNS, ele busca os registros de DNS em outros servidores e devolve a resposta. Você pode verificar isso com o comando do tipo:

$ nslookup duckduckgo.com 127.0.0.1

E ele vai retornar o endereço de IP do site. Essa é uma configuração não muito boa de se ter por padrão em um servidor exposto publicamente porque permite que o servidor seja utilizado de forma maliciosa em ataques de DDoS por amplificação de DNS. Configurações adicionais de firewall e limitação de taxa de requisições devem ser feitas.

Alternativamente, ele pode ser utilizado apenas no modo autoritativo, de forma que ele só resolve os endereços que ele hospeda. Essa configuração pode ser feita no arquivo /etc/bind/named.conf.options, adicionando o seguinte:

options {
    recursion no;
};

Uma boa configuração a se fazer também é adicionar a linha “allow-transfer { none; };” para evitar que qualquer servidor atue como secundário e possa baixar todas as configurações de zonas.

options {
    recursion no;
    allow-transfer { none; };
};

Após reiniciar o serviço, verifique que ele não consegue mais resolver domínios sem zona configurada, com o nslookup obtendo resposta REFUSED ao tentar.

Para adicionar uma zona autoritativa, basta incluí-la no /etc/bind/named.conf.local.

zone "exemplo.com" {
        type master;
        file "/etc/bind/exemplo.com";
};

E configurá-la no arquivo especificado – neste caso, /etc/bind/exemplo.com.

; /etc/bind/exemplo.com
; Time to live: tempo máximo em que outros servidores devem manter essa zona em cache
$TTL 3600

; @ - representa a própria zona de DNS
; IN - classe "Internet" - padrão para TCP/IP
; SOA - tipo de registro - Start of Authority
; ns0.exemplo.com. - MNAME - nameserver primário
; RNAME - administrator email address

@       IN SOA  ns0.exemplo.com. oliveira.d.c.outlook.com. (
                2026090603 ; serial: determina o número de versão da zona. nameservers secundários usam esse número pra determinar se a zona de dns foi alterada
                7200       ; refresh: tempo em segundos em que o nameserver secundário deve verificar a zona no primário (este servidor)
                540        ; retry: intervalo em que o secundário deve tentar caso tenha falha em alcançar o primário
                604800     ; expire: caso o secundário não consiga alcançar o primério durante esse intervalo, a zona é excluida
                3600       ; negative caching: TTL do cache de um registro negativo (NXDOMAIN)
                )

; nameservers autoritativos
@       IN NS   ns0.exemplo.com.
;@       IN NS   ns1.exemplo.com.

; sites
@       IN   A        192.168.11.11
zabbix  IN   A        192.168.11.10
torre1  IN   A        192.168.11.9
torre2  IN   CNAME    torre1.exemplo.com.
www     IN   CNAME    exemplo.com.

; endereço dos nameservers
ns0     IN   A        192.168.11.3
;ns1     IN   A        192.168.11.4

Repare que os nameservers são resolvidos pela própria zona. Isso pode parecer problemático por ser uma dependência circular, mas isso funciona também em servidores de DNS externos, porque esse problema é resolvido pelo chamado “glue record”, um registro que é configurado na infraestrutura do domínio de topo, como .br ou .com, que traz esse mesmo vínculo entre o domínio do nameserver e o IP.

Uma observação: alguns nomes de domínio na configuraçã da zona terminam com um ponto, outros não. A ausência do ponto indica que o nome é relativo à zona. Então www é www.exemplo.com, zabbix é zabbix.exemplo.com. O ponto ao final indica que aquele nome é completo, como no caso do registro CNAME acima.

As configurações podem ser validadas da seguinte forma:

$ named-checkzone exemplo.com /etc/bind/exemplo.com

O comando deve retornar um “OK”.

Normalmente, as zonas de DNS contam com 2 servidores de nome, um primário e um secundário. Essa redundância tem como objetivo impedir que o domínio fique indisponível caso haja algum problema ou manutenção em um dos servidores, e isso é um padrão por causa do quão crítico pra infraestrutura da internet esse tipo de serviço é.

No caso abordado, para uma aplicação de um serviço de DNS interno, isso pode não ser tão crítico, então o servidor secundário foi comentado no arquivo de configuração da zona. No entanto, caso fosse necessário configurar um nameserver secundário, as únicas configurações necessárias são a declaração da zona de DNS no servidor secundário no arquivo /etc/bind/named.conf.local com o servidor primário apontado, e o servidor secundário precisa ser especificado na configuração do servidor primário.

No servidor secundário:

zone "exemplo.com" {
    type slave;
    masters { 192.168.11.3; };
    file "/var/cache/bind/exemplo.com";
};

No servidor primário a linha allow-transfer deve ser adicionada para permitir que o sevidor secundário tenha acesso à configuração dessa zona específica:

zone "exemplo.com" {
        type master;
        file "/etc/bind/exemplo.com";
        allow-transfer { 192.168.11.4; };
};