I was able to come up with steps to verify the build result as delivered by the package as well as adding a simple test with named to ensure it is not breaking by e.g. the key being in the future. Thereby the associated MRs that are up for review now before upload into the Ubuntu SRU queue.
** Description changed: [ Impact ] * ICANN has generated the next DNSSEC root trust anchor, KSK-2024. * ICANN's current plan is that it will be required around 2026-10-11 to 2027-01-11, but the sooner it's updated, the more unmaintained installations will have it when the time comes. * https://lists.dns-oarc.net/pipermail/dns-operations/2024-November/022711.html * On one hand it is "only" annoyance as e.g. named uses them as hints and will on start check those hints and spam you warnings to the logs. * On the other hand this will break. Mid term the old addresses will stop to work (by 2026/2027) that is the strong deadline until this should be updated everywhere. + Read more about the general key rollover policy at + https://www.iana.org/dnssec/files + In regard to that Ubuntu falls into this category: + + "Validators should keep this data up-to-date. Consider the following: + ... + Software vendors often package and distribute up-to-date trust anchors through their regular software update mechanisms." + [ Test Plan ] * In the past on updates the self check on hints of named were quite useful here when it was updating to the new keys (see bug 2045297). But this time we are not so very late (which is good) and thereby that simple test does not work yet (not so good). - TODO - we can likely only compare against the upstream checksums this time then? - TODO - maybe use the readout tool against the content from upstream and verify it's content matches - TODO - while the named check and fetch will not serve as a verification, it still is something we want to ensure is still working after the update + * Still as a regression test against those keys being installed + a valid check is to install bind9 and check named's status with + the new vs the old keys. + + $ apt install bind9; + $ systemctl restart named; + # takes a while to fully start + $ sleep 20s; + $ systemctl status named --lines 80 --no-pager + + Run the above as-is and then again with the updated dns-root-data + package. + + Important should be: + 1. no weird behavior with the updated keys, compare to the old + 2. Named is happy, check for those two + status + Active: active (running) + log + Nov 25 09:06:54 f named[13139]: all zones loaded + Nov 25 09:06:54 f named[13139]: running + + + * This is adding the new KSK-2024 key, not removing the old. So one more + thing that is worth to check is that the key and delegation signer + contained in + $ cat /usr/share/dns/root.key + $ cat /usr/share/dns/root.ds + are still present after the upgrade. There should be a new second key + now. Please mind that the new tooling does generate .ds better and + might switch characters to upper-case as usual in key display. + + + * Since the keys are not yet fully active, it won't do an auto-refresh + using them that we can check for. Instead we need to compare what + the update delivered against what IANA publishes. To do that you'd + compare that added second key. It was already generated the official + way at build time, so not doing the very same again. Instead let us + doing that in a few ways for extra confidence. + + First: + Compare that second key with the post on [1]. Other than some + spacing due to the way displayed it should match that. + + Second: + Compare he pkg content to the published data by IANA (see + https://www.iana.org/dnssec/files fo rmore). + # fetch published keys and signature + $ wget https://data.iana.org/root-anchors/root-anchors.xml \ + https://data.iana.org/root-anchors/root-anchors.p7s \ + https://data.iana.org/root-anchors/icannbundle.pem + # verify against the signature + $ openssl smime -verify -CAfile icannbundle.pem -inform der -in root-anchors.p7s -content root-anchors.xml + <?xml version="1.0" encoding="UTF-8"?> + <TrustAnchor id="0C05FDD6-422C-4910-8ED6-430ED15E11C2" source="http://data.iana.org/root-anchors/root-anchors.xml";> + <Zone>.</Zone> + <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> + <KeyTag>19036</KeyTag> + <Algorithm>8</Algorithm> + <DigestType>2</DigestType> + <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</Digest> + </KeyDigest> + <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> + <KeyTag>20326</KeyTag> + <Algorithm>8</Algorithm> + <DigestType>2</DigestType> + <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest> + <PublicKey>AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=</PublicKey> + <Flags>257</Flags> + </KeyDigest> + <KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00"> + <KeyTag>38696</KeyTag> + <Algorithm>8</Algorithm> + <DigestType>2</DigestType> + <Digest>683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16</Digest> + <PublicKey>AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=</PublicKey> + <Flags>257</Flags> + </KeyDigest> + </TrustAnchor> + Verification successful + # Once trusted, check that the key, ds and tag matches what + # the new version of dns-root-data installed + $ apt install xmlstarlet + # ensure the new KSK-2024 key is in there + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/PublicKey" root-anchors.xml) /usr/share/dns/root.key + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/Digest" root-anchors.xml) /usr/share/dns/root.ds + # ensure we haven't lost the still active key + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/PublicKey" root-anchors.xml) /usr/share/dns/root.key + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/Digest" root-anchors.xml) /usr/share/dns/root.ds + + Sorry for this a bit odd approach, but just re-doing what was already + done at build seemed not to provide a cross-check of any meaningful way. + + + [1]: https://lists.dns-oarc.net/pipermail/dns-operations/2024-November/022711.html + [ Where problems could occur ] * This isn't code, purely a data file for services that need to know about dns root servers. Thereby there is no code in the package itself that would fail, but potential regressions would be in the dependencies. Those are (and we can more consciously look out for those): Reverse-Recommends ================== * dnsmasq-base [amd64 arm64 armhf ppc64el s390x] * dnsmasq-base-lua [amd64 arm64 armhf ppc64el s390x] * ldnsutils [amd64 arm64 armhf ppc64el s390x] * libbellesip2 [amd64 arm64 armhf ppc64el s390x] * unbound * unbound-host Reverse-Depends =============== * bind9 * dnsviz * hash-slinger [amd64 arm64 armhf ppc64el s390x] * knot-resolver [amd64 arm64 armhf] * libgetdns10 [amd64 arm64 armhf ppc64el s390x] * libreswan [amd64 arm64 armhf ppc64el s390x] * opendkim [amd64 arm64 armhf ppc64el s390x] * pdns-recursor [amd64 arm64 ppc64el s390x] * At the same time I think we'd not need to do super advanced tests with custom setups of each of them. Those that are reverse dependencies and have tests (bind9, libreswan) will be ran by autopkgtest and given the change, that should IMHO be sufficient. [ Other Info ] * This is a native package and we are not doing anything special The same landed in Debian => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076995 - * This is structurally a similar update to the past bug 2045297 + * This is structurally a similar update to the past bug 2045297 * Given that this is changing only data and that we likely need to expect updating this more or less regularly I appreciate to - get all the packaging improvements Debian made like improving - readme and updating the generation of the key from the verified - XML at build time to the new rfc. - Hence I'd (just like Debian did) go for a backport of the most - recent version, over just picking the key content. + get all the packaging improvements Debian made like improving + readme and updating the generation of the key from the verified + XML at build time to the new rfc. + Hence I'd (just like Debian did) go for a backport of the most + recent version, over just picking the key content. That is easier to review, easier to maintain, and as long as there are no build issues better to ensure all active releases are on the same state. --- original report --- ICANN has generated the next DNSSEC root trust anchor, KSK-2024. ICANN's current plan is that it will be required around 2026-10-11 - 2027-01-11, but the sooner it's updated, the more unmaintained installations will have it when the time comes. <https://www.iana.org/dnssec/files> <https://lists.dns-oarc.net/pipermail/dns- operations/2024-November/022711.html> The corresponding Debian bug is <https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1076995>. (Some software can automatically update the trust anchor, as long as it's running and connected to the Internet often enough; some cannot.) ** Description changed: [ Impact ] * ICANN has generated the next DNSSEC root trust anchor, KSK-2024. * ICANN's current plan is that it will be required around 2026-10-11 to 2027-01-11, but the sooner it's updated, the more unmaintained installations will have it when the time comes. * https://lists.dns-oarc.net/pipermail/dns-operations/2024-November/022711.html * On one hand it is "only" annoyance as e.g. named uses them as hints and will on start check those hints and spam you warnings to the logs. * On the other hand this will break. Mid term the old addresses will stop to work (by 2026/2027) that is the strong deadline until this should be updated everywhere. - Read more about the general key rollover policy at - https://www.iana.org/dnssec/files - In regard to that Ubuntu falls into this category: + Read more about the general key rollover policy at + https://www.iana.org/dnssec/files + In regard to that Ubuntu falls into this category: "Validators should keep this data up-to-date. Consider the following: - ... + ... Software vendors often package and distribute up-to-date trust anchors through their regular software update mechanisms." - [ Test Plan ] * In the past on updates the self check on hints of named were quite useful here when it was updating to the new keys (see bug 2045297). But this time we are not so very late (which is good) and thereby that simple test does not work yet (not so good). - * Still as a regression test against those keys being installed - a valid check is to install bind9 and check named's status with - the new vs the old keys. + * Still as a regression test against those keys being installed + a valid check is to install bind9 and check named's status with + the new vs the old keys. - $ apt install bind9; - $ systemctl restart named; - # takes a while to fully start - $ sleep 20s; - $ systemctl status named --lines 80 --no-pager + $ apt install bind9; + $ systemctl restart named; + # takes a while to fully start + $ sleep 20s; + $ systemctl status named --lines 80 --no-pager - Run the above as-is and then again with the updated dns-root-data + Run the above as-is and then again with the updated dns-root-data package. Important should be: 1. no weird behavior with the updated keys, compare to the old 2. Named is happy, check for those two - status - Active: active (running) - log - Nov 25 09:06:54 f named[13139]: all zones loaded - Nov 25 09:06:54 f named[13139]: running + status + Active: active (running) + log + Nov 25 09:06:54 f named[13139]: all zones loaded + Nov 25 09:06:54 f named[13139]: running + + * This is adding the new KSK-2024 key, not removing the old. So one more + thing that is worth to check is that the key and delegation signer + contained in + $ cat /usr/share/dns/root.key + $ cat /usr/share/dns/root.ds + are still present after the upgrade. There should be a new second key + now. Please mind that the new tooling does generate .ds better and + might switch characters to upper-case as usual in key display. + + * Since the keys are not yet fully active, it won't do an auto-refresh + using them that we can check for. Instead we need to compare what + the update delivered against what IANA publishes. To do that you'd + compare that added second key. It was already generated the official + way at build time, so not doing the very same again. Instead let us + doing that in a few ways for extra confidence. + + First: + Compare that second key with the post on [1]. Other than some + spacing due to the way displayed it should match that. + + Second: + Compare he pkg content to the published data by IANA (see + https://www.iana.org/dnssec/files fo rmore). + # fetch published keys and signature + $ wget https://data.iana.org/root-anchors/root-anchors.xml \ + https://data.iana.org/root-anchors/root-anchors.p7s \ + https://data.iana.org/root-anchors/icannbundle.pem + # verify against the signature + $ openssl smime -verify -CAfile icannbundle.pem -inform der -in root-anchors.p7s -content root-anchors.xml + <?xml version="1.0" encoding="UTF-8"?> + <TrustAnchor id="0C05FDD6-422C-4910-8ED6-430ED15E11C2" source="http://data.iana.org/root-anchors/root-anchors.xml";> + <Zone>.</Zone> + <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> + <KeyTag>19036</KeyTag> + <Algorithm>8</Algorithm> + <DigestType>2</DigestType> + <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</Digest> + </KeyDigest> + <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> + <KeyTag>20326</KeyTag> + <Algorithm>8</Algorithm> + <DigestType>2</DigestType> + <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest> + <PublicKey>AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=</PublicKey> + <Flags>257</Flags> + </KeyDigest> + <KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00"> + <KeyTag>38696</KeyTag> + <Algorithm>8</Algorithm> + <DigestType>2</DigestType> + <Digest>683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16</Digest> + <PublicKey>AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=</PublicKey> + <Flags>257</Flags> + </KeyDigest> + </TrustAnchor> + Verification successful + # Once trusted, check that the key, ds and tag matches what + # the new version of dns-root-data installed + $ apt install xmlstarlet + # ensure the new KSK-2024 key is in there + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/PublicKey" root-anchors.xml) /usr/share/dns/root.key + . IN DNSKEY 257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ; keytag 38696 + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/Digest" root-anchors.xml) /usr/share/dns/root.ds + . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 + # ensure we haven't lost the still active key + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/PublicKey" root-anchors.xml) /usr/share/dns/root.key + . IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; keytag 20326 + $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/Digest" root-anchors.xml) /usr/share/dns/root.ds + . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D - * This is adding the new KSK-2024 key, not removing the old. So one more - thing that is worth to check is that the key and delegation signer - contained in - $ cat /usr/share/dns/root.key - $ cat /usr/share/dns/root.ds - are still present after the upgrade. There should be a new second key - now. Please mind that the new tooling does generate .ds better and - might switch characters to upper-case as usual in key display. + Sorry for this a bit odd approach, but just re-doing what was already done at build seemed not to provide a cross-check of any meaningful way. - - * Since the keys are not yet fully active, it won't do an auto-refresh - using them that we can check for. Instead we need to compare what - the update delivered against what IANA publishes. To do that you'd - compare that added second key. It was already generated the official - way at build time, so not doing the very same again. Instead let us - doing that in a few ways for extra confidence. - - First: - Compare that second key with the post on [1]. Other than some - spacing due to the way displayed it should match that. - - Second: - Compare he pkg content to the published data by IANA (see - https://www.iana.org/dnssec/files fo rmore). - # fetch published keys and signature - $ wget https://data.iana.org/root-anchors/root-anchors.xml \ - https://data.iana.org/root-anchors/root-anchors.p7s \ - https://data.iana.org/root-anchors/icannbundle.pem - # verify against the signature - $ openssl smime -verify -CAfile icannbundle.pem -inform der -in root-anchors.p7s -content root-anchors.xml - <?xml version="1.0" encoding="UTF-8"?> - <TrustAnchor id="0C05FDD6-422C-4910-8ED6-430ED15E11C2" source="http://data.iana.org/root-anchors/root-anchors.xml";> - <Zone>.</Zone> - <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> - <KeyTag>19036</KeyTag> - <Algorithm>8</Algorithm> - <DigestType>2</DigestType> - <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</Digest> - </KeyDigest> - <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> - <KeyTag>20326</KeyTag> - <Algorithm>8</Algorithm> - <DigestType>2</DigestType> - <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest> - <PublicKey>AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=</PublicKey> - <Flags>257</Flags> - </KeyDigest> - <KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00"> - <KeyTag>38696</KeyTag> - <Algorithm>8</Algorithm> - <DigestType>2</DigestType> - <Digest>683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16</Digest> - <PublicKey>AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=</PublicKey> - <Flags>257</Flags> - </KeyDigest> - </TrustAnchor> - Verification successful - # Once trusted, check that the key, ds and tag matches what - # the new version of dns-root-data installed - $ apt install xmlstarlet - # ensure the new KSK-2024 key is in there - $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/PublicKey" root-anchors.xml) /usr/share/dns/root.key - $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/Digest" root-anchors.xml) /usr/share/dns/root.ds - # ensure we haven't lost the still active key - $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/PublicKey" root-anchors.xml) /usr/share/dns/root.key - $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/Digest" root-anchors.xml) /usr/share/dns/root.ds - - Sorry for this a bit odd approach, but just re-doing what was already - done at build seemed not to provide a cross-check of any meaningful way. - - - [1]: https://lists.dns-oarc.net/pipermail/dns-operations/2024-November/022711.html - + [1]: https://lists.dns-oarc.net/pipermail/dns- + operations/2024-November/022711.html [ Where problems could occur ] * This isn't code, purely a data file for services that need to know about dns root servers. Thereby there is no code in the package itself that would fail, but potential regressions would be in the dependencies. Those are (and we can more consciously look out for those): Reverse-Recommends ================== * dnsmasq-base [amd64 arm64 armhf ppc64el s390x] * dnsmasq-base-lua [amd64 arm64 armhf ppc64el s390x] * ldnsutils [amd64 arm64 armhf ppc64el s390x] * libbellesip2 [amd64 arm64 armhf ppc64el s390x] * unbound * unbound-host Reverse-Depends =============== * bind9 * dnsviz * hash-slinger [amd64 arm64 armhf ppc64el s390x] * knot-resolver [amd64 arm64 armhf] * libgetdns10 [amd64 arm64 armhf ppc64el s390x] * libreswan [amd64 arm64 armhf ppc64el s390x] * opendkim [amd64 arm64 armhf ppc64el s390x] * pdns-recursor [amd64 arm64 ppc64el s390x] * At the same time I think we'd not need to do super advanced tests with custom setups of each of them. Those that are reverse dependencies and have tests (bind9, libreswan) will be ran by autopkgtest and given the change, that should IMHO be sufficient. [ Other Info ] * This is a native package and we are not doing anything special The same landed in Debian => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076995 * This is structurally a similar update to the past bug 2045297 * Given that this is changing only data and that we likely need to expect updating this more or less regularly I appreciate to get all the packaging improvements Debian made like improving readme and updating the generation of the key from the verified XML at build time to the new rfc. Hence I'd (just like Debian did) go for a backport of the most recent version, over just picking the key content. That is easier to review, easier to maintain, and as long as there are no build issues better to ensure all active releases are on the same state. --- original report --- ICANN has generated the next DNSSEC root trust anchor, KSK-2024. ICANN's current plan is that it will be required around 2026-10-11 - 2027-01-11, but the sooner it's updated, the more unmaintained installations will have it when the time comes. <https://www.iana.org/dnssec/files> <https://lists.dns-oarc.net/pipermail/dns- operations/2024-November/022711.html> The corresponding Debian bug is <https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1076995>. (Some software can automatically update the trust anchor, as long as it's running and connected to the Internet often enough; some cannot.) ** Description changed: [ Impact ] * ICANN has generated the next DNSSEC root trust anchor, KSK-2024. * ICANN's current plan is that it will be required around 2026-10-11 to 2027-01-11, but the sooner it's updated, the more unmaintained installations will have it when the time comes. * https://lists.dns-oarc.net/pipermail/dns-operations/2024-November/022711.html * On one hand it is "only" annoyance as e.g. named uses them as hints and will on start check those hints and spam you warnings to the logs. * On the other hand this will break. Mid term the old addresses will stop to work (by 2026/2027) that is the strong deadline until this should be updated everywhere. Read more about the general key rollover policy at https://www.iana.org/dnssec/files In regard to that Ubuntu falls into this category: "Validators should keep this data up-to-date. Consider the following: ... Software vendors often package and distribute up-to-date trust anchors through their regular software update mechanisms." [ Test Plan ] * In the past on updates the self check on hints of named were quite useful here when it was updating to the new keys (see bug 2045297). But this time we are not so very late (which is good) and thereby that simple test does not work yet (not so good). * Still as a regression test against those keys being installed a valid check is to install bind9 and check named's status with the new vs the old keys. $ apt install bind9; $ systemctl restart named; # takes a while to fully start $ sleep 20s; $ systemctl status named --lines 80 --no-pager Run the above as-is and then again with the updated dns-root-data package. Important should be: 1. no weird behavior with the updated keys, compare to the old 2. Named is happy, check for those two status Active: active (running) log Nov 25 09:06:54 f named[13139]: all zones loaded Nov 25 09:06:54 f named[13139]: running * This is adding the new KSK-2024 key, not removing the old. So one more thing that is worth to check is that the key and delegation signer contained in $ cat /usr/share/dns/root.key $ cat /usr/share/dns/root.ds are still present after the upgrade. There should be a new second key now. Please mind that the new tooling does generate .ds better and might switch characters to upper-case as usual in key display. * Since the keys are not yet fully active, it won't do an auto-refresh using them that we can check for. Instead we need to compare what the update delivered against what IANA publishes. To do that you'd compare that added second key. It was already generated the official way at build time, so not doing the very same again. Instead let us doing that in a few ways for extra confidence. First: Compare that second key with the post on [1]. Other than some spacing due to the way displayed it should match that. Second: Compare he pkg content to the published data by IANA (see https://www.iana.org/dnssec/files fo rmore). # fetch published keys and signature $ wget https://data.iana.org/root-anchors/root-anchors.xml \ https://data.iana.org/root-anchors/root-anchors.p7s \ https://data.iana.org/root-anchors/icannbundle.pem # verify against the signature $ openssl smime -verify -CAfile icannbundle.pem -inform der -in root-anchors.p7s -content root-anchors.xml <?xml version="1.0" encoding="UTF-8"?> <TrustAnchor id="0C05FDD6-422C-4910-8ED6-430ED15E11C2" source="http://data.iana.org/root-anchors/root-anchors.xml";> <Zone>.</Zone> <KeyDigest id="Kjqmt7v" validFrom="2010-07-15T00:00:00+00:00" validUntil="2019-01-11T00:00:00+00:00"> <KeyTag>19036</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest>49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5</Digest> </KeyDigest> <KeyDigest id="Klajeyz" validFrom="2017-02-02T00:00:00+00:00"> <KeyTag>20326</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest>E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D</Digest> <PublicKey>AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=</PublicKey> <Flags>257</Flags> </KeyDigest> <KeyDigest id="Kmyv6jo" validFrom="2024-07-18T00:00:00+00:00"> <KeyTag>38696</KeyTag> <Algorithm>8</Algorithm> <DigestType>2</DigestType> <Digest>683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16</Digest> <PublicKey>AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=</PublicKey> <Flags>257</Flags> </KeyDigest> </TrustAnchor> Verification successful # Once trusted, check that the key, ds and tag matches what # the new version of dns-root-data installed $ apt install xmlstarlet # ensure the new KSK-2024 key is in there $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/PublicKey" root-anchors.xml) /usr/share/dns/root.key . IN DNSKEY 257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeHspaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vrhbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAxm9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxPvYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc= ; keytag 38696 $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Kmyv6jo']/Digest" root-anchors.xml) /usr/share/dns/root.ds . IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16 # ensure we haven't lost the still active key $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/PublicKey" root-anchors.xml) /usr/share/dns/root.key . IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ; keytag 20326 $ grep $(xmlstarlet sel -t -v "//KeyDigest[@id='Klajeyz']/Digest" root-anchors.xml) /usr/share/dns/root.ds . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D - - Sorry for this a bit odd approach, but just re-doing what was already done at build seemed not to provide a cross-check of any meaningful way. + Sorry for this a bit odd approach, but just re-doing what was already + done at build seemed not to provide a cross-check of any meaningful way. [1]: https://lists.dns-oarc.net/pipermail/dns- operations/2024-November/022711.html [ Where problems could occur ] * This isn't code, purely a data file for services that need to know about dns root servers. Thereby there is no code in the package itself that would fail, but potential regressions would be in the dependencies. Those are (and we can more consciously look out for those): Reverse-Recommends ================== * dnsmasq-base [amd64 arm64 armhf ppc64el s390x] * dnsmasq-base-lua [amd64 arm64 armhf ppc64el s390x] * ldnsutils [amd64 arm64 armhf ppc64el s390x] * libbellesip2 [amd64 arm64 armhf ppc64el s390x] * unbound * unbound-host Reverse-Depends =============== * bind9 * dnsviz * hash-slinger [amd64 arm64 armhf ppc64el s390x] * knot-resolver [amd64 arm64 armhf] * libgetdns10 [amd64 arm64 armhf ppc64el s390x] * libreswan [amd64 arm64 armhf ppc64el s390x] * opendkim [amd64 arm64 armhf ppc64el s390x] * pdns-recursor [amd64 arm64 ppc64el s390x] * At the same time I think we'd not need to do super advanced tests with custom setups of each of them. Those that are reverse dependencies and have tests (bind9, libreswan) will be ran by autopkgtest and given the change, that should IMHO be sufficient. + * This is following one change in Debian which SRU thoughts might decide + otherwise about. root.hints.sig is no more shipped since 2024041802. + For noble/jammy/focal that means the file is no more around after the + update. I think this is fine as its use-case really is negelgible, + and having them consistent across releases has benefits for admins + and further maintenance. Yet If you disagree let me know and I can + see if we can re-generate that from the upstream content as well. + + [ Other Info ] * This is a native package and we are not doing anything special The same landed in Debian => https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076995 * This is structurally a similar update to the past bug 2045297 * Given that this is changing only data and that we likely need to expect updating this more or less regularly I appreciate to get all the packaging improvements Debian made like improving readme and updating the generation of the key from the verified XML at build time to the new rfc. Hence I'd (just like Debian did) go for a backport of the most recent version, over just picking the key content. That is easier to review, easier to maintain, and as long as there are no build issues better to ensure all active releases are on the same state. --- original report --- ICANN has generated the next DNSSEC root trust anchor, KSK-2024. ICANN's current plan is that it will be required around 2026-10-11 - 2027-01-11, but the sooner it's updated, the more unmaintained installations will have it when the time comes. <https://www.iana.org/dnssec/files> <https://lists.dns-oarc.net/pipermail/dns- operations/2024-November/022711.html> The corresponding Debian bug is <https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=1076995>. (Some software can automatically update the trust anchor, as long as it's running and connected to the Internet often enough; some cannot.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2086795 Title: New DNSSEC root trust anchor To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dns-root-data/+bug/2086795/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
