From 0c487f4b6eade1440ea40f5a5ffc9b5fd4c41ed1 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Wed, 22 Dec 2004 02:02:10 +0000 Subject: [PATCH] regen --- doc/arm/Bv9ARM.ch02.html | 21 ++- doc/arm/Bv9ARM.ch03.html | 20 +-- doc/arm/Bv9ARM.ch04.html | 42 +++--- doc/arm/Bv9ARM.ch05.html | 4 +- doc/arm/Bv9ARM.ch06.html | 282 ++++++++++++++++++++++++++++++--------- doc/arm/Bv9ARM.ch07.html | 8 +- doc/arm/Bv9ARM.ch08.html | 14 +- doc/arm/Bv9ARM.ch09.html | 108 +++++++-------- doc/arm/Bv9ARM.html | 114 ++++++++-------- 9 files changed, 389 insertions(+), 224 deletions(-) diff --git a/doc/arm/Bv9ARM.ch02.html b/doc/arm/Bv9ARM.ch02.html index 0b293c7edf..e7b38428cd 100644 --- a/doc/arm/Bv9ARM.ch02.html +++ b/doc/arm/Bv9ARM.ch02.html @@ -99,12 +99,12 @@ HREF="Bv9ARM.ch02.html#AEN240" >
2.4. Name Server Intensive Environment Issues
2.5. Supported Operating Systems
DNS -traffic. It is still good practice to have enough memory to load +traffic. +Additionally, if additional section caching +(Section 6.2.16.18) is enabled, +the max-acache-size can be used to limit the amount +of memory used by the mechanism. +It is still good practice to have enough memory to load all zone and cache data into memory — unfortunately, the best way to determine this for a given installation is to watch the name server in operation. After a few weeks the server process should reach @@ -188,7 +199,7 @@ CLASS="sect1" >

2.4. Name Server Intensive Environment Issues

2.5. Supported Operating Systems

3.2. Load Balancing
3.3. Name Server Operations

3.1.1. A Caching-only Name Server

3.1.2. An Authoritative-only Name Server

3.2. Load Balancing

3.3. Name Server Operations

3.3.1. Tools for Use With the Name Server Daemon

3.3.2. Signals

4.4. Split DNS
4.6. TKEY
4.7. SIG(0)
4.9. IPv6 Support in BIND

4.4. Split DNS

4.5.1. Generate Shared Keys for Each Pair of Hosts

4.5.1.1. Automatic Generation

4.5.1.2. Manual Generation

4.5.2. Copying the Shared Secret to Both Machines

4.5.3. Informing the Servers of the Key's Existence

4.5.4. Instructing the Server to Use the Key

4.5.5. TSIG Key Based Access Control

4.5.6. Errors

4.6. TKEY

4.7. SIG(0)

4.8.1. Generating Keys

4.8.2. Signing the Zone

4.8.3. Configuring Servers

4.9. IPv6 Support in BIND

4.9.1. Address Lookups Using AAAA Records

4.9.2. Address to Name Lookups Using Nibble Format

5.1. The Lightweight Resolver Library

5.1. The Lightweight Resolver Library

6.3. Zone File

6.1.1.1. Syntax

6.1.1.2. Definition and Usage

6.1.2. Comment Syntax

6.1.2.1. Syntax

6.1.2.2. Definition and Usage

6.2.1. acl

6.2.3. controls

6.2.5. include

6.2.6. include

6.2.7. key

6.2.8. key

6.2.9. logging

6.2.10. logging

6.2.10.1. The channel

6.2.11. lwres

6.2.12. lwres

6.2.13. masters

6.2.14. masters

6.2.15. optionsyes_or_no ; ] -}; [ disable-algorithms ; ] }; ] + [ use-additional-cache yes_or_no ; ] + [ acache-cleaning-interval number; ] + [ max-acache-size size_spec ; ] +};

6.2.16.2. Forwarding

6.2.16.3. Dual-stack Servers

6.2.16.5. Interfaces

6.2.16.6. Query Address

6.2.16.8. Bad UDP Port Lists

6.2.16.9. Operating System Resource Limits

6.2.16.10. Server Resource Limits

6.2.16.11. Periodic Task Intervals

counter to be incremented.

6.2.16.18. Additional Section Caching

