DNSSEC auto-dnssec issue bind-9.7.2-P3

Tue Jan 25 14:51:19 UTC 2011

On 25/01/11 2:34 PM, "Zbigniew Jasiński" <szopen at nask.pl> 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
around this check the BIND ARM for 9.7 which has an explanation of the
calculations.

HTH

> 
> - -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher 