Named.conf - Revision history

Jimbo: Reverted edits by 212.71.37.54 (Talk); changed back to last version by 82.211.152.12

2010-01-11T13:48:17Z

Reverted edits by 212.71.37.54 (Talk); changed back to last version by 82.211.152.12

Show changes

212.71.37.54 at 04:36, 11 January 2010

2010-01-11T04:36:44Z

Show changes

212.71.37.54 at 04:31, 11 January 2010

2010-01-11T04:31:34Z

Show changes

82.211.152.12: /* Zone files */

2009-10-30T22:24:07Z

Zone files

Jimbo: Reverted edits by 80.90.160.194 (Talk); changed back to last version by Jimbo

2008-12-17T01:47:25Z

Reverted edits by 80.90.160.194 (Talk); changed back to last version by Jimbo

Jimbo at 14:10, 27 October 2007

2007-10-27T14:10:00Z

Jimbo at 18:12, 21 June 2007

2007-06-21T18:12:24Z

216.110.12.175 at 15:06, 17 June 2007

2007-06-17T15:06:49Z

88.232.4.215: /* named.conf */

2007-03-26T09:44:13Z

named.conf

Jimbo: /* Zone files */

2006-05-21T19:20:42Z

Zone files

@@ Line 133: / Line 133: @@
                   IN      NS      ns1.masterdomain.net.
                   IN      NS      ns2.masterdomain.net.
-                  MX      10      mail.masterdomain.net.
+                  IN      MX      10 mail.masterdomain.net.
                   IN      A       68.96.111.12

@@ Line 3: / Line 3: @@
 '''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.
+Here is a 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 $

@@ Line 106: / Line 106: @@
 key dynamic.domain.net. {
          algorithm "HMAC-MD5";
-         secret "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f uIIxxei8qm7AVgNBprxtcU FQMzBvU/Y nyM2xbs/C8kF3eJQUA=="";
+         secret "omr5O5so/tZB5XeGuBBf42rrRJRQZB8I9f+uIIxxei8qm7AVgNBprxtcU+FQMzBvU/Y+nyM2xbs/C8kF3eJQUA=="";
 };
@@ Line 142: / Line 142: @@
 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)]].
 [[Category:Important Config Files]]

← Older revision		Revision as of 15:06, 17 June 2007
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 ==

← Older revision		Revision as of 09:44, 26 March 2007
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 ==

@@ Line 141: / Line 141: @@
   ns2             IN      A       68.96.111.11
-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 be configured in the [[root servers]], since masterdomain.net is a [[top level domain]].  For more complex examples, see also [[DNS record types]] and [[BIND (dynamic DNS)]].
+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)]].
 [[Category:Important Config Files]]