BIND não responde com autoridade
Desejo usar o BIND como um servidor de nomes público para os domínios de empresas. Estou usando uma nova instalação do ubuntu server 20.04.1 e BIND 9.16.1. O problema é que o BIND nunca responde com autoridade. Eu posso ver isso usando o dig. Para localizar o problema, tentei com uma zona única e mínima "example.com", mas sem sucesso. O arquivo de zona é db.example.com:
example.com. 86400 IN SOA ns1.example.com. hostmaster.example.com. (
1 ; Serial
900 ; Refresh
300 ; Retry
86400 ; Expire
600 ) ; Negative Cache TTL
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN MX 10 mail.example.com.
ns1.example.com. 86400 IN A 123.123.123.123
mail.example.com. 86400 IN A 125.125.125.125
Obviamente, os endereços IP acima não são os endereços IP reais, mas o endereço IP para ns1.example.com é o endereço IP público do sistema em que o BIND está sendo executado. named-checkzone está satisfeito com isso. Em named.conf.local, apenas as seguintes linhas são adicionadas:
zone "example.com" {
type master;
file "/var/lib/bind/db.example.com";
};
named.conf.options:
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no;
listen-on { any; };
listen-on-v6 { any; };
recursion no;
};
Usando dig com ANY, posso ver todos os registros no arquivo de zona, mas o BIND sempre responde AUTHORITY: 0 . Além disso, os registros A não aparecem na seção de respostas, mas na seção adicional. Infelizmente, não tenho permissão para postar o resultado original do dig porque parece spam. A zona é configurada como master e o registro NS aponta para o endereço IP do servidor onde o BIND está rodando. Outro pensamento foi que o BIND pode tentar consultar "example.com" na raiz e saber que não é realmente o servidor de nomes autorizado. Então eu também tentei o mesmo com o domínio "example.invalid" que realmente não deveria existir em lugar nenhum. O resultado foi o mesmo de "example.com". Eu nunca tive esse problema antes. O que mais posso tentar resolver este problema?
Respostas
O BIND sempre responde AUTORIDADE: 0.
Isso é normal e não significa que a resposta não foi autorizada. Muito pelo contrário, esta seção deve conter registros que informam ao cliente que a autoridade está em outro lugar - por exemplo, se você consultou um servidor de nomes que hospeda a comzona pai ou mesmo a zona raiz, você obteria uma resposta de "referência" que contém Registros NS nesta seção.
Pelo que eu sei, uma resposta oficial real nunca deve conter nenhum registro nesta seção.
Em outras palavras, você está olhando para a parte errada da saída de dig. Para descobrir se uma resposta foi autorizada ou não, olhe para a seção "sinalizadores" - o aasinalizador ( Resposta Autoritativa ) é o indicador.
Além disso, os registros A não aparecem na seção de resposta, mas na seção adicional
Isso também é normal. Eles não aparecerão na seção de respostas porque seu example.comdomínio não possui nenhum registro A.
No entanto, ele possui alguns tipos de registro (NS e MX) que fazem referência a outro nome de domínio que possui registros A. Normalmente, uma segunda consulta seria necessária para resolvê-los para os endereços reais, mas o servidor DNS pode incluir opcionalmente esses registros A / AAAA na seção Adicional.
Então, quando você consulta dig example.com MX, a seção Resposta terá os registros MX para example.com (isto é exatamente o que você consultado), e secção Adicional terá os / AAAA registros A para mail.example.com (que você não fez consulta para , mas o servidor os incluiu para acelerar as coisas).