From Fedora Project Wiki
(Add trackers)
 
(14 intermediate revisions by 3 users not shown)
Line 6: Line 6:
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
BIND 9 would be updated to upcoming stable version BIND 9.16.
BIND 9 would be updated to the upcoming stable version BIND 9.16.


== Owner ==
== Owner ==
Line 14: Line 14:
-->
-->
* Name: [[User:pemensik| Petr Menšík]]
* Name: [[User:pemensik| Petr Menšík]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: pemensik at redhat.com, dns-sig at fedoraproject dot org
* Email: pemensik at redhat.com
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
-->
<!--- UNCOMMENT only if this Change aims specific product, working group (Cloud, Workstation, Server, Base, Env & Stacks)
* Product:
* Responsible WG:
-->
* Email: dns-sig at fedoraproject dot org


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF34]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 44: Line 35:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2559 #2559]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1922343 #1922343]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/646 #646]


== Detailed Description ==
== Detailed Description ==


<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple of sentences suffices to explain the goal, but the more details you can provide the better. -->
ISC BIND 9 stayed longer time on 9.11 Extended Support Version, because dhcp and freeipa depended on it. DHCP package no longer requires bind-export-libs, which new BIND 9.16 does not support. FreeIPA part bind-dyndb-ldap were also modified to support new version.
ISC BIND 9 stayed longer time on 9.11 Extended Support Version because dhcp and freeipa depended on it. DHCP package no longer requires bind-export-libs, which new BIND 9.16 does not support. FreeIPA part bind-dyndb-ldap were also modified to support new version.


BIND 9.16 includes more easy way to provide DNSSEC ([https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP) KASP]).
BIND 9.16 includes more easy way to provide DNSSEC ([https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP) KASP]).
Line 96: Line 87:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Line 103: Line 94:
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: N/A <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->
<!-- If your Change may require trademark approval (for example, if it is a new Spin), file a ticket ( https://pagure.io/Fedora-Council/tickets/issues ) requesting trademark approval from the Fedora Council. This approval will be done via the Council's consensus-based process. -->


Line 118: Line 109:
N/A (not a System Wide Change)
N/A (not a System Wide Change)


lwresd server and lwres nss client plugin is no longer provided. bind-sdb is also no longer provided as separate package. Instead several bind-dlz-* plugins are offered as runtime loadable plugins.
* [https://downloads.isc.org/isc/bind9/9.11.26/doc/arm/Bv9ARM.ch05.html#lightweight_resolver lightweight resolver (lwres)] server and nss client plugin are no longer provided.
* named version with database backends support (bind-sdb) is also no longer provided as a subpackage. Instead several bind-dlz-* plugins are offered as runtime loadable plugins, which require modification to named configuration. They offer the same functionality with just '''bind''' package and selected plugin.
* ''dnssec-enabled'' option is not supported anymore, it is always set to ''yes''. ''dnssec-validation'' can be still turned off.


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  


Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
Remember that you are writing this how-to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.


A good "how to test" should answer these four questions:
A good "how to test" should answer these four questions:
Line 147: Line 140:
   - Packages are compressed more efficiently, making downloads and upgrades faster by 10%.
   - Packages are compressed more efficiently, making downloads and upgrades faster by 10%.
   - Kerberos tickets can be renewed automatically. Users will now have to authenticate less and become more productive. Credential management improvements mean a user can start their work day with a single sign on and not have to pause for reauthentication during their entire day.
   - Kerberos tickets can be renewed automatically. Users will now have to authenticate less and become more productive. Credential management improvements mean a user can start their work day with a single sign on and not have to pause for reauthentication during their entire day.
  - Libreoffice is one of the most commonly installed applications on Fedora and it is now available by default to help users "hit the ground running".
  - LibreOffice is one of the most commonly installed applications on Fedora and it is now available by default to help users "hit the ground running".
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
-->
-->
* named service supports ''dnssec-policy'' option, merging ''dnssec-keymgr'' into ''named''.
* DNSSEC trust anchors were merged into ''trust-anchors'' section, replacing previous ''trusted-keys'' and ''managed-keys''.
* '''dig +yaml''' provides machine parseable output in YAML format


== Dependencies ==
== Dependencies ==
Line 155: Line 151:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
bind-dyndb-ldap -> freeipa
* bind-dyndb-ldap (required by freeipa)


== Contingency Plan ==
== Contingency Plan ==
Line 171: Line 167:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  
<!-- N/A (not a System Wide Change) -->
 
* Upstream [https://bind9.readthedocs.io/en/v9_16_10/notes.html BIND 9.16 Release Notes]
* [https://bind9.readthedocs.io/en/v9_16_10/notes.html#notes-for-bind-9-16-0 Added and removed features]
* Upstream [https://downloads.isc.org/isc/bind9/9.14.0/RELEASE-NOTES-bind-9.14.0.html BIND 9.14 Release Notes]


== Release Notes ==
== Release Notes ==

Latest revision as of 16:27, 29 January 2021


BIND 9.16

Summary

BIND 9 would be updated to the upcoming stable version BIND 9.16.

Owner

  • Name: Petr Menšík
  • Email: pemensik at redhat.com, dns-sig at fedoraproject dot org

Current status

Detailed Description

ISC BIND 9 stayed longer time on 9.11 Extended Support Version because dhcp and freeipa depended on it. DHCP package no longer requires bind-export-libs, which new BIND 9.16 does not support. FreeIPA part bind-dyndb-ldap were also modified to support new version.

BIND 9.16 includes more easy way to provide DNSSEC (KASP).

Feedback

Benefit to Fedora

Stable version under most the active development is packaged again. Introduces DNSSEC Key and Signing Policy without external tools like opendnssec. Also client tools from bind-utils now support yaml export format (dig, mdig, delv).

Scope

  • Proposal owners:
  • Other developers: N/A
  • Policies and guidelines: N/A
  • Trademark approval: N/A
  • Alignment with Objectives:

Upgrade/compatibility impact

N/A (not a System Wide Change)

  • lightweight resolver (lwres) server and nss client plugin are no longer provided.
  • named version with database backends support (bind-sdb) is also no longer provided as a subpackage. Instead several bind-dlz-* plugins are offered as runtime loadable plugins, which require modification to named configuration. They offer the same functionality with just bind package and selected plugin.
  • dnssec-enabled option is not supported anymore, it is always set to yes. dnssec-validation can be still turned off.

How To Test

System administrators would receive the most recent stable version of BIND, with improved performance and features. Prerelease is available on COPR.

User Experience

  • named service supports dnssec-policy option, merging dnssec-keymgr into named.
  • DNSSEC trust anchors were merged into trust-anchors section, replacing previous trusted-keys and managed-keys.
  • dig +yaml provides machine parseable output in YAML format

Dependencies

  • bind-dyndb-ldap (required by freeipa)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

Release Notes