[nSLUG] DNSSEC configuration
D G Teed
donald.teed at gmail.com
Wed Dec 17 11:03:30 AST 2014
On Wed, Dec 17, 2014 at 10:13 AM, D G Teed <donald.teed at gmail.com> wrote:
> The Google DNS servers (e.g. 18.104.22.168) do support DNSSEC, and the
> dig tests perform as expected there.
> dig whitehouse.gov +dnssec @22.214.171.124
> shows flags with qr rd ra ad (ad is the one I'm looking for)
> Also, dig badsign-a.test.dnssec-tools.org +dnssec @126.96.36.199
> does not give a result because the signing is bad....
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> badsign-a.test.dnssec-tools.org
> +dnssec @188.8.131.52
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47495
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512
> ;; QUESTION SECTION:
> ;badsign-a.test.dnssec-tools.org. IN A
> This clearly points to the DNS/bind configuration being the root
> issue. All fhe docs I find say it is enabled by using:
> dnssec-enable yes;
> dnssec-validation yes;
> in the bind options, preferably with referencing the bind keys
> file for the root iscdlv key. This is not enough to make it work
> with bind 9.8.4 on Debian or 9.8.2 on Redhat.
> Also tried out the DNS servers of Bell Aliant in my resolv.conf
> and they do not support the test. I thought maybe
> someone on the list had implemented the name service
> caching end of this and might know the tricks already.
> I believed I did have it configured and working until
> I tried the tests suggested by the dnssec-tools.org folks.
OK, about half of the documentation out there is wrong.
It MUST be auto, not yes, to use DNSSEC.
I knew it had to be something simple - too
bad there are no errors or warnings.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nSLUG