DNSSEC migration sanity check

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

DNSSEC migration sanity check

Bind-Users forum mailing list

We are in the process of moving from one IPAM vendor to another.

 

All of our zones are DNSSEC signed and the TTL’s have been lowered to 300 seconds.

 

At a high level, the playbook is to update the registrar with names/IP addresses of the new servers and update the DSKEY.  Depending on the time of the day that the cutover actually happens at we know the process to request of the registrar an out of band data push so the new servers will be seen by the open Internet.

 

A suggestion have been put forth that we should unsign our zones prior to migration but I am skeptical of the benefits of doing so.

 

Are we missing something obvious?

 

John


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DNSSEC migration sanity check

Crist Clark
Not sure I understand why you need to do anything except change the
authoritative NS records in the zone and in the delegation at the
registrar. You also only really need to decrease the TTL on the NS
records, not all of the records in the zone. Why touch any keys and
the corresponding DS records?

Are we missing some complication in your deployment?

On Wed, Aug 19, 2020 at 11:44 AM John W. Blue via bind-users
<[hidden email]> wrote:

>
> We are in the process of moving from one IPAM vendor to another.
>
>
>
> All of our zones are DNSSEC signed and the TTL’s have been lowered to 300 seconds.
>
>
>
> At a high level, the playbook is to update the registrar with names/IP addresses of the new servers and update the DSKEY.  Depending on the time of the day that the cutover actually happens at we know the process to request of the registrar an out of band data push so the new servers will be seen by the open Internet.
>
>
>
> A suggestion have been put forth that we should unsign our zones prior to migration but I am skeptical of the benefits of doing so.
>
>
>
> Are we missing something obvious?
>
>
>
> John
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DNSSEC migration sanity check

Matthijs Mekking
In reply to this post by Bind-Users forum mailing list
Hi John,

It all depends on the key material that is used to sign your zone. It
looks like you have to update the DNSKEY RRset, so I assume the vendors
are responsible for signing and each have their own key material.

In order to let the world know you are going to use new keys you will
have to pre-publish them in your zone. The DNSKEY RRset should be the
same in both versions of the zone . Also introduce the new NS records in
the child zone at the losing vendor.

Approximately one TTL (300 seconds in your case) later the new DNSKEY
RRset should be propagated and you can swap the DS and NS at the parent.
And when the DS and NS records of the one vendor have expired you can
remove the old key material from the zone.

For a bit more background on this you can take a look at
https://tools.ietf.org/html/rfc6781#section-4.3.5

In most cases there is no need to go insecure. The RFC section I refer
to have some considerations why you might want to go insecure during the
transition.

Hope this helps,

- Matthijs


On 8/19/20 8:45 PM, John W. Blue via bind-users wrote:

> We are in the process of moving from one IPAM vendor to another.
>
>  
>
> All of our zones are DNSSEC signed and the TTL’s have been lowered to
> 300 seconds.
>
>  
>
> At a high level, the playbook is to update the registrar with names/IP
> addresses of the new servers and update the DSKEY.  Depending on the
> time of the day that the cutover actually happens at we know the process
> to request of the registrar an out of band data push so the new servers
> will be seen by the open Internet.
>
>  
>
> A suggestion have been put forth that we should unsign our zones prior
> to migration but I am skeptical of the benefits of doing so.
>
>  
>
> Are we missing something obvious?
>
>  
>
> John
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
>

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users

signature.asc (499 bytes) Download Attachment