]> git.ipfire.org Git - thirdparty/bind9.git/commitdiff
regen
authorMark Andrews <marka@isc.org>
Mon, 24 Sep 2007 05:40:25 +0000 (05:40 +0000)
committerMark Andrews <marka@isc.org>
Mon, 24 Sep 2007 05:40:25 +0000 (05:40 +0000)
FAQ.xml

diff --git a/FAQ.xml b/FAQ.xml
index 3b0c8dffedb1fe94aa7d44292c99ef5535e85672..ba355932d768f8ca5eedb767b8bf60f9ffd30217 100644 (file)
--- a/FAQ.xml
+++ b/FAQ.xml
@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: FAQ.xml,v 1.4.4.13 2007/09/24 02:40:29 marka Exp $ -->
+<!-- $Id: FAQ.xml,v 1.4.4.14 2007/09/24 05:40:25 marka Exp $ -->
 
 <article class="faq">
   <title>Frequently Asked Questions about BIND 9</title>
@@ -619,49 +619,47 @@ zone "list.dsbl.org" {
         </programlisting>
       </answer>
     </qandaentry>
-    
-        <qandaentry>
-          <question>
-       <para>
-         Can you help me understand how BIND 9 uses memory to store DNS zones?
-       </para>
-       <para>
-         Some times it seems to take several times the amount of memory it needs to store the zone.
-       </para>
-          </question>
-          <answer>
-            <para>
-               When reloading a zone named my have multiple copies of the
-               zone in memory at one time.  The zone it is serving and the
-               one it is loading.  If reloads are ultra fast it can have more
-               still.
-               </para>
-            <para>
-               e.g.
-                       Ones that are transferring out, the one that it is serving
-               and the one that is loading.
-               </para>
-          <para>
-               BIND 8 destroyed the zone before loading and also killed
-               off outgoing transfers of the zone.
-               </para>
-          <para>
-               The new strategy allows slaves to get copies of the new
-               zone regardless of how often the master is loaded compared
-               to the transfer time.  The slave might skip some intermediate
-               versions but the transfers will complete and it will
-               keep reasonably in sync with the master.
-               </para>
-          <para>
-               The new strategy also allows the master to recover from
-               syntax and other errors in the master file as it still has
-               an in-core copy of the old contents.
-               </para>
-          </answer>
-        </qandaentry>
-    
-    
-    
+
+    <qandaentry>
+      <question>
+       <para>
+         Can you help me understand how BIND 9 uses memory to store
+         DNS zones?
+       </para>
+       <para>
+         Some times it seems to take several times the amount of
+         memory it needs to store the zone.
+       </para>
+      </question>
+      <answer>
+       <para>
+         When reloading a zone named my have multiple copies of
+         the zone in memory at one time.  The zone it is serving
+         and the one it is loading.  If reloads are ultra fast it
+         can have more still.
+       </para>
+       <para>
+         e.g.  Ones that are transferring out, the one that it is
+         serving and the one that is loading.
+       </para>
+       <para>
+         BIND 8 destroyed the zone before loading and also killed
+         off outgoing transfers of the zone.
+       </para>
+       <para>
+         The new strategy allows slaves to get copies of the new
+         zone regardless of how often the master is loaded compared
+         to the transfer time.  The slave might skip some intermediate
+         versions but the transfers will complete and it will keep
+         reasonably in sync with the master.
+       </para>
+       <para>
+         The new strategy also allows the master to recover from
+         syntax and other errors in the master file as it still
+         has an in-core copy of the old contents.
+       </para>
+      </answer>
+    </qandaentry>
     
     </qandadiv> <!-- Configuration and Setup Questions -->