freebsd-nq/etc/namedb/named.conf

274 lines
11 KiB
Plaintext
Raw Normal View History

1999-08-27 23:37:10 +00:00
// $FreeBSD$
//
// Refer to the named.conf(5) and named(8) man pages, and the documentation
// in /usr/share/doc/bind9 for more details.
//
// If you are going to set up an authoritative server, make sure you
// understand the hairy details of how DNS works. Even with
// simple mistakes, you can break connectivity for affected parties,
// or cause huge amounts of useless Internet traffic.
options {
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
// Relative to the chroot directory, if any
directory "/etc/namedb";
pid-file "/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
2004-09-29 03:49:35 +00:00
statistics-file "/var/stats/named.stats";
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
// listen-on-v6 { ::1; };
// These zones are already covered by the empty zones listed below.
// If you remove the related empty zones below, comment these lines out.
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
// In addition to the "forwarders" clause, you can force your name
// server to never initiate queries of its own, but always ask its
// forwarders only, by enabling the following line:
//
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
// forward only;
// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below. This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
/*
forwarders {
127.0.0.1;
};
*/
/*
Modern versions of BIND use a random UDP port for each outgoing
query by default in order to dramatically reduce the possibility
of cache poisoning. All users are strongly encouraged to utilize
this feature, and to configure their firewalls to accommodate it.
AS A LAST RESORT in order to get around a restrictive firewall
policy you can try enabling the option below. Use of this option
will significantly reduce your ability to withstand cache poisoning
attacks, and should be avoided if at all possible.
Replace NNNNN in the example with a number between 49160 and 65530.
*/
// query-source address * port NNNNN;
};
// If you enable a local name server, don't forget to enter 127.0.0.1
// first in your /etc/resolv.conf so this server will be queried.
// Also, make sure to enable it in /etc/rc.conf.
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "named.root"; };
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
To use this mechanism, uncomment the entries below, and comment
the hint zone above.
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
*/
/*
zone "." {
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
type slave;
file "slave/root.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
};
notify no;
};
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
zone "arpa" {
type slave;
file "slave/arpa.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
};
notify no;
};
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
zone "in-addr.arpa" {
type slave;
file "slave/in-addr.arpa.slave";
masters {
192.5.5.241; // F.ROOT-SERVERS.NET.
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
};
notify no;
};
*/
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
// RFC 1912
zone "localhost" { type master; file "master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file "master/empty.db"; };
// RFC 1912-style zone for IPv6 localhost address
zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; };
// "This" Network (RFCs 1912 and 3330)
zone "0.in-addr.arpa" { type master; file "master/empty.db"; };
// Private Use Networks (RFC 1918)
zone "10.in-addr.arpa" { type master; file "master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; };
// Link-local/APIPA (RFCs 3330 and 3927)
zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; };
// TEST-NET for Documentation (RFC 3330)
zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; };
// Router Benchmark Testing (RFC 3330)
zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; };
zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; };
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
// IANA Reserved - Old Class E Space
zone "240.in-addr.arpa" { type master; file "master/empty.db"; };
zone "241.in-addr.arpa" { type master; file "master/empty.db"; };
zone "242.in-addr.arpa" { type master; file "master/empty.db"; };
zone "243.in-addr.arpa" { type master; file "master/empty.db"; };
zone "244.in-addr.arpa" { type master; file "master/empty.db"; };
zone "245.in-addr.arpa" { type master; file "master/empty.db"; };
zone "246.in-addr.arpa" { type master; file "master/empty.db"; };
zone "247.in-addr.arpa" { type master; file "master/empty.db"; };
zone "248.in-addr.arpa" { type master; file "master/empty.db"; };
zone "249.in-addr.arpa" { type master; file "master/empty.db"; };
zone "250.in-addr.arpa" { type master; file "master/empty.db"; };
zone "251.in-addr.arpa" { type master; file "master/empty.db"; };
zone "252.in-addr.arpa" { type master; file "master/empty.db"; };
zone "253.in-addr.arpa" { type master; file "master/empty.db"; };
zone "254.in-addr.arpa" { type master; file "master/empty.db"; };
// IPv6 Unassigned Addresses (RFC 4291)
zone "1.ip6.arpa" { type master; file "master/empty.db"; };
zone "3.ip6.arpa" { type master; file "master/empty.db"; };
zone "4.ip6.arpa" { type master; file "master/empty.db"; };
zone "5.ip6.arpa" { type master; file "master/empty.db"; };
zone "6.ip6.arpa" { type master; file "master/empty.db"; };
zone "7.ip6.arpa" { type master; file "master/empty.db"; };
zone "8.ip6.arpa" { type master; file "master/empty.db"; };
zone "9.ip6.arpa" { type master; file "master/empty.db"; };
zone "a.ip6.arpa" { type master; file "master/empty.db"; };
zone "b.ip6.arpa" { type master; file "master/empty.db"; };
zone "c.ip6.arpa" { type master; file "master/empty.db"; };
zone "d.ip6.arpa" { type master; file "master/empty.db"; };
zone "e.ip6.arpa" { type master; file "master/empty.db"; };
zone "0.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "1.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "2.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "3.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "4.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "5.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "6.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "7.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "8.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "9.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "a.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "b.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; };
// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "d.f.ip6.arpa" { type master; file "master/empty.db"; };
// IPv6 Link Local (RFC 4291)
zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; };
// IPv6 Deprecated Site-Local Addresses (RFC 3879)
zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; };
zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; };
// IP6.INT is Deprecated (RFC 4159)
zone "ip6.int" { type master; file "master/empty.db"; };
// NB: Do not use the IP addresses below, they are faked, and only
// serve demonstration/documentation purposes!
//
// Example slave zone config entries. It can be convenient to become
// a slave at least for the zone your own domain is in. Ask
// your network administrator for the IP address of the responsible
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
// master name server.
//
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
// Do not forget to include the reverse lookup zone!
// This is named after the first bytes of the IP address, in reverse
// order, with ".IN-ADDR.ARPA" appended, or ".IP6.ARPA" for IPv6.
//
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
// Before starting to set up a master zone, make sure you fully
// understand how DNS and BIND work. There are sometimes
// non-obvious pitfalls. Setting up a slave zone is usually simpler.
//
// NB: Don't blindly enable the examples below. :-) Use actual names
// and addresses instead.
/* An example dynamic zone
key "exampleorgkey" {
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
algorithm hmac-md5;
secret "sf87HJqjkqh8ac87a02lla==";
};
zone "example.org" {
type master;
allow-update {
key "exampleorgkey";
};
file "dynamic/example.org";
};
*/
Bring our default named configuration more in line with current best practices: 1. The old way of generating the localhost zones was not optimal both because they did not exist by default, and because they were not really aligned with BCP. There is no need to have the dynamic data that the make-localhost script generated, and good reasons to do this more "by the book." 2. In named.conf a. Clean up white space b. Add/clarify a few comments c. Slave zones from the root servers instead of using a hints file. This has several advantages, as described in the comments. d. Significantly revamp the default zones, including the forward localhost zone, and the reverse zones for IPv4 and IPv6 loopback addresses. There are extensive comments describing what is included and why. Interested readers should take the time to review the RFCs mentioned in the comments. There is also relevant information about the motivations for hosting these zones in the "work in progress" Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt or its successor. It's also worth noting that a significant number of these empty zones are already included by default in the named binary without any user configuration. e. Because we're including a lot of examples of both local forward zones and slave zones in the default configuration, eliminate some of those examples. 3. Add new localhost-{forward|reverse} zone files, and an "empty" zone to support the changes in 2.d. above. The empty zone file isn't really empty in order to avoid a warning from BIND about a zone file that doesn't contain any A or AAAA records.
2007-06-18 05:58:23 +00:00
/* Example of a slave reverse zone
zone "1.168.192.in-addr.arpa" {
type slave;
file "slave/1.168.192.in-addr.arpa";
masters {
192.168.1.1;
};
};
*/