Trouble with beta DNSSEC deployment:

Mark Andrews Mark_Andrews at isc.org
Mon Jun 12 23:47:10 UTC 2006


> Hey all,
> 
> I've signed my (rather extensive) zonefile for DNSSEC purposes, and
> then on an unrelated machine configured a trust anchor to see if I
> could authenticate the signed zone.  My results were less than stellar,
> and I was wondering if anyone could help interpret these:
> 
> Keys were created via:
> 
> dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -v 10 -n ZONE gushi.org
> dnssec-keygen -r/dev/random -f KSK -a RSASHA1 -b 1024 -n ZONE gushi.org
> 
> Keys were then included in the zonefile, and it was signed using:
> 
> dnssec-signzone -r /dev/urandom -o gushi.org -k
> Kgushi.org.+005+36153.key -e +31536000 gushi.org.hosts
> Kgushi.org.+005+31730.key
> 
> (yes, I signed it for a year).
> 
> I then added the trusted key to my test server (feel free to query it
> from DNS to verify it)...
> 
> trusted-keys {
>         "gushi.org." 257 3 5
> "AQOzvSPlWoJf37qGLPyVsySW9xiDeCLGUhVDYlctYphJYxRNHomQHDQl
> 4Km3iPZcN3uLmcOQR+Z7rEJLJe27aiiI7StVKvxgSi/q9VAJEgcycpnU
> m1xGLNSaVxeg3u3C91UuLKUpp9IQo1FYU3Lt0WDaqj2N3HIpp6iES5fUi2NUQw==";
>                         };
> 
> When I run dig, I get the following:
> 
> ; <<>> DiG 9.3.2 <<>> +dnssec gushi.org @localhost
> ; (2 servers found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55795
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;gushi.org.                     IN      A
> 
> ;; Query time: 6 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sun Jun 11 00:23:35 2006
> ;; MSG SIZE  rcvd: 38
> 
> And in the dnssec log on the server, I find:
> 
> 11-Jun-2006 04:21:06.525 dnssec: debug 3: validating @0xa7b5000:
> gushi.org A: starting
> 11-Jun-2006 04:21:06.525 dnssec: debug 3: validating @0xa7b5000:
> gushi.org A: attempting insecurity proof
> 11-Jun-2006 04:21:06.525 dnssec: debug 3: validating @0xa7b5000:
> gushi.org A: insecurity proof failed
> 11-Jun-2006 04:21:06.525 dnssec: debug 3: validator @0xa7b5000:
> dns_validator_destroy
> 11-Jun-2006 04:21:06.529 dnssec: debug 3: validating @0xa7b5000:
> gushi.org A: starting
> 11-Jun-2006 04:21:06.529 dnssec: debug 3: validating @0xa7b5000:
> gushi.org A: attempting insecurity proof
> 11-Jun-2006 04:21:06.529 dnssec: debug 3: validating @0xa7b5000:
> gushi.org A: insecurity proof failed
> 11-Jun-2006 04:21:06.529 dnssec: debug 3: validator @0xa7b5000:
> dns_validator_destroy
> 
> I've got no idea what this means.  Does anyone else here?
> 
> I've made sure the signed zone IS the one being served by all the
> involved nameservers, serial numbers match, SOA values are right, etc.
> Ive double checked the trusted-key again and again.  Nameserver
> versions are 9.3.2 on the resolving one, and 9.3.2 and 9.3.1 on the
> authoritative ones.
> 
> If anyone would like, I'll give you my TSIG key so you can AXFR the
> zone for yourself.

	Try querying the authoritative servers to see what they (don't)
	return.  Ensure that you have set "dnssec-enable yes;".

	Also you will want to upgrade the 9.3.1 server now and all of them
	again once 9.3.3 is released.

	People are finally exercising the DNSSEC code paths.  Teething
	issues are likely to arise.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list