Upgrading from 9.6 to 9.7

[Mark Andrews]

In message <A5C84BCC694045308CAFD4F5989AA44F at sb.litts.net>, "Timothe Litt" writ
es:
> Thanks - a couple of clarifying questions..
> 
> From: Mark Andrews [mailto:marka at isc.org] 
> Sent: Monday, September 06, 2010 19:57
> To: Timothe Litt
> Cc: bind-users at isc.org
> Subject: Re: Upgrading from 9.6 to 9.7
> 
> 
> In message <A312010A27F14658B095B6523E39B920 at sb.litts.net>, "Timothe Litt"
> writ
> es:
> > I've been running 9.6-ESV-R1 and 9.6.1-P3 with 
> > "-DALLOW_INSECURE_TO_SECURE -DALLOW_SECURE_TO_INSECURE" serving DNSSEC 
> > zones on several servers - all linux, some FC13, others on ARM embedded
> systems.
> 
> >> -DALLOW_INSECURE_TO_SECURE is always allowed.
> 
> >> -DALLOW_SECURE_TO_INSECURE is a named.conf option
> >>	dnssec-secure-to-insecure <boolean>;
>  
> > Is there any documentation for what I need to do to convert from this 
> > interim dnssec auto-signing mechanism to the 9.7.1-P2 release?
> 
> >> Just allow keys changes to become stable, then remove the
> sig-signing-type records.
> These are the TYPE 65534 records?  E.g. dig axfr reports these:
>    example.com. 0     IN      TYPE65534 \# 5 0797800001

The last octet is non zero which indicates named has finished processing
the matching DNSKEY record.

> How can I tell that key changes are 'stable'?  (The only changes going on at
> present
> are the automagic re-signing. (sig-validity-interval 8 2; + dhcp updates)
> 
> Will nsupdate allow me to delete these?

Yes.  "update delete example.com type65534".  named won't delete then
records it is still using.

>  (all the zones are, of course, dynamic)
> The ARM (p 24) seems to indicate that bind 9.7 still uses them - are you
> saying that I 
> need to delete them under the old version before starting the new?  

Yes.  You should be deleting them anyway.  They are only left around so
that you are reminded to do whatever the next step is once the signing
completes. e.g. add DS to parent zone, add DLV record.
 
> This would a bit tricky, since as long as the master is up, dhcp and other
> DDNS updates 
> will arrive at unpredictable times - and of course that triggers resigning.

DHCP doesn't add/remove DNSKEYs.  These records are only created when adding /
removing DNSKEYs (and NSEC3PARAM records in 9.7).

> If the master
> is down - I guess I could axfr from one of the slaves to get a consistent
> copy.  But
> if I restart the master with those files (dozens of them), I'd have to
> delete the
> journals - would state then be lost?  Or do the slaves have everything
> required?

> > Are there interoperability issues between these versions?
> 
> >> No.
> So would you suggest upgrading the slaves before the master, or the master
> first?
> And I can use my existing key-directory (ies - 1/view)  and zone/journal
> files - no 
> changes required?
> 
> > To make life more interesting, I not only want to update all my 
> > servers, but also must move the master server to a new host - with 
> > selinux (fedora core 13).
> > 
> > Is there any 'getting started' presentation (esp for DNSEC) on 9.7?  
> > There was a "DNSSEC in (a few) minutes" presentation for bind, but I 
> > haven't seen an update for 97.  The ARM is great reference, but not 
> > easy to decipher for upgrade situations...
> 
> >> Read up on "rndc sign" and "auto-dnssec".  9.7 also introduced
> "managed-keys"
> >> for setting up trusted keys which are using RFC 5011 management
> techniques.
> 
> I'm looking forward to these - once I understand how they work and how to
> get
> them to do the most magic for me... And how to get the rest into my web gui
> & cron -
> E.g. I want to end up with a button that says "roll key for this zone", with
> all
> the delays and key generation and adds and removes just happening...
> 
> > (I'd be happy to move this to dnssec-deployment if the concensus is 
> > that it belongs there.)
> > 
> > Thanks.
> > 
> > ---------------------------------------------------------
> > This communication may not represent my employer's views, if any, on 
> > the matters discussed.
> >  
> > 
> > _______________________________________________
> > bind-users mailing list
> > bind-users at 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: marka at isc.org
> 
> _______________________________________________
> bind-users mailing list
> bind-users at 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: marka at isc.org