diff --git a/doc/arm/Bv9ARM.ch03.html b/doc/arm/Bv9ARM.ch03.html index 12bef754dd..5610f87325 100644 --- a/doc/arm/Bv9ARM.ch03.html +++ b/doc/arm/Bv9ARM.ch03.html @@ -472,14 +472,14 @@ CLASS="acronym" of the zone option also-notify, , see Section 6.2.12.7. For more information about notify, , see Section 6.2.12.1.

The incremental zone transfer (IXFR) protocol is a way for slave servers to transfer only changed data, instead of having to transfer the entire zone. The IXFR protocol is documented in RFC - 1995.

When acting as a master,

Here is an example configuration for the setup we just described above. Note that this is only configuration information; - for information on how to configure your zone files, Section 3.1

Internal DNS server config:


acl internals { 172.16.72.0/24; 192.168.1.0/24;
-};
+>
+acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
 acl externals { bastion-ips-go-here; };
+
 options {
     ...
     ...
     forward only;
-    forwarders { bastion-ips-go-here; }; // forward to external
-servers
-    allow-transfer { none; };															// sample allow-transfer
-(no one)
-    allow-query { internals; externals; };															// restrict
-query access
-    allow-recursion { internals; };															// restrict recursion
+>; 
+    };
+    allow-transfer { none; };			// sample allow-transfer (no one)
+    allow-query { internals; externals; };	// restrict query access
+    allow-recursion { internals; };		// restrict recursion
     ...
     ...
 };
