From: Andreas Gustafsson Date: Tue, 26 Jun 2001 01:58:26 +0000 (+0000) Subject: note that additional-from-cache and additional-from-auth X-Git-Tag: v9.1.3rc3~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=6a5e7231e886374207bb4af3d2ea009a21050ab3;p=thirdparty%2Fbind9.git note that additional-from-cache and additional-from-auth should only be used with 'recursion no;' --- diff --git a/doc/arm/Bv9ARM-book.xml b/doc/arm/Bv9ARM-book.xml index b5641d75835..fbb01b14217 100644 --- a/doc/arm/Bv9ARM-book.xml +++ b/doc/arm/Bv9ARM-book.xml @@ -2,7 +2,7 @@ - + @@ -2879,16 +2879,20 @@ refresh and retry times to the specified values. additional-from-auth additional-from-cache - -These options control the server's behavior when answering queries -which have additional data, or when following CNAME and DNAME -chains to provide additional data. - + + + +These options control the behavior of an authoritative server when +answering queries which have additional data, or when following CNAME +and DNAME chains. + + + When both of these options are set to yes (the default) and a -query is being answered from authoratitive data (a zone +query is being answered from authoritative data (a zone configured into the server), the additional data section of the -reply will be filled in using data from other authoratitive zones +reply will be filled in using data from other authoritative zones and from the cache. In some situations this is undesirable, such as when there is concern over the correctness of the cache, or in servers where slave zones may be added and modified by @@ -2896,12 +2900,46 @@ untrusted third parties. Also, avoiding the search for this additional data will speed up server operations at the possible expense of additional queries to resolve what would otherwise be provided in the additional section. - + + + For example, if a query asks for an MX record for host foo.example.com, and the record found is "MX 10 mail.example.net", normally the address records (A, A6, and AAAA) for mail.example.net will be provided as well, -if known. These options disable this behavior. +if known. Setting these options to no disables this behavior. + + +These options are intended for use in authoritative-only +servers, or in authoritative-only views. +In other words, they should only be set to +no if the option recursion no; +has also been specified. Setting them to no in a +recursive server will have unexpected side effects such as causing +recursion to not function. + + + +Specifying additional-from-cache no actually +disables the use of the cache not only for additional data lookups +but also when looking up the answer. This is usually the desired +behavior in an authoritative-only server where the correctness of +the cached data is an issue. + + + +When a name server is non-recursively queried for a name that is not +below the apex of any served zone, it normally answers with an +"upwards referral" to the root servers or the servers of some other +known parent of the query name. Since the data in an upwards referral +comes from the cache, the server will not be able to provide upwards +referrals when additional-from-cache no +has been specified. Instead, it will respond to such queries +with REFUSED. This should not cause any problems since +upwards referrals are not required for the resolution process. + + +