Este é um problema comum com o BIND , embora confuso.
- No modo recursivo, o BIND pode retornar registros extras dos quais está passivamente ciente, mas não tentará procurar ativamente por esses registros, a menos que seja exigido pelos padrões relevantes.
- Quando esse comportamento é encontrado em um único servidor DNS (ou seja, a inconsistência é observada em um único servidor, não na frente de um balanceador de carga), a possibilidade de os RR ausentes não serem solicitados deve ser considerada. Um teste simples é pedir explicitamente um registro que você espera que seja incluído e repita a consulta original. Se o registro agora estiver incluído, não será necessário executar a recursão adicional para incluir essa resposta na resposta anterior. A inclusão do registro extra é puramente informativa .
Neste caso específico, parece que você está esperando que os registros RRSIG sejam apresentados ao resolvedor de stub. Pense nisso embora. Como essa assinatura é útil sem conhecer também as assinaturas intermediárias?
Antes de prosseguirmos com as RFCs do DNSSEC, vamos fazer uma rápida revisão do que está facilmente disponível na Wikipedia:
https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers
A stub resolver will simply forward a request to a recursive name server, and use the Authenticated Data (AD) bit in the response as a "hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response."
A validating stub resolver can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver uses the CD bit to perform its own recursive authentication. Using such a validating stub resolver gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet Service Provider or the connection to them is not trusted.
A ênfase em negrito é minha. Juntando isso:
- Um resolvedor de stub sem validação simplesmente procura o
ADem sua resposta e está confiando que o servidor recursivo executou a validação para ele. Não faz nada com o registroRRSIG. Os aplicativos que desejam executar uma ação com base nesseRRSIGdevem solicitar esse registro diretamente e não confiar em sua inclusão na resposta. - Um resolvedor de stub de validação deve executar sua própria recursão. Essa é a única maneira de validar que as assinaturas válidas estão em vigor dos servidores raiz até o
RRSIGassociado ao registro em questão.
Sabendo de tudo isso, precisamos confirmar o que exatamente o dig está fazendo quando o sinalizador +dnssec está definido. Podemos conseguir isso na página do manual:
+[no]dnssec
Requests DNSSEC records be sent by setting the DNSSEC OK bit (DO)
in the OPT record in the additional section of the query.
A partir disso podemos inferir que dig não está operando como um resolvedor de stub de validação (o que pode ser confirmado com uma captura de pacote se você preferir, já que ele deveria estar executando sua própria recursão), e que o BIND servidor está não executando a validação em seu nome, pois a resposta não retornou com o ad bit definido na pseudo-seção OPT para a resposta. (apenas do , uma confirmação de que viu do na consulta original)