The CUDN central recursive DNS servers have been
performing DNSSEC validation since 9 June 2009, initially using
lookaside validation via
dlv.isc.org, and validating
from the root zone since it was signed on 18 July 2010.
If you set up validation on your own recursive
nameservers, then you should achieve equivalent
results. The following describes how you can test that.
The most useful test is to use
dig +dnssec [some_name_in_a_signed_and_registered_zone] @[nameserver]
and see whether you get the ad bit set among the "flags" in the
response. This means that the nameserver has successfully
validated the answer it got from the authoritative nameservers.
Note, however, that BIND does not validate the contents of zones for
which it is authoritative. So if the "aa" bit is set in the response,
then the "ad" bit will not be. As you will typically be a stealth
secondary for cam.ac.uk, that isn't a good test case.
You use any signed zone with a chain of trust from the root. For the former, you might try any of the DNSSEC signed top-level domains listed by ICANN, for example
dig +dnssec -t SOA com. @[nameserver]
Other domains to try include ripe.net, isc.org, or ic.ac.uk.
You can also test a domain which has a deliberately broken DNSSEC, to verify that your validator is correctly detecting problems. For example, the following query should result in a SERVFAIL error:
dig dnssec-failed.org
With recent versions of dig you can use the +adflag option instead
of the +dnssec option. This requests the server to set the "ad" bit
in the response, if the data has been validated, but not the DNSSEC
records that would prove it. In the BIND 9.9 distribution, this
has even become the default.