|
|
| Line 1: |
Line 1: |
| − | == named.conf ==
| |
| − |
| |
| − | '''Named.conf''' controls system-wide configuration of [[named]] (*nix's standard [[DNS]] server, the Berkeley Internet Name Daemon), and also tells it where to find the files used to control individual domains, which are usually referred to as '''zones''' when discussing DNS administration.
| |
| − |
| |
| − | Here is an sample '''named.conf''', in which the global section instructs [[named]] to try to resolve queries through an ISP's DNS servers before falling back on the [[root servers]] if the ISP's servers fail to respond. After that, a few sample zone configurations are given - but as you will see, in most cases, the majority of the detail in individual zones is in the '''zone files''' themselves.
| |
| − |
| |
| − | <nowiki>// $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.4 2001/12/05 22:10:12 cjc Exp $
| |
| − | //
| |
| − | // Refer to the named.conf(5) and named(8) man pages for details. If
| |
| − | // you are ever going to setup a primary server, make sure you've
| |
| − | // understood the hairy details of how DNS is working. Even with
| |
| − | // simple mistakes, you can break connectivity for affected parties,
| |
| − | // or cause huge amount of useless Internet traffic.
| |
| − |
| |
| − | options {
| |
| − | directory "/etc/namedb";
| |
| − |
| |
| − | // Limit to using forwarders ONLY by enabling the following line:
| |
| − | //
| |
| − | // forward only;
| |
| − |
| |
| − | // Set forwarders to attempt to resolve DNS queries at lower-level
| |
| − | // caching DNS servers (typically, your ISP's), reducing load on
| |
| − | // the root servers and the internet in general. NOTE: even without
| |
| − | // setting "forward only", using frequently-broken forwarders will,
| |
| − | // sadly, DRASTICALLY impact your own performance.
| |
| − |
| |
| − | forwarders {
| |
| − | 4.21.223.2;
| |
| − | 4.21.223.2;
| |
| − | };
| |
| − |
| |
| − |
| |
| − | // Set query-source address to force a specific source port
| |
| − | // for outbound queries.
| |
| − | //
| |
| − | // query-source address * port 53;
| |
| − |
| |
| − | /*
| |
| − | * Specify a location for the dumpfile (may be necessary if running in a sandbox)
| |
| − | */
| |
| − | // dump-file "s/named_dump.db";
| |
| − | };
| |
| − |
| |
| − | // If you are running a local name server, don't forget to put 127.0.0.1 in the first place
| |
| − | // in your </nowiki>[[/etc/resolv.conf]] and enable it in /[[etc/rc.conf]].<nowiki>
| |
| − |
| |
| − |
| |
| − | // Ultimately, DNS queries are an example of hierarchical buck-passing: root queries begin
| |
| − | // with the [[root servers]] for the internet, which don't know the answer, and possibly not
| |
| − | // even who does know the answer - but they know how to get you one step closer. The buck keeps
| |
| − | // passing downwards until you finally reach the [[authoritative nameserver]] for the record
| |
| − | // you're trying to resolve. This entry points out the [[root servers]] if your server should
| |
| − | // need them.
| |
| − |
| |
| − | zone "." {
| |
| − | type hint;
| |
| − | file "named.root";
| |
| − | };
| |
| − |
| |
| − | // This is a simple "reverse zone", which points IP addresses to [[canonical DNS names]] instead
| |
| − | // of vice-versa. Ideally, you should have a complete zone file for your LAN IP space as well as
| |
| − | // the subnet your WAN occupies. In practice, many smaller companies never get this done properly.
| |
| − |
| |
| − | zone "0.0.127.IN-ADDR.ARPA" {
| |
| − | type master;
| |
| − | file "localhost.rev";
| |
| − | };
| |
| − |
| |
| − | // This is a reverse IPv6 zone. We won't have enough IPv4 (dotted quad style) addresses for
| |
| − | // everybody forever. Life will not be fun when six-bone is a necessity. Life will be even LESS
| |
| − | // fun in the last, gruesome days of the necessary switch. (Look at this monster!)
| |
| − |
| |
| − | 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.IP6.INT" {
| |
| − | type master;
| |
| − | file "localhost.rev";
| |
| − | };
| |
| − |
| |
| − | // This is a simple slave zone. We don't actually write or control this zone file, we just
| |
| − | // ask its real master if we can have a copy of it so that we can help distribute it to others.
| |
| − | // NOTE: attempting to slave a domain that you don't have any business with is VERY frowned upon.
| |
| − |
| |
| − | zone "slavedomain.com" {
| |
| − | type slave;
| |
| − | file "zones/slavedomain.com";
| |
| − | masters {
| |
| − | 65.43.99.11;
| |
| − | };
| |
| − | };
| |
| − |
| |
| − | // This is a simple master zone. We originate and control the zone file which describes this
| |
| − | // zone. We may or may not choose to allow others to slave it for us. In this case, we are
| |
| − | // not securing it, so anyone who wants to slave it may do so.
| |
| − |
| |
| − | zone "masterdomain.net" {
| |
| − | type master;
| |
| − | file "zones/masterdomain.net";
| |
| − | };
| |
| − |
| |
| − | // This is a dynamically updated zone. We originate and control it, but only a small "seed"
| |
| − | // is statically maintained on the server - the rest is updated, deleted, refreshed, etc by
| |
| − | // clients with no fixed IP address as they need to in order to let others find them. The
| |
| − | // privilege to update records in this zone is secured with a crypto key. The key is *not*
| |
| − | // visible to simple queries from the internet.
| |
| − |
| |
| − | key dynamic.domain.net. {
| |
| − | algorithm "HMAC-MD5";
| |
| − | secret "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f+uIIxxei8qm7AVgNBprxtcU+FQMzBvU/Y+nyM2xbs/C8kF3eJQUA=="";
| |
| − | };
| |
| − |
| |
| − | zone "dynamic.domain.net" {
| |
| − | type master;
| |
| − | file "zones/dynamic.domain.net";
| |
| − | allow-update{
| |
| − | key dynamic.domain.net;
| |
| − | };
| |
| − | };</nowiki>
| |
| − |
| |
| − |
| |
| | == Zone files == | | == Zone files == |
| | | | |
This is a very simple (but serviceable) zone file, with one webserver that responds to either masterdomain.net or www.masterdomain.net, and two individual nameservers. (These nameservers will also have A records configured in the root servers, since masterdomain.net is a second level domain. For more complex examples, see also DNS record types and BIND (dynamic DNS).
