diff --git a/doc/arm/notes-9.17.1.xml b/doc/arm/notes-9.17.1.xml
index 65b5bfb6e2..da15f4bd31 100644
--- a/doc/arm/notes-9.17.1.xml
+++ b/doc/arm/notes-9.17.1.xml
@@ -15,9 +15,9 @@
     <itemizedlist>
       <listitem>
         <para>
-	  DNS rebinding protection was ineffective when BIND 9 is configured as
-	  a forwarding DNS server.  Found and responsibly reported by Tobias
-	  Klein.  [GL #1574]
+          DNS rebinding protection was ineffective when BIND 9 is configured as
+          a forwarding DNS server. Found and responsibly reported by Tobias
+          Klein. [GL #1574]
         </para>
       </listitem>
     </itemizedlist>
@@ -27,7 +27,13 @@
     <itemizedlist>
       <listitem>
         <para>
-	  None.
+          We have received reports that in some circumstances, receipt of an
+          IXFR can cause the processing of queries to slow significantly. Some
+          of these were related to RPZ processing, which has been fixed in this
+          release (see below). Others appear to occur where there are
+          NSEC3-related changes (such as an operator changing the NSEC3 salt
+          used in the hash calculation). These are being investigated.
+          [GL #1685]
         </para>
       </listitem>
     </itemizedlist>
@@ -37,8 +43,17 @@
     <itemizedlist>
       <listitem>
         <para>
-	  None.
-	</para>
+          A new option, <command>nsdname-wait-recurse</command>, has been added
+          to the <command>response-policy</command> clause in the configuration
+          file. When set to <command>no</command>, RPZ NSDNAME rules are only
+          applied if the authoritative nameservers for the query name have been
+          looked up and are present in the cache. If this information is not
+          present, the RPZ NSDNAME rules are ignored, but the information is
+          looked up in the background and applied to subsequent queries. The
+          default is <command>yes</command>, meaning that RPZ NSDNAME rules
+          should always be applied, even if the information needs to be looked
+          up first. [GL #1138]
+        </para>
       </listitem>
     </itemizedlist>
   </section>
@@ -47,9 +62,9 @@
     <itemizedlist>
       <listitem>
         <para>
-	  The DNSSEC sign statistics used lots of memory.  The number of keys
-	  to track is reduced to four per zone, which should be enough for
-	  99% of all signed zones. [GL #1179]
+          The previous DNSSEC sign statistics used lots of memory. The number of
+          keys to track is reduced to four per zone, which should be enough for
+          99% of all signed zones. [GL #1179]
         </para>
       </listitem>
     </itemizedlist>
@@ -59,20 +74,25 @@
     <itemizedlist>
       <listitem>
         <para>
-	  When an RPZ policy zone was updated via zone transfer
-	  and a large number of records were deleted, <command>named</command>
-	  could become nonresponsive for a short period while deleted
-	  names were removed from the RPZ summary database. This database
-	  cleanup is now done incrementally over a longer period of time,
-	  reducing such delays. [GL #1447]
+          When an RPZ policy zone was updated via zone transfer and a large
+          number of records was deleted, <command>named</command> could become
+          nonresponsive for a short period while deleted names were removed from
+          the RPZ summary database. This database cleanup is now done
+          incrementally over a longer period of time, reducing such delays.
+          [GL #1447]
         </para>
       </listitem>
       <listitem>
         <para>
-	  Migration to dnssec-policy from existing DNSSEC strategy with
-	  auto-dnssec maintain did not work due to bad initializing of the
-	  key states.  Fixed by looking closely at the time metadata to
-	  set the key states to the correct values. [GL #1706]
+          When trying to migrate an already-signed zone from
+          <command>auto-dnssec maintain</command> to one based on
+          <command>dnssec-policy</command>, the existing keys were immediately
+          deleted and replaced with new ones. As the key rollover timing
+          constraints were not being followed, it was possible that some clients
+          would not have been able to validate responses until all old DNSSEC
+          information had timed out from caches. BIND now looks at the time
+          metadata of the existing keys and incorporates it into its DNSSEC
+          policy operation. [GL #1706]
         </para>
       </listitem>
     </itemizedlist>