-zone "site1.example.com" { 															//
-sample slave zone
+
+zone "site1.example.com" { 			// sample slave zone
   type master;
   file "m/site1.example.com";
-  forwarders { }; 															// do normal iterative
-															// resolution (do not forward)
+  forwarders { }; 				// do normal iterative
+						// resolution (do not forward)
   allow-query { internals; externals; };
   allow-transfer { internals; };
 };
+
 zone "site2.example.com" {
   type slave;
   file "s/site2.example.com";
@@ -507,6 +509,7 @@ zone "site2.example.com" {
   allow-query { internals; externals; };
   allow-transfer { internals; };
 };
+
 zone "site1.internal" {
   type master;
   file "m/site1.internal";
@@ -514,6 +517,7 @@ zone "site1.internal" {
   allow-query { internals; };
   allow-transfer { internals; }
 };
+
 zone "site2.internal" {
   type slave;
   file "s/site2.internal";
@@ -527,28 +531,27 @@ zone "site2.internal" {
 >External (bastion host) DNS server config:


acl internals { 172.16.72.0/24; 192.168.1.0/24;
-};
+>
acl internals { 172.16.72.0/24; 192.168.1.0/24; };
+
 acl externals { bastion-ips-go-here; };
+
 options {
   ...
   ...
-  allow-transfer { none; };															// sample allow-transfer
-(no one)
-  allow-query { internals; externals; };															// restrict
-query access
-  allow-recursion { internals; externals; };															// restrict
-recursion
+  allow-transfer { none; };			// sample allow-transfer (no one)
+  allow-query { internals; externals; };	// restrict query access
+  allow-recursion { internals; externals; };	// restrict recursion
   ...
   ...
 };
-zone "site1.example.com" {															//
-sample slave zone
+
+zone "site1.example.com" {			// sample slave zone
   type master;
   file "m/site1.foo.com";
   allow-query { any; };
   allow-transfer { internals; externals; };
 };
+
 zone "site2.example.com" {
   type slave;
   file "s/site2.foo.com";
@@ -606,7 +609,7 @@ for TSIG.

TSIG might be most useful for dynamic update. A primary server for a dynamic zone should use access control to control updates, but IP-based access control is insufficient. Key-based - access control is far superior, . The nsupdate @@ -856,11 +859,11 @@ CLASS="command" >host1-host2.".

The more +>You may want to read about the more powerful update-policy statement statement in Section 6.2.20.4.

BIND 9 includes a new lightweight resolver library and resolver daemon which new applications may choose to use to avoid - the complexities of A6 chain following and bitstring labels,Chapter 5.


$ORIGIN example.com.
-host					1h		IN	AAAA	3ffe:8050:201:1860:42::1
+host		3600	IN	AAAA	3ffe:8050:201:1860:42::1
 

While their use is deprecated, they are useful to support @@ -1390,7 +1393,7 @@ NAME="AEN934" >


$ORIGIN example.com.
-host					1h		IN	A6	0	3ffe:8050:201:1860:42::1
+host		3600	IN	A6	0 3ffe:8050:201:1860:42::1
 

$ORIGIN	example.com.
-host			1h	IN	A6	64	0:0:0:0:42::1											company.example1.net.
-host			1h	IN	A6	64	0:0:0:0:42::1					company.example2.net.
+host		3600	IN	A6	64 0:0:0:0:42::1 company.example1.net.
+host		3600	IN	A6	64 0:0:0:0:42::1 company.example2.net.
 

ISP1 will use:


$ORIGIN example1.net.
-company				1h		IN		A6	0	3ffe:8050:201:1860::
+company		3600	IN	A6	0 3ffe:8050:201:1860::
 

ISP2 will use:


$ORIGIN example2.net.
-company				1h		IN		A6	0	1234:5678:90ab:fffa::
+company		3600	IN	A6	0 1234:5678:90ab:fffa::
 

When


$ORIGIN example.com.
-@			4h		IN		NS		ns0
-			4h		IN		NS		ns1
-ns0			4h		IN		A6		0						3ffe:8050:201:1860:42::1
-ns1			4h		IN		A		192.168.42.1
+@		14400		IN	NS		ns0
+		14400		IN	NS		ns1
+ns0		14400		IN	A6		0 3ffe:8050:201:1860:42::1
+ns1		14400		IN	A		192.168.42.1
 

It is recommended that IPv4-in-IPv6 mapped addresses not @@ -1496,7 +1499,7 @@ CLASS="literal" >


$ORIGIN 0.6.8.1.1.0.2.0.0.5.0.8.e.f.f.3.ip6.int.
-1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0				4h										IN		PTR		host.example.com.
+1.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0	  14400 IN 	PTR	host.example.com.
 

$ORIGIN \[x3ffe805002011860/64].ip6.arpa.
-\[x0042000000000001/64]									4h			IN			PTR			host.example.com.
+\[x0042000000000001/64] 	14400 	IN 	PTR	host.example.com.
 

$ORIGIN example.com.
-host						A6		64		::1234:5678:1212:5675 cust1.example.net.
-						A6		64		::1234:5678:1212:5675 subnet5.example2.net.
+host			A6	64	::1234:5678:1212:5675 cust1.example.net.
+			A6	64	::1234:5678:1212:5675 subnet5.example2.net.
 $ORIGIN example.net.
-cust1						A6		48		0:0:0:dddd:: ipv6net.example.net.
-ipv6net						A6		0		aa:bb:cccc::
+cust1			A6	48	0:0:0:dddd:: ipv6net.example.net.
+ipv6net			A6	0	aa:bb:cccc::
 $ORIGIN example2.net.
-subnet5						A6		48		0:0:0:1:: ipv6net2.example2.net.
-ipv6net2						A6		0		6666:5555:4::
+subnet5			A6	48	0:0:0:1:: ipv6net2.example2.net.
+ipv6net2		A6	0	6666:5555:4::
 

This sets up forward lookups. To handle the reverse lookups, @@ -1578,7 +1581,7 @@ would have:


$ORIGIN \[x00aa00bbcccc/48].ip6.arpa.
-\[xdddd/16]								DNAME		ipv6-rev.example.com.
+\[xdddd/16]		DNAME		ipv6-rev.example.com.
 

and


$ORIGIN \[x666655550004/48].ip6.arpa.
-\[x0001/16]								DNAME		ipv6-rev.example.com.
+\[x0001/16]		DNAME		ipv6-rev.example.com.
 


$ORIGIN ipv6-rev.example.com.
-\[x1234567812125675/64]								PTR				host.example.com. 
+\[x1234567812125675/64]	PTR		host.example.com. 
 
or acl_name elements, +> elements, see Section 6.1.1key statement defines a shared - secret key for use with TSIG, Section 4.4.

This is the grammar of the optionoptions statement in the | response response )( (the default), DNS NOTIFY messages are sent when a zone the server is authoritative for -changes, Section 3.3. @@ -4402,7 +4402,7 @@ or have a different forward only/first behavior, -or not forward at all, Section 6.2.19.

Access to the server can be restricted based on the IP address -of the requesting system. Section 6.1.1 for @@ -7655,7 +7655,7 @@ VALIGN="MIDDLE" allow-query in Section 6.2.12.4

See the description of allow-transfer in Section 6.2.12.4.

max-transfer-time-out under under Section 6.2.12.7.

max-transfer-idle-out under under Section 6.2.12.7.