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
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.