Groups | Search | Server Info | Login | Register


Groups > comp.protocols.dns.bind > #16058

Re: DNSSEC migration sanity check

Path csiph.com!3.eu.feeder.erje.net!feeder.erje.net!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!not-for-mail
From Matthijs Mekking <matthijs@isc.org>
Newsgroups comp.protocols.dns.bind
Subject Re: DNSSEC migration sanity check
Date Thu, 20 Aug 2020 10:25:24 +0200
Lines 111
Approved bind-users@lists.isc.org
Message-ID <mailman.813.1597911882.942.bind-users@lists.isc.org> (permalink)
References <44d00cc0366c4c7fa9342946d5fedd1f@mail.rrcic.com> <87af7e8f-5cd9-f062-af0d-c9426e1a9077@isc.org>
NNTP-Posting-Host lists.isc.org
Mime-Version 1.0
Content-Type multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Dur6WrLSX3THtIS6u7rCY6fvp4vLANX4p"
X-Trace usenet.stanford.edu 1597911930 19920 149.20.1.60 (20 Aug 2020 08:25:30 GMT)
X-Complaints-To action@cs.stanford.edu
To bind-users@lists.isc.org
Return-Path <matthijs@isc.org>
X-Original-To bind-users@lists.isc.org
Delivered-To bind-users@lists.isc.org
Autocrypt addr=matthijs@isc.org; keydata= xsBNBFwE8S0BCADtYae8WFJO5uKd1n8e/6nOJu/fc63+wrwugPevwfkLthb8URsu50JiQvhW 43Z7aLKV7bdYb6XrxBvTj/H03bBXxPMFChePi7ov+kQODVCaR+jlpaWJRuBUuh6Pbg9jlvj3 TCeTtsAv8e5JUno2uzRk/NVydC5kmx2c5OxxOkxAVugnAGY0+BoGEAXH5DHX4HMcooj1t9XL kWY1tbcZefEyvNpjBtjO00fIybx45slLR29muheZWN5m4r8FD+tJVO/sqfUXDK1P3pZ6cL52 wGrE4eHZOLsXDLiSQZqd226r3IOFtISjX7mWWXsN/OhvSU8Kq61hD0hNjYPXO9qVXggZABEB AAHNI01hdHRoaWpzIE1la2tpbmcgPG1hdHRoaWpzQGlzYy5vcmc+wsB4BBMBCAAiBQJcBPEt AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBUeXtXLXQVHslmB/9I/BEyoMwz2FeD AmjoD8hyfUurGFXgy2mBCbFAHvBwC1RwCpEihuUZKX4mzHluA94xToqTwVG3emOj/tLIdUPd EAhM8kCHqq/ggSnMnm/9nyIGCrYk5Ln6GWUG9GS9UnNZqDGNu4SjXcDpm0WvhV5D/e+J6fcL 6ZcPgWXtnsb6mdJLyviOqknFPLMPszdsyal94+w2tLDGDIMzIQ4HczIuRkIRnuim3b+AADPq 1lyjbuLceGKCziTC4oWzzFr1oF6gL/MslzRLJUsNwXCoTwhMM+MKE/nk58HR+DKYdi/LfxqR 7KBE3p8scLFCaqXPITYbBZci3SG4oPCUG8VTtqf1zsBNBFwE8S0BCAD65Qe6tGP+cfSw3VuZ o7rKi+ZNMNY5t0fGt+BW8Euc8eTt4VAcKTaiEFhiOqvkGclUoRxTuhT8rYLiPhcjJhvj9S15 1P1nNNtXXcoo4lSiWDM/1mrvB0Mtjw24/pl1k93SVmJqMCz1QbDO7VmEgi4dX1evretALlun O348o6LerptDtnNtKavTUrJV51v2M/InepIk8rFZr8fRkyqbxgQJ+UvLOmBh9WJskyxPgJjb 2rEMOFGfhtEFqJRm6A+ozr21XWjU2GZlVfq0JAT2WelGuQ/3ZoT9cKyaBK+GSfMMJu1HxKw+ RZopTzEUP46adOYCkBaSknKRnHOhNkiCRe0xABEBAAHCwF8EGAEIAAkFAlwE8S0CGwwACgkQ VHl7Vy10FR7duAgArTxD+1ItUxeplSJiX9DT+fBBU6aKIpkN0otdHjs+KtsQfRfq4alVSKzD LMizDcZU+Maz3LEPVLUFYj0bgD3FL+Jp5mrfnEr1Y/QTCY2amaHFuN8Egvcw35Jj5WbZ2LnI KpIMKpskidd+C1nV6j9nNhqxLv0wiQWbOy6jjgKEIYO20lx3r0Ii3UqdQxVaw9DPTA7wZZbn XW0oCes332l3DhXxais9gaosLOPo/P6NKcq6V/n089wgw1NDBk7TR5zOpgUH8vprf+D3Z8hc bYMqKTVu6w+V0U6YIkzWLX2NrafrDO76GPGMXDNH+P3h8VFMacyacNj8f35Te5sI0kocnQ==
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
In-Reply-To <44d00cc0366c4c7fa9342946d5fedd1f@mail.rrcic.com>
X-BeenThere bind-users@lists.isc.org
X-Mailman-Version 2.1.29
Precedence list
List-Id BIND Users Mailing List <bind-users.lists.isc.org>
List-Unsubscribe <https://lists.isc.org/mailman/options/bind-users>, <mailto:bind-users-request@lists.isc.org?subject=unsubscribe>
List-Archive <https://lists.isc.org/pipermail/bind-users/>
List-Post <mailto:bind-users@lists.isc.org>
List-Help <mailto:bind-users-request@lists.isc.org?subject=help>
List-Subscribe <https://lists.isc.org/mailman/listinfo/bind-users>, <mailto:bind-users-request@lists.isc.org?subject=subscribe>
X-Mailman-Original-Message-ID <87af7e8f-5cd9-f062-af0d-c9426e1a9077@isc.org>
X-Mailman-Original-References <44d00cc0366c4c7fa9342946d5fedd1f@mail.rrcic.com>
Xref csiph.com comp.protocols.dns.bind:16058

Show key headers only | View raw


[Multipart message — attachments visible in raw view] - view raw

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

Back to comp.protocols.dns.bind | Previous | Next | Find similar


Thread

Re: DNSSEC migration sanity check Matthijs Mekking <matthijs@isc.org> - 2020-08-20 10:25 +0200

csiph-web