The additional section cache, also called acache, +is an internal cache to improve the response performance of BIND 9. +When the additional section caching is enabled, BIND 9 will +cache internal short-cut to the additional section content for each +answer RR. +Note that acache is an internal caching mechanism of BIND 9, and is +not relevant to the DNS caching server function. +

The additional section caching does not make any difference on the +response content (except the RRsets ordering of the additional +section, see below), but can improve the response performance significantly. +It is particularly effective when BIND 9 acts as an authoritative server +for a zone that has many delegations with many glue RRs. +

In order to achieve the maximum performance improvement by acache, +it is recommended to set additional-from-cache +to no, since the current implementation of acache +does not make a short-cut of additional section information from a DNS +cache data. +

One obvious disadvantage of acache is that it requires much more +memory for the internal cached data. +Thus, if the response performance does not matter and memory +consumption is much more severe, the acache mechanism can be +disabled by setting use-additional-cache to +no. +It is also possible to specify the upper limit of memory consumption +for acache by max-acache-size. +

The additional section caching also has a minor effect on the RRset +ordering in the additional section. +Without acache, the "cyclic" order is effective for the additional +section as well as the answer and authority sections. +However, the additional section caching fixes the ordering when it +first caches an RRset for the additional section, and the same +ordering will be kept in succeeding responses, regardless of the +configuration for rrset-order. +This should be minor, though, since an RRset in the additional section +typically only contains a small number of RRs (and in many cases it +only contains a single RR), in which case the +ordering does not matter much. +

The following is a summary of options related to acache. +

use-additional-cache

If yes, the additional section caching is enabled. +The default value is yes. +

acache-cleaning-interval

The server will remove stale cache entries, based on an LRU based +algorithm, every acache-cleaning-interval minutes. +The default is 60 minutes. +If set to 0, no periodic cleaning will occur. +

max-acache-size

The maximum amount of memory to use for the server's acache, in bytes. +When the amount of data in the acache reaches this limit, the server +will cause more aggressive cleaning so that the limit is not exceeded. +In a server with multiple views, the limit applies separately to the +acache of each view. +The default is unlimited, meaning that +entries are purged from acache only at the periodic cleaning time. +

6.2.19. trusted-keys

6.2.20. trusted-keys

6.2.22. view

6.2.24. zone

6.2.24.1. Zone Types

6.2.24.2. Class

6.2.24.3. Zone Options

6.3. Zone File

6.3.1.1. Resource Records

6.3.1.2. Textual expression of RRs

6.3.2. Discussion of MX Records

6.3.4. Inverse Mapping in IPv4

6.3.5. Other Zone File Directives

6.3.5.1. The $ORIGIN

6.3.5.2. The $INCLUDE

6.3.5.3. The $TTL

6.3.6. BIND

7.2. chroot

7.2. chroot

7.2.1. The chroot

7.2.2. Using the setuid

8.1. Common Problems
8.2. Incrementing and Changing the Serial Number
8.3. Where Can I Get Help?

8.1. Common Problems

8.1.1. It's not working; how can I figure out what's wrong?

8.2. Incrementing and Changing the Serial Number

8.3. Where Can I Get Help?

A.1. Acknowledgments

A.1. Acknowledgments

Bibliography

Standards

[RFC974] 

[RFC1034] 

[RFC1035] 

[RFC2181] 

[RFC2308] 

[RFC1995] 

[RFC1996] 

[RFC2136] 

[RFC2845] 

Proposed Standards Still Under Development

[RFC1886] 

[RFC2065] 

[RFC2137] 

Other Important RFCs About DNS

[RFC1535] 

[RFC1536] 

[RFC1982] 

Resource Record Types

[RFC1183] 

[RFC1706] 

[RFC2168] 

[RFC1876] 

[RFC2052] 

[RFC2163] 

[RFC2230] 

DNS

[RFC1101] 

[RFC1123] 

[RFC1591] 

[RFC2317] 

DNS

[RFC1537] 

[RFC1912] 

[RFC2010] 

[RFC2219] 

Other DNS

[RFC1464] 

[RFC1713] 

[RFC1794] 

[RFC2240] 

[RFC2345] 

[RFC2352] 

Obsolete and Unimplemented Experimental RRs