1. Forum
  2. USENET
  3. comp.protocols.dns.bind

  • DNSSEC migration sanity check

    From John W. Blue@john.blue@rrcic.com to bind-users@lists.isc.org on Wed Aug 19 18:45:54 2020
    From Newsgroup: comp.protocols.dns.bind

    --_000_44d00cc0366c4c7fa9342946d5fedd1fmailrrciccom_
    Content-Type: text/plain; charset="us-ascii"
    Content-Transfer-Encoding: quoted-printable

    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 s= econds.

    At a high level, the playbook is to update the registrar with names/IP addr= esses of the new servers and update the DSKEY. Depending on the time of th=
    e day that the cutover actually happens at we know the process to request o=
    f 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 m= igration but I am skeptical of the benefits of doing so.

    Are we missing something obvious?

    John

    --_000_44d00cc0366c4c7fa9342946d5fedd1fmailrrciccom_
    Content-Type: text/html; charset="us-ascii"
    Content-Transfer-Encoding: quoted-printable

    <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40">
    <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=

    <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!--
    /* Font Definitions */
    @font-face
    {font-family:"Cambria Math";
    panose-1:2 4 5 3 5 4 6 3 2 4;}
    @font-face
    {font-family:Calibri;
    panose-1:2 15 5 2 2 2 4 3 2 4;}
    /* Style Definitions */
    p.MsoNormal, li.MsoNormal, div.MsoNormal
    {margin:0in;
    margin-bottom:.0001pt;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";}
    a:link, span.MsoHyperlink
    {mso-style-priority:99;
    color:#0563C1;
    text-decoration:underline;}
    a:visited, span.MsoHyperlinkFollowed
    {mso-style-priority:99;
    color:#954F72;
    text-decoration:underline;}
    span.EmailStyle17
    {mso-style-type:personal-compose;
    font-family:"Calibri","sans-serif";
    color:windowtext;}
    .MsoChpDefault
    {mso-style-type:export-only;
    font-family:"Calibri","sans-serif";}
    @page WordSection1
    {size:8.5in 11.0in;
    margin:1.0in 1.0in 1.0in 1.0in;}
    div.WordSection1
    {page:WordSection1;}
    </style><!--[if gte mso 9]><xml>
    <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
    </xml><![endif]--><!--[if gte mso 9]><xml>
    <o:shapelayout v:ext=3D"edit">
    <o:idmap v:ext=3D"edit" data=3D"1" />
    </o:shapelayout></xml><![endif]-->
    </head>
    <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
    <div class=3D"WordSection1">
    <p class=3D"MsoNormal">We are in the process of moving from one IPAM vendor=
    to another.<o:p></o:p></p>
    <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class=3D"MsoNormal">All of our zones are DNSSEC signed and the TTL&#8217=
    ;s have been lowered to 300 seconds.<o:p></o:p></p>
    <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class=3D"MsoNormal">At a high level, the playbook is to update the regis= trar with names/IP addresses of the new servers and update the DSKEY.&nbsp;=
    Depending on the time of the day that the cutover actually happens at we k= now the process to request of the registrar
    an out of band data push so the new servers will be seen by the open Inter= net.<o:p></o:p></p>
    <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class=3D"MsoNormal">A suggestion have been put forth that we should unsi=
    gn our zones prior to migration but I am skeptical of the benefits of doing=
    so.<o:p></o:p></p>
    <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class=3D"MsoNormal">Are we missing something obvious?<o:p></o:p></p>
    <p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
    <p class=3D"MsoNormal">John<o:p></o:p></p>
    </div>
    </body>
    </html>

    --_000_44d00cc0366c4c7fa9342946d5fedd1fmailrrciccom_--
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Crist Clark@cjc+bind-users@pumpky.net to John W. Blue on Wed Aug 19 21:49:28 2020
    From Newsgroup: comp.protocols.dns.bind

    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 <bind-users@lists.isc.org> wrote:

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



    All of our zones are DNSSEC signed and the TTLrCOs 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
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Matthijs Mekking@matthijs@isc.org to bind-users on Thu Aug 20 10:25:24 2020
    From Newsgroup: comp.protocols.dns.bind

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Dur6WrLSX3THtIS6u7rCY6fvp4vLANX4p
    Content-Type: multipart/mixed; boundary="O8DTYpSB1XwhRrfGroJgNeg6vniuuXX3P";
    protected-headers="v1"
    From: Matthijs Mekking <matthijs@isc.org>
    To: bind-users@lists.isc.org
    Message-ID: <87af7e8f-5cd9-f062-af0d-c9426e1a9077@isc.org>
    Subject: Re: DNSSEC migration sanity check
    References: <44d00cc0366c4c7fa9342946d5fedd1f@mail.rrcic.com>
    In-Reply-To: <44d00cc0366c4c7fa9342946d5fedd1f@mail.rrcic.com>

    --O8DTYpSB1XwhRrfGroJgNeg6vniuuXX3P
    Content-Type: text/plain; charset=windows-1252
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable

    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.
    =20
    =A0
    =20
    All of our zones are DNSSEC signed and the TTL=92s have been lowered to=

    300 seconds.
    =20
    =A0
    =20
    At a high level, the playbook is to update the registrar with names/IP addresses of the new servers and update the DSKEY.=A0 Depending on the
    time of the day that the cutover actually happens at we know the proces=
    s
    to request of the registrar an out of band data push so the new servers=

    will be seen by the open Internet.
    =20
    =A0
    =20
    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.
    =20
    =A0
    =20
    Are we missing something obvious?
    =20
    =A0
    =20
    John
    =20
    =20
    _______________________________________________
    Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsub=
    scribe from this list
    =20
    ISC funds the development of this software with paid support subscripti=
    ons. Contact us at https://www.isc.org/contact/ for more information.
    =20
    =20
    bind-users mailing list
    bind-users@lists.isc.org
    https://lists.isc.org/mailman/listinfo/bind-users
    =20


    --O8DTYpSB1XwhRrfGroJgNeg6vniuuXX3P--

    --Dur6WrLSX3THtIS6u7rCY6fvp4vLANX4p
    Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"

    -----BEGIN PGP SIGNATURE-----

    iQEzBAEBCAAdFiEEF9tUtPZjiCApvBobVHl7Vy10FR4FAl8+M3QACgkQVHl7Vy10 FR4+7gf6Avjm4T0eTv/wIlYfSvYdsgBlB5/kGGRwSKhePwW9LFMW610XK7XxwPWX CkEBXPewzxGjzPq/gz7EzpErkig4U8D8TsSoS4oQjoXZWZsYEwgEu6BwIeF263z2 iz01LmlDPyDc1vmVuTba8u4XjOHpbvW7aLKdymGNPnE1EtvUAUp2AYnMkZR6Yw2C IG8DuI3HIKnf084dajkqZW4xWdS4xXP87qgDKdKsc6NqZvnB2aXp95HIxCVOcq3w ImtN+O/yyP7TKOz08krdFfyuFwQiI9H94fLskmYA5+LMa+t6OZzTftHksgFPx2UW cuII0FXncGYUIuj6qeVsatArLyjyzg==
    =Ge5O
    -----END PGP SIGNATURE-----

    --Dur6WrLSX3THtIS6u7rCY6fvp4vLANX4p--
    --- Synchronet 3.21d-Linux NewsLink 1.2