Re: SOA record not signed with new key at key-rollover

2016-07-18 Thread Nis Wechselberg 
Am 18.07.2016 um 12:48 schrieb Tony Finch:
> If your rollover time is much shorter then you are testing something that
> is more like an emergency unplanned rollover.

At the moment I am merely testing in this "high-frequency" setup to get
a good feeling for the mechanics and the interaction between the tools.

I understand that this is not the correct approach for a stable zone.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SOA record not signed with new key at key-rollover

2016-07-18 Thread Tony Finch 
Nis Wechselberg  wrote:

> Am I getting it right that the rest of the zone is not (re)signed
> because the current signature is still valid for some time?
>
> So if I were to set sig-validity-interval to a shorter value, this would
> help with the issue?

If you are testing out a fast rollover schedule then it would make sense
to set a short sig-validity-interval, scaled to match.

If your rollover time is much shorter then you are testing something that
is more like an emergency unplanned rollover.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Southerly, becoming variable, 3 or 4, occasionally 5 at first in
west. Smooth or slight. Fog banks. Moderate or good, occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SOA record not signed with new key at key-rollover

2016-07-17 Thread Nis Wechselberg 
Hi,

you are right, I got confused there.
Am I getting it right that the rest of the zone is not (re)signed
because the current signature is still valid for some time?

So if I were to set sig-validity-interval to a shorter value, this would
help with the issue?
Sadly it seems to be a value in days, so it is not that easy to test.
I will try setting the interval to 1 day with 23 hours preview signing.

Thanks.

Am 17.07.2016 um 06:06 schrieb Mark Andrews:
> In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes:
>> Hi,
>>
>> I am curently testing a dnssec setup with the new dnssec-keymgr tool. I
>> created a test zone with very fast key rollover setings and very short
>> TTLs. (Configs below)
>>
>> The automated creation of keys seems to work fine but bind behaves other
>> than I would have expected.
>>
>> - Initial deployment looks fine with the current ZSK published and in use.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/)
> 
> ZSK = 36141
>  
>> - At prepublication time the next key is published but not yet used (as
>> expected.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/)
> 
> New ZSK is 10173
> 
>> - After rollover time the new key is used to sign the zone EXCEPT the
>> SOA record. This one is still signed by the old key.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/)
> 
> No.  The new ZSK signs the SOA record.  The old signatures still exist
> on the other records as the only RRset that changes is the SOA.
>  
>> - When post-publication of the old key expires it is removed and the new
>> key is used for all records.
>> (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/)
>>
>>
>> I am confused becaus of the special treatment of the SOA record. I would
>> expect a complete switch to the new key. At the moment, cached responses
>> of the SOA record could not be verified in the timeframe between
>> deletion of the old key and the next TTL.
>>
>> Am I missing something?
>>
>> Regards,
>> Nis
>>
>> 
>>
>>
>> dnssec-keymgr policy:
>>
>> zone testmichhartundwild.de {
>>   algorithm RSASHA256;
>>   directory "/etc/bind/zones/keys";
>>   coverage 2d;
>>   keyttl 600;
>>   roll-period zsk 8h;
>>   post-publish zsk 2h;
>>   pre-publish zsk 2h;
>> };
>>
>>
>> bind zone config:
>>
>> zone "testmichhartundwild.de" IN {
>>   type master;
>>
>>   file "de/testmichhartundwild.de/zone.db";
>>
>>   // Allow zone transfers to trusted servers
>>   allow-transfer {
>> myServers;
>> localhost;
>>   };
>>
>>   // Allow updates with shared key
>>   update-policy {
>> grant morpheus-trinity. zonesub any;
>>   };
>>   serial-update-method unixtime;
>>
>>   // Activate dnssec for this domain
>>   key-directory "keys";
>>   auto-dnssec maintain;
>> };
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>>  from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SOA record not signed with new key at key-rollover

2016-07-16 Thread Mark Andrews 

In message <5788c969.6070...@enbewe.de>, Nis Wechselberg writes:
> Hi,
> 
> I am curently testing a dnssec setup with the new dnssec-keymgr tool. I
> created a test zone with very fast key rollover setings and very short
> TTLs. (Configs below)
> 
> The automated creation of keys seems to work fine but bind behaves other
> than I would have expected.
> 
> - Initial deployment looks fine with the current ZSK published and in use.
> (http://dnsviz.net/d/testmichhartundwild.de/V4ep6A/dnssec/)

ZSK = 36141
 
> - At prepublication time the next key is published but not yet used (as
> expected.
> (http://dnsviz.net/d/testmichhartundwild.de/V4fV_A/dnssec/)

New ZSK is 10173

> - After rollover time the new key is used to sign the zone EXCEPT the
> SOA record. This one is still signed by the old key.
> (http://dnsviz.net/d/testmichhartundwild.de/V4fyNQ/dnssec/)

No.  The new ZSK signs the SOA record.  The old signatures still exist
on the other records as the only RRset that changes is the SOA.
 
> - When post-publication of the old key expires it is removed and the new
> key is used for all records.
> (http://dnsviz.net/d/testmichhartundwild.de/V4gSGg/dnssec/)
> 
> 
> I am confused becaus of the special treatment of the SOA record. I would
> expect a complete switch to the new key. At the moment, cached responses
> of the SOA record could not be verified in the timeframe between
> deletion of the old key and the next TTL.
> 
> Am I missing something?
> 
> Regards,
> Nis
> 
> 
> 
> 
> dnssec-keymgr policy:
> 
> zone testmichhartundwild.de {
>   algorithm RSASHA256;
>   directory "/etc/bind/zones/keys";
>   coverage 2d;
>   keyttl 600;
>   roll-period zsk 8h;
>   post-publish zsk 2h;
>   pre-publish zsk 2h;
> };
> 
> 
> bind zone config:
> 
> zone "testmichhartundwild.de" IN {
>   type master;
> 
>   file "de/testmichhartundwild.de/zone.db";
> 
>   // Allow zone transfers to trusted servers
>   allow-transfer {
> myServers;
> localhost;
>   };
> 
>   // Allow updates with shared key
>   update-policy {
> grant morpheus-trinity. zonesub any;
>   };
>   serial-update-method unixtime;
> 
>   // Activate dnssec for this domain
>   key-directory "keys";
>   auto-dnssec maintain;
> };
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> 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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users