DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I have my test zone example configured with option auto-dnssec maintain;
zone "example" {
type master;
file "var/zone/example";
allow-update { loopback; };
allow-transfer { trusted; loopback; };
auto-dnssec maintain;
key-directory "var/keys/example";
};
in server conf there's also 'dnssec-enable yes'
and I've configured keys (KSK/ZSK) with timing options (same for both keys):
; Created: 20110114150841 (Fri Jan 14 16:08:41 2011)
; Publish: 20110114151339 (Fri Jan 14 16:13:39 2011)
; Activate: 20110114151839 (Fri Jan 14 16:18:39 2011)
; Inactive: 20110114152339 (Fri Jan 14 16:23:39 2011)
; Delete: 20110114152839 (Fri Jan 14 16:28:39 2011)
I started bind, send update for my example zone with NSEC3PARAM:
Jan 14 16:08:40 named[25297]: general: zone example/IN:
dns_zone_addnsec3chain(hash=1, iterations=12, salt=28EA1FFF42617C9D59B1)
Jan 14 16:08:40 named[25297]: general: zone example/IN:
zone_addnsec3chain(1,CREATE,12,28EA1FFF42617C9D59B1)
send the rndc sign command:
Jan 14 16:08:41 named[25297]: general: received control channel command
'sign example'
Jan 14 16:08:41 named[25297]: general: zone example/IN: reconfiguring
zone keys
Jan 14 16:08:42 named[25297]: general: zone example/IN:
zone_addnsec3chain(1,REMOVE|NONSEC,12,28EA1FFF42617C9D59B1)
Jan 14 16:08:42 named[25297]: general: zone example/IN: next key event:
14-Jan-2011 16:13:39.200
next key event is scheduled for 16:13:39.200 which is correct, and this
is the key Publish event:
Jan 14 16:13:39 named[25297]: general: zone example/IN: reconfiguring
zone keys
Jan 14 16:13:39 named[25297]: general: zone example/IN: next key event:
14-Jan-2011 16:23:39.234
but what with the Activate event??? in log I just see Publish, Inactive
and Delete events but without Activate event. zone is just no signed by
named.
If I use default settings when generating keys (Created, Publish,
Activate = NOW), change 'auto-dnssec maintain' to 'auto-dnssec allow'
and send 'rndc sign example' zone is signed without problems.
what's going on?
- --
regards
zbigniew jasinski
[SYStem OPerator]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNNEh0AAoJEH26UYiRhe/g2WoP/i4Ecn5Jq78GFFlJGpde6fyd
vXN3pwFpWUvDSZqYQfLYMHg4PaI5RNDU2NLfnM0gnMZ83cXz0kw0h9bBj8O/EmXX
44+7/wheBnpOijlKItt2IjnBzFKV6uTu6nj5RtpbvTAMTEny0Hy4q41Y8zB8Mt4P
h0VuTi91q2WmSisa2bYnIKrQzQFR6W+nbPRFpxHyzj3SX2hdoqSBQkbNhmC+nCJR
nJQQa4u9JKcCtDkQeoRUiUVHNECuZSXMwCukXEagweEadP6EIPhC+TCyUTXKiR7s
9jQ/1svVmsKNqqFLgMf2w2x8oKXeAP/PvRzlyZlBwzHHgHBetgPsd1oKcHB9rElM
/rVNk8nzIadrp0TF7WEy4Ld4GdbwVGbiv0p+vDounPmm4KntwcxyFxpu+PZRs/tp
zt/z4KYrR+Z+1pNl6ojfg5mD7UTPEmMj9gFHhVuwdrcHP5EH/SkxofDFAB8C0IyX
LJ3jbKITqmLHhVCDWVLxwXws4/QUOTF/rU48zk1XxaEP80tmKO9PfgCYr4QPz3v4
UDPMvZyI5r0yqk+V5gxXMjWcbMh9K/lq00Nj4/dXCP9iIlvd0MkKdnfTHuMK5BNN
OGTrQlVVyGG6+iKU1XXAp0BahVjQnGk46EsKcqUXOjc/4bm/myvfG3WyLFm8okYD
412Ik3YKP3YpZvxqc9X6
=+ZO3
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
Have you tried more sane times?
Those don't look like sensible times even for a test, which is probably why
BIND isn't signing. I think you are below the sensitivity level for BIND to
sign automatically.
If you want to test, try using hours or days as values. When initially
testing I used lifetimes of a week, then increased to 1 month for ZSKs and 3
months for KSKs. That allowed me to test things quickly, but without
compromising the validity of the test.
On 17/01/11 2:47 PM, "Zbigniew Jasiński" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Hi all,
>
> I have my test zone example configured with option auto-dnssec maintain;
>
> zone "example" {
> type master;
> file "var/zone/example";
> allow-update { loopback; };
> allow-transfer { trusted; loopback; };
> auto-dnssec maintain;
> key-directory "var/keys/example";
> };
>
> in server conf there's also 'dnssec-enable yes'
>
> and I've configured keys (KSK/ZSK) with timing options (same for both keys):
>
> ; Created: 20110114150841 (Fri Jan 14 16:08:41 2011)
> ; Publish: 20110114151339 (Fri Jan 14 16:13:39 2011)
> ; Activate: 20110114151839 (Fri Jan 14 16:18:39 2011)
> ; Inactive: 20110114152339 (Fri Jan 14 16:23:39 2011)
> ; Delete: 20110114152839 (Fri Jan 14 16:28:39 2011)
>
> I started bind, send update for my example zone with NSEC3PARAM:
>
> Jan 14 16:08:40 named[25297]: general: zone example/IN:
> dns_zone_addnsec3chain(hash=1, iterations=12, salt=28EA1FFF42617C9D59B1)
> Jan 14 16:08:40 named[25297]: general: zone example/IN:
> zone_addnsec3chain(1,CREATE,12,28EA1FFF42617C9D59B1)
>
> send the rndc sign command:
>
> Jan 14 16:08:41 named[25297]: general: received control channel command
> 'sign example'
> Jan 14 16:08:41 named[25297]: general: zone example/IN: reconfiguring
> zone keys
> Jan 14 16:08:42 named[25297]: general: zone example/IN:
> zone_addnsec3chain(1,REMOVE|NONSEC,12,28EA1FFF42617C9D59B1)
> Jan 14 16:08:42 named[25297]: general: zone example/IN: next key event:
> 14-Jan-2011 16:13:39.200
>
> next key event is scheduled for 16:13:39.200 which is correct, and this
> is the key Publish event:
>
> Jan 14 16:13:39 named[25297]: general: zone example/IN: reconfiguring
> zone keys
> Jan 14 16:13:39 named[25297]: general: zone example/IN: next key event:
> 14-Jan-2011 16:23:39.234
>
> but what with the Activate event??? in log I just see Publish, Inactive
> and Delete events but without Activate event. zone is just no signed by
> named.
>
> If I use default settings when generating keys (Created, Publish,
> Activate = NOW), change 'auto-dnssec maintain' to 'auto-dnssec allow'
> and send 'rndc sign example' zone is signed without problems.
>
> what's going on?
>
> - --
> regards
>
> zbigniew jasinski
> [SYStem OPerator]
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJNNEh0AAoJEH26UYiRhe/g2WoP/i4Ecn5Jq78GFFlJGpde6fyd
> vXN3pwFpWUvDSZqYQfLYMHg4PaI5RNDU2NLfnM0gnMZ83cXz0kw0h9bBj8O/EmXX
> 44+7/wheBnpOijlKItt2IjnBzFKV6uTu6nj5RtpbvTAMTEny0Hy4q41Y8zB8Mt4P
> h0VuTi91q2WmSisa2bYnIKrQzQFR6W+nbPRFpxHyzj3SX2hdoqSBQkbNhmC+nCJR
> nJQQa4u9JKcCtDkQeoRUiUVHNECuZSXMwCukXEagweEadP6EIPhC+TCyUTXKiR7s
> 9jQ/1svVmsKNqqFLgMf2w2x8oKXeAP/PvRzlyZlBwzHHgHBetgPsd1oKcHB9rElM
> /rVNk8nzIadrp0TF7WEy4Ld4GdbwVGbiv0p+vDounPmm4KntwcxyFxpu+PZRs/tp
> zt/z4KYrR+Z+1pNl6ojfg5mD7UTPEmMj9gFHhVuwdrcHP5EH/SkxofDFAB8C0IyX
> LJ3jbKITqmLHhVCDWVLxwXws4/QUOTF/rU48zk1XxaEP80tmKO9PfgCYr4QPz3v4
> UDPMvZyI5r0yqk+V5gxXMjWcbMh9K/lq00Nj4/dXCP9iIlvd0MkKdnfTHuMK5BNN
> OGTrQlVVyGG6+iKU1XXAp0BahVjQnGk46EsKcqUXOjc/4bm/myvfG3WyLFm8okYD
> 412Ik3YKP3YpZvxqc9X6
> =+ZO3
> -END PGP SIGNATURE-
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Kal Feher
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-17 15:39, Kalman Feher pisze: > Have you tried more sane times? > > Those don't look like sensible times even for a test, which is probably why > BIND isn't signing. I think you are below the sensitivity level for BIND to > sign automatically. > > If you want to test, try using hours or days as values. When initially > testing I used lifetimes of a week, then increased to 1 month for ZSKs and 3 > months for KSKs. That allowed me to test things quickly, but without > compromising the validity of the test. > maybe it was little to short for keys, but ok, new keys with new timings: ; Created: 20110119091030 (Wed Jan 19 10:10:30 2011) ; Publish: 20110119091124 (Wed Jan 19 10:11:24 2011) ; Activate: 20110119091224 (Wed Jan 19 10:12:24 2011) ; Inactive: 20110218091224 (Fri Feb 18 10:12:24 2011) ; Delete: 20110218091724 (Fri Feb 18 10:17:24 2011) and what I've seen in logs: NSEC3PARAM via dynamic update, and 'rndc sign' command: Jan 19 10:10:24 named[32664]: update: client 127.0.0.1#65349: updating zone 'example/IN': adding an RR at 'example' NSEC3PARAM Jan 19 10:10:24 named[32664]: general: zone example/IN: dns_zone_addnsec3chain(hash=1, iterations=12, salt=1BDF09CE56C674D422EB) Jan 19 10:10:24 named[32664]: general: zone example/IN: zone_addnsec3chain(1,CREATE,12,1BDF09CE56C674D422EB) Jan 19 10:10:30 named[32664]: general: received control channel command 'sign example' Jan 19 10:10:30 named[32664]: general: zone example/IN: reconfiguring zone keys Jan 19 10:10:30 named[32664]: general: zone example/IN: zone_addnsec3chain(1,REMOVE|NONSEC,12,1BDF09CE56C674D422EB) Jan 19 10:10:30 named[32664]: general: zone example/IN: next key event: 19-Jan-2011 10:11:24.765 first key event is Publish: Jan 19 10:11:24 named[32664]: general: zone example/IN: reconfiguring zone keys Jan 19 10:11:24 named[32664]: general: zone example/IN: next key event: 19-Jan-2011 11:11:24.807 second one is Activate which should occur on (Wed Jan 19 10:12:24 2011), but in log is one hour later, why is that? but ok, signing zone is most important, so after Activate key event: Jan 19 11:11:24 named[32664]: general: zone example/IN: reconfiguring zone keys Jan 19 11:11:25 named[32664]: general: zone example/IN: next key event: 18-Feb-2011 10:12:24.274 so now I should have a signed zone with KSK/ZSK of one month lifetime. using dig: $ dig @127.0.0.1 example dnskey +dnssec +short 257 3 10 AwEAAa7r9QSelP34TYFVWWLhDVU+RU+LI7Fr9N0Hy2xnJ/8TK8sRo+OC 256 3 10 AwEAAa/sFWJDcylO33IQWnpKEve661t0S/K8+AWPy+PSq69xo27WUGRN so I have both keys in my zone, but without signatures. I've checked the journal file and there are updates with RRSIG records but still named is returning answers without signatures. Any hint? - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNNs+3AAoJEH26UYiRhe/gfRsP/3m2zDBhKPpICiUroC+CUgpw OKlwGRcwWZFrmea4j7J/zUdS6OPpwh8lsHCftUS17WPhr654guAF7ftf/y8m6dLb 2aYOU1boYv4uDrlu74/bvyt1FngA8LMzNIO2lIP/x53QBqMMuPRTMsC4SpMi4VVc G04jeVjE7R6RG1kDZspEaaRtbxtQpJobW2seKP90U99FMhwAgqyDFwYdx1zF0vAt kcDmN+fwGOJUQO1CO8/2jX6AgpMXDGOoG75qCVHB5QzXysW47rzLuewvVB9h/2lU WNDtmCUIZ50JtfyuOKrz8U6hdbfvRI4iJFdweckniCJ85gyx7fHMP3sgZModRKgW PdxLjHQ3xOqsBmfGlAaeYSrAx7hryNaUqLE1xGDLkCaX7dywz5sH4kElqpRwGOvf CvLBJ8df7qGLgX+B5VuAXOzGZxOCOhwBuMiSYwY8F/12tBhzW8nhaRGBuBBj6cAp 7AkFFa/DsqVvCo+sYWt1+ekAt2LQWnE+cDaV2Ar84lG/fMYtvHDfNhdqLa1P6N7S PG9rdfkv+jh5zlczIoNFVRVhVoPEs2ui28PVw8ArvOnUeeJrl60fdputvcXThUY/ uea6/mDrRCLSUYpV9oyMxDdtR3pz0buD80Gk20HBgI/BHopD6H77DNpDAvy+Q3fF wgluCpVvogYlj88l1uXZ =jGrN -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
Try without +short ;) I also have the habit of using that and can get caught out. Remember that +short only includes the answer, which is not the RRSIG you are hoping to see. On 19/01/11 12:49 PM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-17 15:39, Kalman Feher pisze: >> Have you tried more sane times? >> >> Those don't look like sensible times even for a test, which is probably why >> BIND isn't signing. I think you are below the sensitivity level for BIND to >> sign automatically. >> >> If you want to test, try using hours or days as values. When initially >> testing I used lifetimes of a week, then increased to 1 month for ZSKs and 3 >> months for KSKs. That allowed me to test things quickly, but without >> compromising the validity of the test. >> > > maybe it was little to short for keys, but ok, new keys with new timings: > > ; Created: 20110119091030 (Wed Jan 19 10:10:30 2011) > ; Publish: 20110119091124 (Wed Jan 19 10:11:24 2011) > ; Activate: 20110119091224 (Wed Jan 19 10:12:24 2011) > ; Inactive: 20110218091224 (Fri Feb 18 10:12:24 2011) > ; Delete: 20110218091724 (Fri Feb 18 10:17:24 2011) > > and what I've seen in logs: > > NSEC3PARAM via dynamic update, and 'rndc sign' command: > > Jan 19 10:10:24 named[32664]: update: client 127.0.0.1#65349: updating > zone 'example/IN': adding an RR at 'example' NSEC3PARAM > Jan 19 10:10:24 named[32664]: general: zone example/IN: > dns_zone_addnsec3chain(hash=1, iterations=12, salt=1BDF09CE56C674D422EB) > Jan 19 10:10:24 named[32664]: general: zone example/IN: > zone_addnsec3chain(1,CREATE,12,1BDF09CE56C674D422EB) > Jan 19 10:10:30 named[32664]: general: received control channel command > 'sign example' > Jan 19 10:10:30 named[32664]: general: zone example/IN: reconfiguring > zone keys > Jan 19 10:10:30 named[32664]: general: zone example/IN: > zone_addnsec3chain(1,REMOVE|NONSEC,12,1BDF09CE56C674D422EB) > Jan 19 10:10:30 named[32664]: general: zone example/IN: next key event: > 19-Jan-2011 10:11:24.765 > > first key event is Publish: > > Jan 19 10:11:24 named[32664]: general: zone example/IN: reconfiguring > zone keys > Jan 19 10:11:24 named[32664]: general: zone example/IN: next key event: > 19-Jan-2011 11:11:24.807 > > second one is Activate which should occur on (Wed Jan 19 10:12:24 2011), > but in log is one hour later, why is that? > > but ok, signing zone is most important, so after Activate key event: > > Jan 19 11:11:24 named[32664]: general: zone example/IN: reconfiguring > zone keys > Jan 19 11:11:25 named[32664]: general: zone example/IN: next key event: > 18-Feb-2011 10:12:24.274 > > so now I should have a signed zone with KSK/ZSK of one month lifetime. > using dig: > > $ dig @127.0.0.1 example dnskey +dnssec +short > 257 3 10 AwEAAa7r9QSelP34TYFVWWLhDVU+RU+LI7Fr9N0Hy2xnJ/8TK8sRo+OC > > 256 3 10 AwEAAa/sFWJDcylO33IQWnpKEve661t0S/K8+AWPy+PSq69xo27WUGRN > > > so I have both keys in my zone, but without signatures. > > I've checked the journal file and there are updates with RRSIG records > but still named is returning answers without signatures. > > Any hint? > > - -- > regards > > zbigniew jasinski > [SYStem OPerator] > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNNs+3AAoJEH26UYiRhe/gfRsP/3m2zDBhKPpICiUroC+CUgpw > OKlwGRcwWZFrmea4j7J/zUdS6OPpwh8lsHCftUS17WPhr654guAF7ftf/y8m6dLb > 2aYOU1boYv4uDrlu74/bvyt1FngA8LMzNIO2lIP/x53QBqMMuPRTMsC4SpMi4VVc > G04jeVjE7R6RG1kDZspEaaRtbxtQpJobW2seKP90U99FMhwAgqyDFwYdx1zF0vAt > kcDmN+fwGOJUQO1CO8/2jX6AgpMXDGOoG75qCVHB5QzXysW47rzLuewvVB9h/2lU > WNDtmCUIZ50JtfyuOKrz8U6hdbfvRI4iJFdweckniCJ85gyx7fHMP3sgZModRKgW > PdxLjHQ3xOqsBmfGlAaeYSrAx7hryNaUqLE1xGDLkCaX7dywz5sH4kElqpRwGOvf > CvLBJ8df7qGLgX+B5VuAXOzGZxOCOhwBuMiSYwY8F/12tBhzW8nhaRGBuBBj6cAp > 7AkFFa/DsqVvCo+sYWt1+ekAt2LQWnE+cDaV2Ar84lG/fMYtvHDfNhdqLa1P6N7S > PG9rdfkv+jh5zlczIoNFVRVhVoPEs2ui28PVw8ArvOnUeeJrl60fdputvcXThUY/ > uea6/mDrRCLSUYpV9oyMxDdtR3pz0buD80Gk20HBgI/BHopD6H77DNpDAvy+Q3fF > wgluCpVvogYlj88l1uXZ > =jGrN > -END PGP SIGNATURE- > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-19 14:24, Kalman Feher pisze: > Try without +short ;) > I also have the habit of using that and can get caught out. Remember that > +short only includes the answer, which is not the RRSIG you are hoping to > see. > RRSIG is _the_ answer like normal DNS record in this particular case it's also included in answer section and +short it isn't an issue here. of course I'm asking for DNSKEY record but with DO bit I should get also signatures for this record set. like i wrote in my previous email I've checked the journal file and there are updates with RRSIG records but still named is returning answers without signatures check this out: $ dig @c.ns.nic.cz cz dnskey +dnssec +short 256 3 10 BQEBxBm6EoG5NZcdHB1TXkvEemtWUJfoveCAUpGHIHy7wzKMCdTI kEqs/n6tuGtaKsGDPwdJEy01U6uvg35Vz6fpmsIkjWcmS2TXKoBuNdsq /AN1EBpo58v1jrt1BfST3ZyHiOJsK8jg2kQwca9Pk79rqGpR5QcWGKDa oSr3vYSVJ60= 257 3 10 AwEAAaVU8EMQrZ6Tix2zBaAmizMQ7W0m94qSJUXV4eVWS9ZpXh9t1uj8 U/B5Nnqge4G0Te0/NJIqflihZKXs8HyhJqjF852RKnvNWPu2wMujYjHP 0T4lIhu4rTym9+sPNsfioqvMyyDeqyhVPx21nvLW5oaKjaLd3XJxijRb DTddRU97mJVVS50PKdDmh5n/4KdRKV7ifR2Ap8L1bvUiCOxl4GAqLoXf t+L896bkVj6mefdCSyYaCbgsDc2+10ZBOSF1t89NJ6O1yO+y5/7vS3dY KEqj+p4ygaCY0spvrhZxncUeASixg224bNYZM5TLk2/YoKgAEjaIoCwu 7SAXB5iUvLU= DNSKEY 10 1 3600 20110130131945 20110118153609 14568 cz. SllgVFaBLBuzosgOJKPGh76zOv3DghocSvpSCaX0yQ5WonDDqqU+AIAt ornhLs3EKI4a0Ofj3LCHY/Z450+5KSlbL/XguONvSMntHeKuM/J2oaYM veHr75jTzRDaRxNmByI4S3Qrg5hLRE/VF8qsQn04+L/1aGcIGk0PVwnG A0gn2mR4dzLUMgiNz6DJYsWfhRsjWF5WeQ+yfVkDVWZqTYJyIcchHvSX 0vrrcJkOi2jSmzqGH8NtvCJ4fMRiuLBde8HC8pZC5PAYiO8g6lhrHC6+ xquXs+ybPMc8J+p++f7hB95dDMHDIuOHjQjvfOZxF/IgqL1KxFb7w2GE 9RCbXQ== DNSKEY 10 1 3600 20110131234224 20110118153609 34702 cz. ACjlQpDb38se9p+enPG2KbxEjrBnfGdjYdZHSco4Ldc9EfnK67XLXvun ThUa0g+logqUJCr9NhHdd+UMaOua8vdRAe2yKyLsJzvQcKnM29b4Qfd5 fVauLa3TA9ZyPjhZgBbCmQFjKOiYW6XcYwjsOO3JUCEMEbPHmzzkhOnh Wso= 2 keys, 2 signatures. - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNNvxCAAoJEH26UYiRhe/gKcMP/10+YCk9RLCyEZa/n6wlfHYa VlBgfNqixzZo4jMegpY65Te2ULRzq/gXzcqbTlgt249ZOuRgbxDN4ewe7qzF81aX ElElCVyZLzUhUnCsPd0nQPADQJ2OoNQbm2Dkj9VuFaIEHgNYxXYtDde4gUyZkEE8 CUAU2W/XsolpUi7HLkwDOuoTLK/MW5ubb/9ocjjDquMOqjAoQeQNWjlVdXzAUBhc zZ+x+WNzwGXYFh9VmqgE8iKc/YK8hLPfAkbUdVjKCNonPJpspXyI57jOQXjsfeF0 gpPjBPGe2DwV+vPAiwRQFRBut0W7L6jHjGSy+LuecHuJIEj2x2DI0YXgd1TiaJQW yQSkVRkshxW7/3znhgl63jKgBAVcN2btEGil3F8BaFp5+Wvyk8ZAJFUEFvOEgCTW HSy2y4QgmPTkMNtxSZU89Jjij74uGBhUTrUVWsLY7JuXmWMCwE26usIEhFmiP2mo 0JCOdd3Za+CKvEAGAey09TWZdDUVD0A1dyeBcrvVN3BbaxlNV2R1bdx0NvIJdB8n Q9I2zOjJwztH06d2b+id6bU+8hXlg3Se/1igJl9inSC7jI1SqH1zm8XG237954y5 ju0kWePfr10MgvSEBFaZ4FWAsA+NxSBXxRnKluOlD1Iasmy9oquReK3ha4fNsA0h SCnoMIVGVmueKrp0/f5a =ncpB -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.01.2011 15:59, Zbigniew Jasiński wrote: > like i wrote in my previous email I've checked the journal file and > there are updates with RRSIG records but still named is returning > answers without signatures Another thing you might check: With "dnssec-enable no;" in named.conf, BIND still does its automatic DNSSEC signing but won't add RRSIG to responses. I ran across such a configuration lately. Your problem sounds similar. Hauke. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk03IXIACgkQKIgAG9lfHFN0GgCfQssE0Gjl1iVH0EvX3K0RdXNQ XUsAn1yeCOeolCfNmCEfOozhCKvgUOLW =sDdG -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-19 18:38, Hauke Lampe pisze: > Another thing you might check: > > With "dnssec-enable no;" in named.conf, BIND still does its automatic > DNSSEC signing but won't add RRSIG to responses. > > I ran across such a configuration lately. Your problem sounds similar. > > > Hauke. that was first thing which I've checked: dnssec-enable yes; and it's of course enabled. I see in journal file: ./sbin/named-journalprint var/zone/example.jnl add example. 3600IN RRSIG DNSKEY 10 1 3600 20110218225336 20110119215336 57635 example. Xo9o137Q4BmELA0wumTLujJkHq0b/tDbYvuFCfZDfcbp8cuutDJUxCPy add example. 3600IN RRSIG DNSKEY 10 1 3600 20110218225336 20110119215336 57636 example. SfFa5xjRtb/VBm3Zv1j31VRlqJORM0laX1PuZ+Asi6IFutH4q5TeknYN add example. 3600IN RRSIG SOA 10 1 3600 20110218225336 20110119215336 57635 example. wYZ/nZbnN6HGrWTDLkfbyW4dQGMVs1ZVY+r8zc9t92ykxu7ipycxnITW also RRSIG for SOA record and for DNSKEY records are present in plain zone file but still named isn't responding with correct signatures. - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNOUAtAAoJEH26UYiRhe/goMcP/i5MLxBFh8+Fl2R2oqIKdRR1 ntBcfXBK1niJmlDpFzGu97gXNxoofk/bWVEhb+eo/e4+ln8bSuOiKVV5PQJ8zq1t ke5jCIw7iRdBQgMcZNHQCWcI1lCWnPc0SxcCtw6u2ZItfFxqwANwFJw0oXwX/C8i iVGflBdSUI9G/MGIaCsiwBdNBZnVhgrVz5F3KHXKC6aH49HI9kieXqz8v9pczcGR xoy/RRrgObvb8N4jz2GA+fq8thFoKzZkoWLWG/5eE9uYd8oY3wLHIoAt0jBfGXOR UXrFQ1QDqjUdotb3ovUGH2NH1NpWnITYm9gDWqEo3egaLpQU6itc2z57BNkuIkPS qn3m2rgnEKy+p6flLYNxwyYnrXWVIpti73r+aPpkWQpWptEBcyCIl2su6yLZPv1y R7ioFCualJLOWWqio9w5hQeRUvgrF6w7XBc97PMWgwLSrjHF0XADOWn9IqB4/XgA agPSo7p8D6mmfpnv9c+q1JVIUEhEqihNs5/c1/dhRRn4SRIucvvzuVlXB/gqVQep i+Ft2Tq3zgepBOxLGtZQ22o7VoBSWj8tHT6qRDG9qChsOXE054eN+r8xNbJ4rRzu oASw1n11vm0JAqceMeadCc0Zz2y4WbIJO7jEsPTp9KUHPNwbDmNnMH7pWyHvxS4v oZD7PbxPnyDpwRerG7zh =Sp+3 -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
The only way I can replicate the behaviour is with dnssec-enable no or with an unsigned version of the zone in another view. Assuming you've not overlapped your views in such a way (it was a very contrived test), I think you'll need to provide a bit more information on your configuration. -options -relevant view statement -The zone statement (from the hashed file if you are using the new dynamic zones feature). -The zone itself -Query logs. Without the full dig output it is hard to see what is actually happening. I'd suggest including that as well. If you dig axfr or dig rrsig are the signatures present? On 21/01/11 9:13 AM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-19 18:38, Hauke Lampe pisze: > >> Another thing you might check: >> >> With "dnssec-enable no;" in named.conf, BIND still does its automatic >> DNSSEC signing but won't add RRSIG to responses. >> >> I ran across such a configuration lately. Your problem sounds similar. >> >> >> Hauke. > > that was first thing which I've checked: > > dnssec-enable yes; > > and it's of course enabled. > > I see in journal file: > > ./sbin/named-journalprint var/zone/example.jnl > > add example. 3600IN RRSIG DNSKEY 10 1 3600 > 20110218225336 20110119215336 57635 example. > Xo9o137Q4BmELA0wumTLujJkHq0b/tDbYvuFCfZDfcbp8cuutDJUxCPy > > add example. 3600IN RRSIG DNSKEY 10 1 3600 > 20110218225336 20110119215336 57636 example. > SfFa5xjRtb/VBm3Zv1j31VRlqJORM0laX1PuZ+Asi6IFutH4q5TeknYN > > add example. 3600IN RRSIG SOA 10 1 3600 > 20110218225336 20110119215336 57635 example. > wYZ/nZbnN6HGrWTDLkfbyW4dQGMVs1ZVY+r8zc9t92ykxu7ipycxnITW > > > also RRSIG for SOA record and for DNSKEY records are present in plain > zone file but still named isn't responding with correct signatures. > > - -- > regards > > zbigniew jasinski > [SYStem OPerator] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNOUAtAAoJEH26UYiRhe/goMcP/i5MLxBFh8+Fl2R2oqIKdRR1 > ntBcfXBK1niJmlDpFzGu97gXNxoofk/bWVEhb+eo/e4+ln8bSuOiKVV5PQJ8zq1t > ke5jCIw7iRdBQgMcZNHQCWcI1lCWnPc0SxcCtw6u2ZItfFxqwANwFJw0oXwX/C8i > iVGflBdSUI9G/MGIaCsiwBdNBZnVhgrVz5F3KHXKC6aH49HI9kieXqz8v9pczcGR > xoy/RRrgObvb8N4jz2GA+fq8thFoKzZkoWLWG/5eE9uYd8oY3wLHIoAt0jBfGXOR > UXrFQ1QDqjUdotb3ovUGH2NH1NpWnITYm9gDWqEo3egaLpQU6itc2z57BNkuIkPS > qn3m2rgnEKy+p6flLYNxwyYnrXWVIpti73r+aPpkWQpWptEBcyCIl2su6yLZPv1y > R7ioFCualJLOWWqio9w5hQeRUvgrF6w7XBc97PMWgwLSrjHF0XADOWn9IqB4/XgA > agPSo7p8D6mmfpnv9c+q1JVIUEhEqihNs5/c1/dhRRn4SRIucvvzuVlXB/gqVQep > i+Ft2Tq3zgepBOxLGtZQ22o7VoBSWj8tHT6qRDG9qChsOXE054eN+r8xNbJ4rRzu > oASw1n11vm0JAqceMeadCc0Zz2y4WbIJO7jEsPTp9KUHPNwbDmNnMH7pWyHvxS4v > oZD7PbxPnyDpwRerG7zh > =Sp+3 > -END PGP SIGNATURE- > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W dniu 2011-01-21 11:23, Kalman Feher pisze:
> The only way I can replicate the behaviour is with dnssec-enable no or with
> an unsigned version of the zone in another view. Assuming you've not
> overlapped your views in such a way (it was a very contrived test), I think
> you'll need to provide a bit more information on your configuration.
>
> -options
> -relevant view statement
> -The zone statement (from the hashed file if you are using the new dynamic
> zones feature).
> -The zone itself
> -Query logs.
>
> Without the full dig output it is hard to see what is actually happening.
> I'd suggest including that as well.
>
> If you dig axfr or dig rrsig are the signatures present?
>
I've conducted test with 'auto-dnssec allow' and that works without any
single problem, than I just change this options to 'auto-dnssec
maintain' and odd things happen.
Didn't mentioned before but this named is working with SoftHSM. But like
I said no problems with 'auto-dnssec allow'.
this is zone conf:
zone "example" {
type master;
file "var/zone/example";
allow-update { loopback; };
allow-transfer { trusted; loopback; };
auto-dnssec maintain;
key-directory "var/keys/example";
};
named.conf:
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
inet ::1 port 953 allow { ::1; } keys { "rndc-key"; };
};
acl trusted {
127.0.0.1;
172.16.7.5;
};
acl loopback {
127.0.0.1;
};
acl eth0 {
172.16.7.5;
};
options {
directory "/";
query-source address 172.16.7.5;
notify-source 172.16.7.5;
transfer-source 172.16.7.5;
port 53;
pid-file "var/run/named/named.pid";
session-keyfile "var/run/named/session.key";
listen-on {
loopback;
eth0;
};
listen-on-v6 { none; };
recursion no;
notify explicit;
allow-query { trusted; };
dnssec-enable yes;
dnssec-validation yes;
max-journal-size 100k;
random-device "/dev/urandom";
};
this is zone file:
$TTL3600
example.SOA ns1.example. bugs.x.w.example. (
1292481908
7200
3600
734400
600
)
TXT "dnssec test"
NS ns1.example.
NS ns2.example.
$ORIGIN example.
ns1 A 127.0.0.3
ns2 A 127.0.0.4
a NS ns1.a
NS ns2.a
DS 23344 5 1 CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56
ns1.a IN A 127.0.0.1
ns2.a IN A 127.0.0.1
c NS ns1.c
c NS ns2.c
ns1.c IN A 127.0.0.5
ns2.c IN A 127.0.0.6
ai IN A 127.0.0.1
IN 0:0:0:0:0:0:0:1
xx IN A 127.0.0.1
IN 0:0:0:0:0:0:0:1
w IN A 127.0.0.1
*.w MX 10 ai
x.w MX 10 xx
x.y.w MX 10 xx
If I make query for RRSIG records, named is returning proper signatures.
for example for SOA record:
$ dig @127.0.0.1 example rrsig +short
SOA 10 1 3600 20110220123506 20110121113506 51587 example.
cVzWYkeTASPUiHv0DxFXpTsK4G1QkpS3sZ1jXmDCDv+EaYUs2C/kRlD9
same with AXFR, and same for zone file.
- --
regards
zbigniew jasinski
[SYStem OPerator]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNOYSaAAoJEH26UYiRhe/gNmcQALSiNOVoKWBpA/GV1WiarmDt
b+G6NZPBOtXXW4U90XDqL211TUaeXgLfwesRfIERraDxOTtCPjTx9npIoMQMLrWk
F91slmf8thgLpPzFqwe2FxMoagL/HdQ8fXrzHmdMU5Lsg8gBalJyVKL56Hozlp9R
n5LZy8+QBSJHuJKXFIZcBPPCdUW8dEJcONve01ik09gHbwcQzCuqwY7S5vYrDW2s
fZhYQUCvjdBpmf3uKH1yXiqdtUtUerZN3fCB6r4cGIkzYk98iEj5M6fngsBl49vt
SijzWbQftd0ThSxHPcEiuSom4pAuFlxN1O7Al8laIRwgme5wvtUeN+PA8sxr7FWl
cnUC///yLnYJNTJBnbIY0wiWsSTU9H4LU42tnesAKJaIBmaOR9w6QgxLs+E+pyKM
M3pnC//ZqxGirnV9YetV6mqfch23Y08yWcmjTNI8QytEoXPMMaGXyh4IYJFAiMaz
SxV5B9Be1KP1DxO2wyHwDEwrZzIkS5sl1iiaoyb+G0d9dWjuvlSmkDSZA43nYXGS
cn91vMLqUHpYCYVIy3p8w62y7+jOPrIM94vsgONjPijqlB0DZY2JsMP4q2StHUui
cYEqw5NDoCGpxPbnlMJF8FmFmv9R7r+yTPI/O5oR7I4sbhxti3eP0/oDLTlpZDfx
qF6n+qmGBcLll7mn4pUy
=dt7w
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 21/01/11 2:05 PM, "Zbigniew Jasiński" wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> W dniu 2011-01-21 11:23, Kalman Feher pisze:
>> The only way I can replicate the behaviour is with dnssec-enable no or with
>> an unsigned version of the zone in another view. Assuming you've not
>> overlapped your views in such a way (it was a very contrived test), I think
>> you'll need to provide a bit more information on your configuration.
>>
>> -options
>> -relevant view statement
>> -The zone statement (from the hashed file if you are using the new dynamic
>> zones feature).
>> -The zone itself
>> -Query logs.
>>
>> Without the full dig output it is hard to see what is actually happening.
>> I'd suggest including that as well.
>>
>> If you dig axfr or dig rrsig are the signatures present?
>>
>
> I've conducted test with 'auto-dnssec allow' and that works without any
> single problem, than I just change this options to 'auto-dnssec
> maintain' and odd things happen.
>
Perhaps we are getting close to the problem then.
Can you show the content of the key files? Specifically the metadata which
the "maintain" option wants.
Since "allow" works I'm assuming that key file permissions (and directory
permissions) are ok, but it couldn't hurt to check them.
> Didn't mentioned before but this named is working with SoftHSM. But like
> I said no problems with 'auto-dnssec allow'.
>
> this is zone conf:
>
> zone "example" {
> type master;
> file "var/zone/example";
> allow-update { loopback; };
> allow-transfer { trusted; loopback; };
> auto-dnssec maintain;
> key-directory "var/keys/example";
> };
>
> named.conf:
>
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
> inet ::1 port 953 allow { ::1; } keys { "rndc-key"; };
> };
>
> acl trusted {
> 127.0.0.1;
> 172.16.7.5;
> };
>
> acl loopback {
> 127.0.0.1;
> };
>
> acl eth0 {
> 172.16.7.5;
> };
>
> options {
> directory "/";
> query-source address 172.16.7.5;
> notify-source 172.16.7.5;
> transfer-source 172.16.7.5;
> port 53;
> pid-file "var/run/named/named.pid";
> session-keyfile "var/run/named/session.key";
> listen-on {
> loopback;
> eth0;
> };
> listen-on-v6 { none; };
> recursion no;
> notify explicit;
> allow-query { trusted; };
>
> dnssec-enable yes;
> dnssec-validation yes;
> max-journal-size 100k;
> random-device "/dev/urandom";
> };
>
> this is zone file:
>
> $TTL3600
> example.SOA ns1.example. bugs.x.w.example. (
> 1292481908
> 7200
> 3600
> 734400
> 600
> )
> TXT "dnssec test"
> NS ns1.example.
> NS ns2.example.
> $ORIGIN example.
> ns1 A 127.0.0.3
> ns2 A 127.0.0.4
>
> a NS ns1.a
> NS ns2.a
> DS 23344 5 1 CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56
>
> ns1.a IN A 127.0.0.1
> ns2.a IN A 127.0.0.1
>
> c NS ns1.c
> c NS ns2.c
> ns1.c IN A 127.0.0.5
> ns2.c IN A 127.0.0.6
>
> ai IN A 127.0.0.1
> IN 0:0:0:0:0:0:0:1
> xx IN A 127.0.0.1
> IN 0:0:0:0:0:0:0:1
>
> w IN A 127.0.0.1
> *.w MX 10 ai
> x.w MX 10 xx
> x.y.w MX 10 xx
>
> If I make query for RRSIG records, named is returning proper signatures.
> for example for SOA record:
>
> $ dig @127.0.0.1 example rrsig +short
> SOA 10 1 3600 20110220123506 20110121113506 51587 example.
> cVzWYkeTASPUiHv0DxFXpTsK4G1QkpS3sZ1jXmDCDv+EaYUs2C/kRlD9
>
>
> same with AXFR, and same for zone file.
>
> - --
> regards
>
> zbigniew jasinski
> [SYStem OPerator]
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJNOYSaAAoJEH26UYiRhe/gNmcQALSiNOVoKWBpA/GV1WiarmDt
> b+G6NZPBOtXXW4U90XDqL211TUaeXgLfwesRfIERraDxOTtCPjTx9npIoMQMLrWk
> F91slmf8thgLpPzFqwe2FxMoagL/HdQ8fXrzHmdMU5Lsg8gBalJyVKL56Hozlp9R
> n5LZy8+QBSJHuJKXFIZcBPPCdUW8dEJcONve01ik09gHbwcQzCuqwY7S5vYrDW2s
> fZhYQUCvjdBpmf3uKH1yXiqdtUtUerZN3fCB6r4cGIkzYk98iEj5M6fngsBl49vt
> SijzWbQftd0ThSxHPcEiuSom4pAuFlxN1O7Al8laIRwgme5wvtUeN+PA8sxr7FWl
> cnUC///yLnYJNTJBnbIY0wiWsSTU9H4LU42tnesAKJaIBmaOR9w6QgxLs+E+pyKM
> M3pnC//ZqxGirnV9YetV6mqfch23Y08yWcmjTNI8QytEoXPMMaGXyh4IYJFAiMaz
> SxV5B9Be1KP1DxO2wyHwDEwrZzIkS5sl1iiaoyb+G0d9dWjuvlSmkDSZA43nYXGS
> cn91vMLqUHpYCYVIy3p8w62y7+jOPrIM94vsgONjPijqlB0DZY2JsMP4q2StHUui
> cYEqw5N
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-21 15:17, Kalman Feher pisze: >> Perhaps we are getting close to the problem then. >> Can you show the content of the key files? Specifically the metadata which >> the "maintain" option wants. > >> Since "allow" works I'm assuming that key file permissions (and directory >> permissions) are ok, but it couldn't hurt to check them. I've made new instalation without SoftHSM support to be sure that this is not an issue, and of course 'allow' works and 'maintain' the same odd things. permissions are ok, double-checked, and with 'allow' it works. key metadata, same for ZSK and KSK: ; Created: 20110121145849 (Fri Jan 21 15:58:49 2011) ; Publish: 20110121145937 (Fri Jan 21 15:59:37 2011) ; Activate: 20110121170117 (Fri Jan 21 18:01:17 2011) ; Inactive: 20110121220937 (Fri Jan 21 23:09:37 2011) ; Delete: 20110122001117 (Sat Jan 22 01:11:17 2011) and of course I'm waiting until Activate key event to be sure I will get RRSIG in response but there's now signatures. strange thing, that after signing zone with 'maintain' and after named dumps zone into plain file, file differs from this dumped with 'allow' option, much. for example don't have NSEC3PARAM in file from 'maintain' and DS record (authoritative) doesn't have even it's signature! zone with 'maintain' option: $ORIGIN . $TTL 3600 ; 1 hour example IN SOA ns1.example. bugs.x.w.example. ( 1292481918 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 734400 ; expire (1 week 1 day 12 hours) 600; minimum (10 minutes) ) RRSIG SOA 10 1 3600 20110223093216 ( 20110124083216 41870 example. SbFalU9K5yroRNtENT7nQHovxOXhl8ROOi90D77qFEXc NS ns1.example. NS ns2.example. TXT "dnssec test" $TTL 600; 10 minutes NSECa.example. NS SOA TXT RRSIG NSEC DNSKEY TYPE65534 $TTL 3600 ; 1 hour DNSKEY 256 3 10 ( AwEAAdByffBxPaxGFxfnf10TKUIwUKvq79vfMJ9wGW6s ) ; key id = 41870 DNSKEY 257 3 10 ( AwEAAdFituIkCms1lVbht+ykmwRUoBQJjHW9qep2GS1O ) ; key id = 996 RRSIG DNSKEY 10 1 3600 20110223093216 ( 20110124083216 996 example. LXfYVMI7BuQEEvYKpiadeboBHlv1RYv1vaaUoZLwnhC6 RRSIG DNSKEY 10 1 3600 20110223093216 ( 20110124083216 41870 example. $TTL 0 ; 0 seconds TYPE65534 \# 5 ( 0A03E40001 ) TYPE65534 \# 5 ( 0AA38E0001 ) $ORIGIN example. $TTL 3600 ; 1 hour a NS ns1.a NS ns2.a DS 23344 5 1 ( CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56 ) $ORIGIN a.example. ns1 A 127.0.0.1 ns2 A 127.0.0.1 $ORIGIN example. ai A 127.0.0.1 ::1 c NS ns1.c NS ns2.c $ORIGIN c.example. ns1 A 127.0.0.5 ns2 A 127.0.0.6 $ORIGIN example. ns1 A 127.0.0.3 ns2 A 127.0.0.4 w A 127.0.0.1 $ORIGIN w.example. * MX 10 ai.example. x MX 10 xx.example. x.y MX 10 xx.example. $ORIGIN example. xx A 127.0.0.1 ::1 - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNPUwaAAoJEH26UYiRhe/gwDoP/ikpiRA/aLKoufjvUUs3+8OD BKzDUMUoHVQZ5kL+jiS0PA1gabTTL6iCyA7w+Rw6mwFsSM/SWqtjDE2EeKb27wYN osrRvPk6Cszq5W4hOD3PCZe93hcL/MZ8IQxF4qCW3v7XHpHQ7wXyttDC2KkIRcRI VNLaJDjD8MQsK1qAsPL86WXdZCousejUbPPNIc2mYyz/5fhOvCRFZ1ALW8ljuhqd hqM9gbv35d6nXg10yfdkp1nEOz7D25yU6KXhoeX4IOH4+qWvvs3e/zl7EY/BQ66k 4fco8fzkLik3hzAwyqbuBfiEH8/u7LjC8tcrMz3TuTsOdMkolgRVDorLsvKCz1WL eTp+9qe8PNrT5vCXsY7jz5ODgfiiKA9QbtSmAvvVVMnz5h1gBMZUyhLubA/ZCuhI A0UUSltbQo7yyZgfy8UW+3rV2mdyHJJ7wTGMbW0B0uzS59Uks/XIQ5kDDBAo/1fh fPJGPpbN5Ak93B2s/kMdYoCcFNRhLb8TtUGZduL4oZtPbX7stmP/+Nq2ghwyeM4f VlheVVE7GTAUOpkFhu/QxBnO2KIO6RbsTNfoI2vJNrZkmKgffbE4AacgBpktjp5X 7oB7mJifkzT7xSbbcf0AOgyBLuMrrkaa4tK0arzfDtF+0jV
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 24/01/11 10:53 AM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-21 15:17, Kalman Feher pisze: >>> Perhaps we are getting close to the problem then. >>> Can you show the content of the key files? Specifically the metadata which >>> the "maintain" option wants. >> >>> Since "allow" works I'm assuming that key file permissions (and directory >>> permissions) are ok, but it couldn't hurt to check them. > > I've made new instalation without SoftHSM support to be sure that this > is not an issue, and of course 'allow' works and 'maintain' the same odd > things. > > permissions are ok, double-checked, and with 'allow' it works. > > key metadata, same for ZSK and KSK: > > ; Created: 20110121145849 (Fri Jan 21 15:58:49 2011) > ; Publish: 20110121145937 (Fri Jan 21 15:59:37 2011) > ; Activate: 20110121170117 (Fri Jan 21 18:01:17 2011) > ; Inactive: 20110121220937 (Fri Jan 21 23:09:37 2011) > ; Delete: 20110122001117 (Sat Jan 22 01:11:17 2011) > > and of course I'm waiting until Activate key event to be sure I will get > RRSIG in response but there's now signatures. > > strange thing, that after signing zone with 'maintain' and after named > dumps zone into plain file, file differs from this dumped with 'allow' > option, much. for example don't have NSEC3PARAM in file from 'maintain' > and DS record (authoritative) doesn't have even it's signature! I assume you did add the nsec3param record via nsupdate after adding the zone? I note that there is an NSEC entry there, which is not right. > > zone with 'maintain' option: > > $ORIGIN . > $TTL 3600 ; 1 hour > example IN SOA ns1.example. bugs.x.w.example. ( > 1292481918 ; serial > 7200 ; refresh (2 hours) > 3600 ; retry (1 hour) > 734400 ; expire (1 week 1 day 12 hours) > 600; minimum (10 minutes) > ) > RRSIG SOA 10 1 3600 20110223093216 ( > 20110124083216 41870 example. > SbFalU9K5yroRNtENT7nQHovxOXhl8ROOi90D77qFEXc > > NS ns1.example. > NS ns2.example. > TXT "dnssec test" > $TTL 600; 10 minutes > NSECa.example. NS SOA TXT RRSIG NSEC DNSKEY > TYPE65534 > $TTL 3600 ; 1 hour > DNSKEY 256 3 10 ( > AwEAAdByffBxPaxGFxfnf10TKUIwUKvq79vfMJ9wGW6s > ) ; key id = 41870 > DNSKEY 257 3 10 ( > AwEAAdFituIkCms1lVbht+ykmwRUoBQJjHW9qep2GS1O > ) ; key id = 996 > RRSIG DNSKEY 10 1 3600 20110223093216 ( > 20110124083216 996 example. > LXfYVMI7BuQEEvYKpiadeboBHlv1RYv1vaaUoZLwnhC6 > RRSIG DNSKEY 10 1 3600 20110223093216 ( > 20110124083216 41870 example. > $TTL 0 ; 0 seconds > TYPE65534 \# 5 ( 0A03E40001 ) > TYPE65534 \# 5 ( 0AA38E0001 ) > $ORIGIN example. > $TTL 3600 ; 1 hour > a NS ns1.a > NS ns2.a > DS 23344 5 1 ( > CECDDBFFD6A0C01F8D7E96C4BE31CB577433DD56 ) > $ORIGIN a.example. > ns1 A 127.0.0.1 > ns2 A 127.0.0.1 > $ORIGIN example. > ai A 127.0.0.1 > ::1 > c NS ns1.c > NS ns2.c > $ORIGIN c.example. > ns1 A 127.0.0.5 > ns2 A 127.0.0.6 > $ORIGIN example. > ns1 A 127.0.0.3 > ns2 A 127.0.0.4 > w A 127.0.0.1 > $ORIGIN w.example. > * MX 10 ai.example. > x MX 10 xx.example. > x.y MX 10 xx.example. > $ORIGIN example. > xx A 127.0.0.1 > ::1 > - -- I cut and paste the zone (except for DS) and loaded it, added nsec3param, then signed and it went perfectly. I then added an a.example zone and did the same thing. I took the resulting dsset and added it into example using nsupdate and it was signed within moments. Are you following this same workflow? FWIW I use a script to add all my test zones from a zone template file. That script automatically adds the nsec3param as soon as the zone is loaded, but before it signs. That way
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-24 14:34, Kalman Feher pisze: > I assume you did add the nsec3param record via nsupdate after adding the > zone? I note that there is an NSEC entry there, which is not right. > Yes, with nsupdate. and lack of NSEC3PARAM was very odd. > Are you following this same workflow? > FWIW I use a script to add all my test zones from a zone template file. That > script automatically adds the nsec3param as soon as the zone is loaded, but > before it signs. That way I keep things simple and never forget to update > that zone before signing. I made few more tests and what I've understand you have to have at least one key in 'Activate' state. for example: the same example zone, generated keys with future Prepublish and Activate event, adding NSEC3PARAM via nsupdate: Jan 24 15:28:36 named[15837]: update: client 127.0.0.1#8917: updating zone 'example/IN': adding an RR at 'example' NSEC3PARAM Jan 24 15:28:36 named[15837]: general: zone example/IN: dns_zone_addnsec3chain(hash=1, iterations=12, salt=19CC44675CFB020065B1) Jan 24 15:28:36 named[15837]: general: zone example/IN: zone_addnsec3chain(1,CREATE,12,19CC44675CFB020065B1) now I want named to read the key timings from key files so I make 'rndc sign example': Jan 24 15:28:37 named[15837]: general: received control channel command 'sign example' Jan 24 15:28:37 named[15837]: general: zone example/IN: reconfiguring zone keys Jan 24 15:28:37 named[15837]: general: zone example/IN: zone_addnsec3chain(1,REMOVE|NONSEC,12,19CC44675CFB020065B1) Jan 24 15:28:37 named[15837]: general: zone example/IN: next key event: 24-Jan-2011 15:29:36.860 Jan 24 15:29:36 named[15837]: general: zone example/IN: reconfiguring zone keys Jan 24 15:29:36 named[15837]: general: zone example/IN: next key event: 24-Jan-2011 16:29:36.886 and my NSEC3PARAM record is removed! and my question is why? why can't I have NSEC3PARAM record in my zone before signing it?? If I wait until 'Activate' event (16:29:36.886 - for this particular test) I will get strangely looking signed zone (which I attached in my previous emails) without my NSEC3PARAM record. - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNPZXVAAoJEH26UYiRhe/gPDwP/2kxlk5ct9hpffP94tAUgx/F R61tr9IA1mSAkHkN6zJh7GYRgNSxllI4s+h41FXYBhlknpARdcobfm2ybdkReojm llaTIQtqcgh+7vRq/MK9zH3MwWglhatuQFENUwTpy38zccRwSAQhtN+XDUi2TpVq VS0tjpAqZb0/hpz9pb4Bxu1uNzpRUehiRcjhg0l2ocsBg/32FQ4xSDr3ViMNHgeA 0a+xIRkp9gK5DsUUCPlpkQBBr7ICyvl/M4t3RPUOr3zf7tzUX81TrNLF1PeHC/kh gR8Hz+94MceVdgVIaRNWUpj5wvYVRuz9DEdp9li124kk4hyATh+Qo1Bk1ZrreoNa AxqO/qVqtRz7xpRSdjvOcsNrJ7/5dJltfp/Mv7wC0xXgz/DR84xiFvpy21JAEJIa W0D7lCSixF3B8WV90vKevJGSCWSi0ipLANuckO4oHzhTyVk0RQmV/iGZjneWwJpV KJWuTSa1sffk2QXI3ikwH5WKLyKaXmOCG5ZkEmLc8OO70WSkuWlsbt2oGGRAgGVd b8uYtr6NrJdJBhAU5KgcEHiOY6g9Wv6ffC63XS1LMC9b/Tnp5DXHnK8VG5og6NwO vjgJu5SwyuijAl+VIWlnnenxNBy4vB4OSrht0sC+JvzN360/sSSLE3fzHpFwMTGq D1zWmxkyD645F6od2RJ/ =iWfG -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 24/01/11 4:08 PM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-24 14:34, Kalman Feher pisze: >> I assume you did add the nsec3param record via nsupdate after adding the >> zone? I note that there is an NSEC entry there, which is not right. >> > > Yes, with nsupdate. and lack of NSEC3PARAM was very odd. > >> Are you following this same workflow? >> FWIW I use a script to add all my test zones from a zone template file. That >> script automatically adds the nsec3param as soon as the zone is loaded, but >> before it signs. That way I keep things simple and never forget to update >> that zone before signing. > > I made few more tests and what I've understand you have to have at least > one key in 'Activate' state. > > for example: > > the same example zone, generated keys with future Prepublish and > Activate event, adding NSEC3PARAM via nsupdate: > > Jan 24 15:28:36 named[15837]: update: client 127.0.0.1#8917: updating > zone 'example/IN': adding an RR at 'example' NSEC3PARAM > Jan 24 15:28:36 named[15837]: general: zone example/IN: > dns_zone_addnsec3chain(hash=1, iterations=12, salt=19CC44675CFB020065B1) > Jan 24 15:28:36 named[15837]: general: zone example/IN: > zone_addnsec3chain(1,CREATE,12,19CC44675CFB020065B1) > > now I want named to read the key timings from key files so I make 'rndc > sign example': > > Jan 24 15:28:37 named[15837]: general: received control channel command > 'sign example' > Jan 24 15:28:37 named[15837]: general: zone example/IN: reconfiguring > zone keys > Jan 24 15:28:37 named[15837]: general: zone example/IN: > zone_addnsec3chain(1,REMOVE|NONSEC,12,19CC44675CFB020065B1) This appears to be the problem. I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could not replicate it. Try turning up the logging to get more information about why the nsec3param is removed. Make sure also that your keys are nsec3 compatible and you don't have any old non nsec3 keys in the directory that could be used to sign. > Jan 24 15:28:37 named[15837]: general: zone example/IN: next key event: > 24-Jan-2011 15:29:36.860 > Jan 24 15:29:36 named[15837]: general: zone example/IN: reconfiguring > zone keys > Jan 24 15:29:36 named[15837]: general: zone example/IN: next key event: > 24-Jan-2011 16:29:36.886 > > and my NSEC3PARAM record is removed! and my question is why? why can't I > have NSEC3PARAM record in my zone before signing it?? > > If I wait until 'Activate' event (16:29:36.886 - for this particular > test) I will get strangely looking signed zone (which I attached in my > previous emails) without my NSEC3PARAM record. > > - -- > regards > > zbigniew jasinski > [SYStem OPerator] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJNPZXVAAoJEH26UYiRhe/gPDwP/2kxlk5ct9hpffP94tAUgx/F > R61tr9IA1mSAkHkN6zJh7GYRgNSxllI4s+h41FXYBhlknpARdcobfm2ybdkReojm > llaTIQtqcgh+7vRq/MK9zH3MwWglhatuQFENUwTpy38zccRwSAQhtN+XDUi2TpVq > VS0tjpAqZb0/hpz9pb4Bxu1uNzpRUehiRcjhg0l2ocsBg/32FQ4xSDr3ViMNHgeA > 0a+xIRkp9gK5DsUUCPlpkQBBr7ICyvl/M4t3RPUOr3zf7tzUX81TrNLF1PeHC/kh > gR8Hz+94MceVdgVIaRNWUpj5wvYVRuz9DEdp9li124kk4hyATh+Qo1Bk1ZrreoNa > AxqO/qVqtRz7xpRSdjvOcsNrJ7/5dJltfp/Mv7wC0xXgz/DR84xiFvpy21JAEJIa > W0D7lCSixF3B8WV90vKevJGSCWSi0ipLANuckO4oHzhTyVk0RQmV/iGZjneWwJpV > KJWuTSa1sffk2QXI3ikwH5WKLyKaXmOCG5ZkEmLc8OO70WSkuWlsbt2oGGRAgGVd > b8uYtr6NrJdJBhAU5KgcEHiOY6g9Wv6ffC63XS1LMC9b/Tnp5DXHnK8VG5og6NwO > vjgJu5SwyuijAl+VIWlnnenxNBy4vB4OSrht0sC+JvzN360/sSSLE3fzHpFwMTGq > D1zWmxkyD645F6od2RJ/ > =iWfG > -END PGP SIGNATURE- > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 W dniu 2011-01-24 17:47, Kalman Feher pisze: > This appears to be the problem. > I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could > not replicate it. Try turning up the logging to get more information about > why the nsec3param is removed. Make sure also that your keys are nsec3 > compatible and you don't have any old non nsec3 keys in the directory that > could be used to sign. I was trying to reproduce your scheme: > FWIW I use a script to add all my test zones from a zone template file. That > script automatically adds the nsec3param as soon as the zone is loaded, but > before it signs. That way I keep things simple and never forget to update > that zone before signing. but without success. did you use keys with future Prepublish and Activate or it's set to NOW? I made few tests: - -- first scenario (desirable): 1. get unsigned zone 2. generate nsec3 compatible keys (Prepublish and Activate in the future) 3. send 'rndc sign' to named 4. send NSEC3PARAM via dynamic update result: after waiting until key Activate event: 1. SOA and DNSKEY records are signed and have RRSIG records 2. NSEC3PARAM and DS records are still unsigned which is not proper signed zone. - -- second scenario: 1. get unsigned zone with NSEC3PARAM record 2. generate nsec3 compatible keys (Prepublish and Activate in the future) 3. send 'rndc sign' to named result: 1. NSEC3PARAM is immediately removed from zone after waiting until key Activate event: 1. SOA and DNSKEY records are signed and have RRSIG records but in zone file. can't get RRSIG records with dns response. only if I send query for RRSIG records - -- third scenario: 1. get unsigned zone 2. generate nsec3 compatible keys (Prepublish and Activate = NOW) 3. send NSEC3PARAM via dynamic update 4. send 'rndc sign' to named result: everything is ok. one conclusion: you need to have at least one key in Activate state. as for me this is wrong assumption. first scenario should be ok but strange things happened after Activate event or I made a mistake. - -- regards zbigniew jasinski [SYStem OPerator] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNPtF7AAoJEH26UYiRhe/gReoP/j9fMxut/d7B5g4n86X2xiu/ GxvHbLiCMzxmJvIJG0tx2WuMYddiWBT+Jpv3sRimhdXY5zuALYK/n9Kig6r9GcCj P12fH5CgDR/G5EP0ll254JeEGv34M4v7ZlUEU1ffZK14b+/RGNFZloSZ4wyBTcWv aqcqUOnd0a7g2sRsDk3I9T3MSla9sYBKeh4/CLQlmIyDWIHG4L3X9Nr6HWwj9hZv 0Oeu60eY6C/pLGptsHhax/dxmE+ZanQ2Dtrq5eTxFtyUT6TBFMKrZbpBuNjfq0QK M2GRwEiILujx5g5u/eWgfggd+aPWjafkn1hskxaSJfSZ6uni8f+sKiRnR3HFkVkN vLrgLdyVoNL4PsChvLu8eyPsLbaJTx6UagovIw5EEvAaWIyKrw6Hf8YxwjvI95uF wBphk118zw7SXxchyJaDIT2cyxUtWDt3spou6mq7Mi45CdAj47ekVoc8txcUW6mW MhgIQi+U+7XcbzfhxRiQoGeuSkRnJ5o3TlJNsgzKjDwZdqHRMxuDI+Mh87ZjJXa2 gVZAX2INWy3pEAmVEPy84ci1iRrgns7buzv7no5AG8oBpZEHzr0DOhy+XCpCCjND w6vulBKlraEPC5cTK3HoOC8lxXWixF86q4xmIZ8KXIAOPvARJkTa92Mia9/XVrER gZfMc3kS3UWIBZoJAKeq =IR/F -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 25/01/11 2:34 PM, "Zbigniew Jasiński" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > W dniu 2011-01-24 17:47, Kalman Feher pisze: >> This appears to be the problem. >> I copied your NSEC3PARAM (opt out clear, 12 iterations) details but could >> not replicate it. Try turning up the logging to get more information about >> why the nsec3param is removed. Make sure also that your keys are nsec3 >> compatible and you don't have any old non nsec3 keys in the directory that >> could be used to sign. > > > I was trying to reproduce your scheme: > >> FWIW I use a script to add all my test zones from a zone template > file. That >> script automatically adds the nsec3param as soon as the zone is > loaded, but >> before it signs. That way I keep things simple and never forget to update >> that zone before signing. > > but without success. did you use keys with future Prepublish and > Activate or it's set to NOW? > > I made few tests: > > - -- first scenario (desirable): > > 1. get unsigned zone > 2. generate nsec3 compatible keys (Prepublish and Activate in the future) > 3. send 'rndc sign' to named > 4. send NSEC3PARAM via dynamic update If you swap steps 3 and 4 you'll be ok. That is assuming your sign is issued at the point in future after your activate date (activate saying that the key should now be used to sign rather than just be present for caching). Done in that order, my test worked fine, including DS signing whenever a DS was added (along with any other new record). > > result: > > after waiting until key Activate event: > > 1. SOA and DNSKEY records are signed and have RRSIG records > 2. NSEC3PARAM and DS records are still unsigned This is symptomatic of the broken automatic signing. I suspect any new record would not be signed. Give it a try just in case. > > which is not proper signed zone. > > - -- second scenario: > > 1. get unsigned zone with NSEC3PARAM record > 2. generate nsec3 compatible keys (Prepublish and Activate in the future) > 3. send 'rndc sign' to named > > result: > > 1. NSEC3PARAM is immediately removed from zone If you issue sign before the key is active, you're not going to be able to sign properly. I'm not sure why nsec3param is removed, but it probably is due to the aborted automated signing. > > after waiting until key Activate event: > > 1. SOA and DNSKEY records are signed and have RRSIG records but in zone > file. can't get RRSIG records with dns response. only if I send query > for RRSIG records If the nsec3param has been removed, the automated signing will be weird if you are using nsec3 keys. I havent tested this scenario, since it isnt really a working scenario. > > - -- third scenario: > > 1. get unsigned zone > 2. generate nsec3 compatible keys (Prepublish and Activate = NOW) > 3. send NSEC3PARAM via dynamic update > 4. send 'rndc sign' to named > > result: > > everything is ok. > > one conclusion: you need to have at least one key in Activate state. as > for me this is wrong assumption. first scenario should be ok but strange > things happened after Activate event or I made a mistake. Yes this is the correct scenario. Activate is when you plan on using that key to sign. Issuing sign without an active key doesn't really make sense. Noting of course that the meta data is only used by the automated signing logic within BIND. So you can always use any key to sign manually. However I think this may have mislead you regarding the purpose of the meta data. The best way to think of keys in DNSSEC is in groups of threes. Keys in the past, keys in the future and keys in the present. Keys in the past don't matter for your first signing. Keys in the present are used for signing _right now_. That means they need to be active and published. Keys in the future will be used to sign, so they should ideally be published before hand. You may also need to apply some parent publishing logic (has my registry accepted my DS, has it published in the parent zone) for the exact time difference between publish and activate. Most organisations simply leave a large gap (a month or two) between publish and activate for KSKs as a result. With that in mind, your first time signing should be: 1.Create nsec3 compatible keys. Ideally a pair for now and a pair for the future (the future pair can wait however). -Personally my "now" keys are actually set as active and publish in the past. -My future keys are created on a set schedule with publish dates a few days before their active dates (this is the test system, production systems need longer times). 2.If zone is not already locally dynamically managed, do so now. 3.NSEC3PARAM is added 4.Sign is issued for the first and last time (if you are using "maintain"). -The active keys are used to sign and will continue to be used until they are no longer active. -Key directory will be checked as key events approach and keys will be published and made active according to their meta data. For the exact timing aroun
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 1/25/2011 9:51 AM, Kalman Feher wrote: > If the nsec3param has been removed, the automated signing will be weird if > you are using nsec3 keys. I havent tested this scenario, since it isnt > really a working scenario. There is no such thing as an "nsec3 key". If you auto-sign a zone that does not contain an NSEC3PARAM record, the zone will be signed using NSEC. [note that I'm leaving the rest of that mail to be responded to by someone with more intimate knowledge of the auto-signing mechanism] AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 25/01/11 4:10 PM, "Alan Clegg" wrote: > On 1/25/2011 9:51 AM, Kalman Feher wrote: > >> If the nsec3param has been removed, the automated signing will be weird if >> you are using nsec3 keys. I havent tested this scenario, since it isnt >> really a working scenario. > > There is no such thing as an "nsec3 key". Sorry, I was a little sloppy with my vernacular. I meant the algorithm used to create the keys in question. ie using -3 in dnssec-keygen. > > If you auto-sign a zone that does not contain an NSEC3PARAM record, the > zone will be signed using NSEC. That was the observed behaviour of the OP, which wasn't their preference. Hence the need to add and retain said nsec3param in this instance. > > [note that I'm leaving the rest of that mail to be responded to by > someone with more intimate knowledge of the auto-signing mechanism] > > AlanC > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
In message , Kalman Feher write s: > > > > On 25/01/11 4:10 PM, "Alan Clegg" wrote: > > > On 1/25/2011 9:51 AM, Kalman Feher wrote: > > > >> If the nsec3param has been removed, the automated signing will be weird if > >> you are using nsec3 keys. I havent tested this scenario, since it isnt > >> really a working scenario. > > > > There is no such thing as an "nsec3 key". > Sorry, I was a little sloppy with my vernacular. > I meant the algorithm used to create the keys in question. ie using -3 in > dnssec-keygen. And *all* keys that support NSEC3 are also NSEC capable. There isn't such a thing as a NSEC3 key. There are NSEC3 capable keys and keys that are not NSEC3 capable. All keys are NSEC capable. As for the NSEC3PARAM going away it is only supposed to exist in a *signed* zone and you are attempting to add it to a unsigned zone. The key timing are there for managing keys in a already signed zone. You are attempting to use them to start signing the zone which requires as whole different set of steps to be done. To get named to convert a unsigned zone to a signed zone with NSEC3 use nsupdate to add the DNSKEYs and NSEC3PARAM record in the same UPDATE request. > > If you auto-sign a zone that does not contain an NSEC3PARAM record, the > > zone will be signed using NSEC. > That was the observed behaviour of the OP, which wasn't their preference. > Hence the need to add and retain said nsec3param in this instance. > > > > > [note that I'm leaving the rest of that mail to be responded to by > > someone with more intimate knowledge of the auto-signing mechanism] > > > > AlanC > > > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > -- > Kal Feher > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC auto-dnssec issue bind-9.7.2-P3
On 25/01/11 11:20 PM, "Mark Andrews" wrote: > > In message , Kalman Feher > write > s: >> >> >> >> On 25/01/11 4:10 PM, "Alan Clegg" wrote: >> >>> On 1/25/2011 9:51 AM, Kalman Feher wrote: >>> If the nsec3param has been removed, the automated signing will be weird if you are using nsec3 keys. I havent tested this scenario, since it isnt really a working scenario. >>> >>> There is no such thing as an "nsec3 key". >> Sorry, I was a little sloppy with my vernacular. >> I meant the algorithm used to create the keys in question. ie using -3 in >> dnssec-keygen. > > And *all* keys that support NSEC3 are also NSEC capable. There > isn't such a thing as a NSEC3 key. There are NSEC3 capable keys > and keys that are not NSEC3 capable. All keys are NSEC capable. I don't think this was in question. But it is always useful to have it explicitly stated. Though hopefully this wont muddy the waters, since it is the complete opposite of what OP was trying to do. > > As for the NSEC3PARAM going away it is only supposed to exist in a > *signed* zone and you are attempting to add it to a unsigned zone. Good point. However I note that it definitely _does_ work when added to an unsigned zone, which following an rndc sign, (with caveats of appropriately created keys ) will result in an nsec3 signed zone. This is also the workflow documented in Alan's nanog presentation (the slide titled "Create & Sign (NSEC3)"). If that isn't ideal, it would be useful to know why. And also why it does work for now. Does it only work when done in rapid succession? > > The key timing are there for managing keys in a already signed zone. > You are attempting to use them to start signing the zone which > requires as whole different set of steps to be done. > > To get named to convert a unsigned zone to a signed zone with NSEC3 > use nsupdate to add the DNSKEYs and NSEC3PARAM record in the same > UPDATE request. > >>> If you auto-sign a zone that does not contain an NSEC3PARAM record, the >>> zone will be signed using NSEC. >> That was the observed behaviour of the OP, which wasn't their preference. >> Hence the need to add and retain said nsec3param in this instance. >> >>> >>> [note that I'm leaving the rest of that mail to be responded to by >>> someone with more intimate knowledge of the auto-signing mechanism] I believe this was the original issue with OP. There seemed to be a misunderstanding of the purpose of the activate value. Specifically, expecting that the zone would automatically sign updates (the DS in this case) prior to the activate time. >>> >>> AlanC >>> >>> ___ >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users >> >> -- >> Kal Feher >> >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
