logoCert_sugestao2.png

Testando DNSSEC com o DIG

Introdução

Este documento descreve algumas opções de teste do DNSSEC usando o DIG.

Consulta simples

O comando abaixo realiza uma consulta ao servidor recursivo DNSSEC-habilitado 192.168.5.6 pelo registro www.pop-ba.rnp.br/A. A primeira linha, em negrito, é o comando executado, onde temos o parâmetro +dnssec informa ao DIG para requisitar os registros DNSSEC na consulta (setando o bit DO - DNSSEC OK); já o parâmetro +multiline é somente para dividir as assinaturas em várias linhas; o parâmetro +noadditional informa ao DIG para não retornar dados adicionais à consulta (por exemplo, registros NS, etc.). O restante das linhas são os resultados, que analisaremos abaixo.

dig +dnssec +multiline +noadditional @192.168.5.6 www.pop-ba.rnp.br

; <<>> DiG 9.6.1-P1 <<>> +dnssec +multiline +noadditional @192.168.5.6 www.pop-ba.rnp.br
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10840
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.pop-ba.rnp.br.   IN A

;; ANSWER SECTION:
www.pop-ba.rnp.br.   35784 IN CNAME server2.pop-ba.rnp.br.
www.pop-ba.rnp.br.   35784 IN RRSIG CNAME 5 4 38400 20100920120357 (
            20100622120357 52737 pop-ba.rnp.br.
            lfdwV1CnFE/WccanQ9PmR2mowKZTHSN/FIQNdOg4l9Xn
            zUqBWmGWNCg+94oqK/MzwSQP6pAHG6HJEHoMaNNI0Nmw
            NfPYg0IEJojhTEGPwAtuE7DnWY8FeZMds+sFQdP7PfbA
            4ocHDBl1ECg5o1BO1mNx1Pgf/jE2vjXItqoOPdAjemlX
            Xtu992vQ6AtR3GZc )
server2.pop-ba.rnp.br.   35784 IN A 200.18.234.22
server2.pop-ba.rnp.br.   35784 IN RRSIG A 5 4 38400 20100920120357 (
            20100622120357 52737 pop-ba.rnp.br.
            cXkndSmlx7KsZ9eggq5AfrzXPPXQ7AnNJ688BbL2omj3
            k1oAqYLT9/KJp3HwWxlu6xrp4fLgExjSo52hpi6itwpr
            gI7DEtYvxYrYBCMPa2G/RLwwlY6u7BPIKf3E7ZNaOL4b
            xhGQvneH2rT2N6SsG8Kny/XCSzq6FCeLLCH44QMKWMCw
            4C4Hgho/zcrdnHgW )

;; Query time: 12 msec
;; SERVER: 192.168.5.6#53(192.168.5.6)
;; WHEN: Wed Jul  7 15:06:51 2010
;; MSG SIZE  rcvd: 462

Um detalhe que não passa despercebido são as assinaturas dos registros (para cada registro retornado, temos também a assinatura do registro), aumentando bastante o tamanho da resposta. Observe também o campo flags do cabeçalho, que contém os seguintes FLAGS: qr rd ra ad. Em particular, vamos olhar para o flag aa, que significa Dados Autenticos. Esse flag é setado na resposta quando o servidor consegue validar uma resposta com DNSSEC (RFC 4035). Vale ressaltar que o flag AD não é setado quando de uma resposta autoritativa (ou seja, o servidor recursivo é autoritativo para o nome da consulta).

Verificando o canal de assinaturas DNSSEC

Uma outra opção disponível no DIG (a partir da versão 9.7.0) é o parâmetro +sigchase. Essa opção é interessante para validar o caminho de segurança nas delegações de zona. Por exemplo, você configura uma âncora de segurança para o domínio br. em seu servidor e tenta verificar se as delegações até seu domínio estão corretas.

Em nosso exemplo, vamos verificar o caminho do br. até a zona pop-ba.rnp.br (que passa pela zona rnp.br). Para isso precisamos configurar o arquivo com a âncora que usaremos em nossa busca (o ponto de entrada seguro). Em nosso caso, teremos a âncora da zona br., que será incluída no arquivo /tmp/trusted-key.key e deve conter o seguinte (a chave pode mudar dependendo de quando você está realizando essa configuração):

br.              21600 IN DNSKEY   257 3 5 AwEAAblaEaapG4inrQASY3HzwXwBaRSy5mkj7mZ30F+huI7zL8g0U7dv7ufnSEQUlsC57OHoTBza+TQIv/mgQed8Fy4XGCGzYiHSYVYvGO9iWG3O0voBYy/zv0z7ANfrA7Z3lY51CI6m/qoZUcDlNM0yTcJgilaKwUkLBHMAp9NJPuKVt8A7OHab00r2RDEVjiLWIIuTbz74gCXOVfAmvW07c8c=

Por fim, executamos o comando a seguir para obter informações sobre a cadeia de verificação de uma consulta DNSSEC (no exemplo abaixo o servidor recursivo DNSSEC-habilitado é 192.168.5.6):

dig @192.168.5.6 +trusted-key=/tmp/trusted-key.key  +sigchase www.pop-ba.rnp.br

A saída desse comando é grande, por isso não será exibida no tutorial. Porém a ideia é que para cada nível na hierarquia será obtido a chave e comparado ou com o registro DS da zona parent ou com a chave armazenada no arquivo trusted-key.key criado acima (o que deve ocorrer somente para o domínio br no exemplo acima). Junto ao resultado apresentado, alguns comentários são adicionados para facilitar a compreensão.