Jump to first page
 -105
Testing a verifying forwarder
dig: an example
n; <<>> DiG 9.3.0s20020122 <<>> +dnssec @127.0.0.1 secret-wg.org NS
n;; global options:  printcmd
n;; Got answer:
n;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31630
n;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
n
n;; OPT PSEUDOSECTION:
n; EDNS: version:    0, udp=   4096
n;; QUESTION SECTION:
n;secret-wg.org. IN NS
n
n;; ANSWER SECTION:
nsecret-wg.org. 600 IN NS ns2.secret-wg.org.
nsecret-wg.org. 600 IN NS bert.secret-wg.org.
nsecret-wg.org. 600 IN SIG NS 1 2 600 20020314134313
n                       20020212134313 47783 secret-wg.org.
n      DVC/ACejHtZylifpS6VSSqLa15xPH6p33HHmr3hC7eE6/QodM6fBi5z3
n      fsLhbQuuJ3pCEdi2bu+A0duuQlQMiHPvrkYia4bKmoyyvWHwB3jcyFhW
n      lV4YOzX/fgkLUmu8ysGOiD9C0CkSvNSE6rBCzUa3hfkksHt4FBsuA1oQ
n      yoc=
Some notes:
When querying an authoritative server directly, data will not be verified! Even if a signature is corrupt (i.e. the data is BAD). This is because the authoritative server trusts the data from disk. Note that both the ÔadÕ and ÔaaÕ flags are set.

The semantics of the AD bit are under discussion. There are several issues that mainly have to do with what exactly is covered by the ÔadÕ statement of security.