** Description changed: [ Impact ] - * ICANN has generated the next DNSSEC root trust anchor, KSK-2024. + * 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 + * 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 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. + * 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. [ Test Plan ] - * In the past on updates the self check on hints of named - were quite useful here (see bug 2045297) but this time + * In the past on updates the self check on hints of named + were quite useful here (see bug 2045297) but this time TODO - check what the old test does not (expect nothing) TODO - we can likely only compare against the upstream checksums this time then? - [ 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): + * 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. + * 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 [1] - And we backport the content, the same way as we did in the past. + * 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 - [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076995 + * Given that this is changing only data and that we likely need + to expect updating this more or less regularly I appreciate all + the packaging improvements Debian made like improving readme + and the generation of the key from the verified XML at build + time. 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
