Solaris DNS Server Installation and Administration

Solaris uses an open source DNS implementation called BIND (Berkeley Internet Name Domain) as its DNS daemon. BIND (Berkeley Internet Name Domain) is the oldest implementation of the DNS protocol that can be traced to original BSD systems.

Contrary to popular urban myth Paul Vixie did nit write the original BIND.  As Kevin Oberman recollected:

The first BIND version (4.3?) was written by the CSRG at UC Berkeley by Kevin Dunlap who was on loan to CSRG by Digital (who also employed Paul at that time). When Paul took over support of BIND at about 4.4, it was a horrid mess and rapidly moving toward death. After some fixes and clean-up of the code, the first real BIND from Paul was 4.8. ISC (including Paul) wrote BIND 8. BIND 9 was contracted out to Nominum and one of the stipulations was that the existing code base could not be used at all and another was that the team that wrote BIND 8 should not work on BIND 9. For that (and other) reason, Paul did not write any of BIND 9

In his comment to the letter Paul Vixie clarified some facts: 

> Well, Paul Vixie wrote bind

nope.  kevin dunlap and other folks at U C Berkeley wrote BIND originally. all i did was fork the code base at 4.8.3, produce King James BIND, then BIND 4.9 through BIND 8.1, and along the way co-founded ISC with rick adams.  also along the way i won the "most cert advisories by a single author" award (which noone has been willing to try to take away from me) and stopped coding.  i'm pleased to announce that BIND9 has no code from BIND8 or BIND4 in it, and also no code from me in it.

--- [email protected] ("Kevin Oberman") writes:

> Paul Vixie did NOT write the original BIND. The first BIND version
> (4.3?) was written by the CSRG at UC Berkeley by Kevin Dunlap who was on
> loan to CSRG by Digital (who also employed Paul at that time).

no, i was employed by Digital later, long after kevin dunlap had moved on.

> When Paul took over support of BIND at about 4.4,

4.8.3.

> it was a horrid mess and rapidly moving toward death.

and there were other code forks besides mine.  what distinguished my work
was that i merged in every change i could understand from every other fork.
(that's why i called it King James BIND, for you literary history buffs.)

> After some fixes and clean-up of the
> code, the first real BIND from Paul was 4.8.

4.9.

> ISC (including Paul) wrote BIND 8.

john gilmore and bob halley had a LOT to do with the creation of BIND8 btw.
(john also taught me to use CVS rather than RCS, to my great betterment,
and he wrote some early DNSSEC code, and negotiated a licensing deal between
RSADSI and ISC... he's an unsung hero in the BIND revolution.)

> BIND 9 was contracted out to Nominum

internet engines.  Which later became nominum.

> and one of the stipulations was that the existing code base could not be
> used at all and another was that the team that wrote BIND 8 should not
> work on BIND 9.

actually, bob halley worked on both BIND8 and BIND9.

> For that (and other) reason, Paul did not write any of BIND 9.

yea, verily.

--- [email protected] (David Conrad) writes:

> However, I don't speak authoritatively (pun intended) on BIND.

and yet, for the record, i agree with everything drc said in his note today.
--
Paul Vixie
 

The source code is licensed under BSD license and includes implementation of:

• a Domain Name System server (named)
• a Domain Name System resolver library
• tools for verifying the proper operation of the DNS server (dig and nslookup). 

When you are working with BIND it's evident how old it is and how people who developed various packages for it were unable to understand the "spirit of Unix" and come with kluges that contradict Unix philosophy, but for some reason stay with us for decades.  Actually first implementations of DNS servers were for the TOPS-20 operating system in 1983.

Still BIND is a pretty vivid demonstration of inability of designers of Unix packages to grasp the spirit of Unix :-) And while the general DNS architecture is sound the BIND implementation was (until version 9 let's hope) a very questionable security-wise. Administration-wise it continues to be challenging to say the least.  IMHO administration was done unnecessary complex by configuration files that are far from being human-friendly and have subtle interdependencies that for some unexplainable reason need to be resolved manually (many scripts exist for this purpose and at least couple of them should probably be used by every non-masochistic DNS admin). 

The structure of DNS configuration files can serve as a good example of how old data-related mini-languages survive in software packages. And they can be quite horrible mess even if the code written by above average programmers. Even in Bind 9  the configuration files remain very cumbersome and their maintenance time consuming and error prone.

Currently the second (or third) generation of Unix administrators needs to suffer from all those unnecessary complexity. In a sense BIND is the greatest failure of open source programming model. Despite its critical role in Internet infrastructure BIND 4 and 8 were probably one of the most "security-challenged" open source applications widely deployed. At least until version 9 was released. For decades it was pretty unusual not have a bind exploit each second quarter. Not that all of those exploit were really dangerous, but still the feeling was that one needs to upgrade and countless hours were spend on countless upgrade of bind by each organization with its own nameserver.

BIND's complexity provided a windows opportunity for book publishers and I believe O'Reilly got a neat revenue from selling four editions of BIND book.

Alternative implementations of DNS servers exist including several open source packages but none get the same level of prominence as original BIND. Of alternative free packages only D. J. Bernstein's djbdns got some traction due to it significantly higher level of security: it is sometimes called "Continuous DNS service without continual software upgrades" :-)

As of Jan 2006 current versions from Internet Systems Consortium, Inc. are

• Current Release
  BIND 9.3.2 [ download ] [ security ] [ manual: html | pdf ]
• Maintenance Releases
  BIND 9.2.6 [ download ] [ security ] [ manual: html | pdf ]
  BIND 8.4.7 [ download ] [ security ]

You should recompile those versions using Studio 11 or download the latest precompiled version from Solaris freeware site. It does not make sense to preserve the version that comes with Solaris 9 or 10.  

In Solaris the daemon in.named is by default placed in /usr/sbin/ . It is stared during system boot if the /etc/named.conf file exists. When configuring nameserver, you need to supply the following information in your /etc/named.conf and files that it refers to (so called DNS resource records) :   

• Names and addresses of root servers.

• The information needed to resolve all domains for which the server is authoritative. Those records, called A records provide name to address translation.

• The information needed to resolve all inverse domains for which the server is authoritative. Those records called IN records provide address to name translation (construction of IN records can be automated as all information necessary is contains in A-record

• Names and addresses of servers for all domains one level below the domain being served by this server. This is sometimes referred to as parenting or delegating.

• All of this information is supplied in configuration files referred to by the BIND configuration file /etc/named. conf and loaded into the in . named cache.

There are two major versions of BIND daemon: version 8 and version 9. Solaris 9 uses BIND 8.x.x implementation. Solaris 10 uses 9.x.x implementation.

/etc/named.conf configuration file determines if the server is a primary, secondary, or cache-only name server. It also specifies the zones over which the server has authority and which data files it should read to get its initial data.

• master server is defined by the type master in the zone statement of /etc/named.conf .
• slave servers are defined by the type slave argument to the zone statement in the /etc/named.conf configuration file.

The/etc/named.conf file consists of statements possibly separated by blank lines. Each statement should end with a semicolon. Some statements can contain a block of statements in curvy brackets. Again, each statement in the block is terminated with a semicolon.

There are several major types of named.conf statements. Four are used in the example below:

1. options Controls global server configuration options and sets default values for other statements.

2. zone Defines a zone. Selectively applies options on a per-zone basis, rather than to all zones.

3. file Defines an include file that contains so called called DNS resource records. Is used to break up the configuration into more easily managed chunks.

4. type Sets designated type associated with a server.

Here is an example of the BIND configuration file /etc/named. conf and its relationship to name server data files.

options {
   DIRECTORY "/var/named";
};

zone "." in {
   type hint;
   file "named.root";
};

zone "softpanorama.org" in {
   type master;
   file "softpanorama.org.zone";
};

zone "10.10.10.in-addr.arpa" in {
   type master;
   file "softpanorama.org.rzone";
};

zone "127.in-addr.arpa" in {
   type master;
   file "loopback-domain-info";
};

Other statements include:

1. acl Defines a named IP address match list used for access control. The address match list designates one or more IP addresses or IP prefixes. The named IP address match list must be defined by an acl statement before it can be used elsewhere. No forward references are allowed.
2. key Specifies a key ID used for authentication and authorization on a particular name server.
3. logging Specifies the information the server logs and the destination of log messages.

Dr. Nikolai Bezroukov

NEWS CONTENTS

• 20071119 : Novel Course 3074_Sample ( Novel Course 3074_Sample, Nov 19, 2007 )
• 20060830 : Implementing a DNS Server on the Solaris 8 OS ( Implementing a DNS Server on the Solaris 8 OS, Aug 30, 2006 )
• 20060127 : DNS Server Setup Template for the Solaris Operating Environment ( June 2000 , Sun )
• 20060127 : currentversions from Internet Systems Consortium, Inc. ( currentversions from Internet Systems Consortium, Inc., Jan 27, 2006 )
• 20060127 : docs.sun.com Solaris 10 Whats New ( docs.sun.com Solaris 10 What's New, )

Old News ;-)

[Nov 19, 2007] Novel Course 3074_Sample/Configure a DNS Server

The configuration of each DNS server type is slightly different. In this objective the following is discussed:

• Configure a Caching-Only DNS Server
• Configure a Master Server for Your Domain
• Configure One or More Slave Servers

[Aug 30, 2006] A community-submitted Tech Tip, Implementing a DNS Server on the Solaris 8 OS, offers suggestions for setup on both SPARC and x86 platforms. -- pretty poor and very basic.

[Jan 27, 2006] DNS Server Setup Template for the Solaris Operating Environment

June 2000 | Sun

You never know when the set up for a trade show, demo, lab, or other project might come to a loggerhead because someone needs a robust internet domain name server (DNS). The function of the DNS is to act as the server that client applications contact to resolve an IP address from the host name. The IP address is then used by network routers to send data packets to the remote server.

In reverse mode, the DNS can also resolve host names when given an IP address. Many UNIX applications use this method to perform security checks, Address Resolution Protocol (ARP), or Reverse Address Resolution Protocol (RARP) to verify that the host name data and IP address do indeed match. For example, if you try to Telnet or FTP to a Solaris host from a renegade laptop using a valid but unresolvable IP address on the LAN, you may notice that it can take up to 60 seconds to receive the login prompt. You can fix this delay by simply adding an entry for host name and IP address into the maps on the primary network DNS.

Setting up a DNS from scratch can be complicated. Although you can read the man pages and generate valid map files from scratch, it is not very efficient. A better way is to follow an example template provided in the next section.

Unpacking Instructions

Download this template to a work directory, such as /var. To unpack the file, at the command line type:

    zcat name.tar.Z | tar xvf -

Fast Installation Overview

For quick installation, do the following:

1. Determine what type of DNS you want and what support information you need from your network provider, such as global caching DNS.
2. Edit the named.* files you need. For releases prior to Solaris 7, use named.boot, named.local, named.cache, named.mydomain, and named.mydomain.rev. For Solaris 7 and Solaris 8, the map files are the same, but edit the named.conf instead of named.boot.
3. Edit the /etc/resolv.conf file. It should look like the following:

       domain mydomain.com
       nameserver 127.0.0.1     ;if DNS server runs on this host
       nameserver 129.200.9.1   ;if this is a remote client

4. Create a symbolic link in /etc/ to either the named.boot or named.conf file and start the DNS (/usr/sbin/in.named).
5. You can verify the DNS is working properly by running some queries to test forward and reverse resolution.

Detailed Installation

1. Determine what kind of DNS you need.

   If you are at a trade show and without Internet access, you need to be a primary.

   If you are at a trade show and have Internet access, find the ISP and ask whether they have (a) a world resolvable caching DNS and (b) a primary for the show floor.

   • If they have (a) but not (b), you will need to be a primary for this subnet. Any reputable ISP will have at least (a).
   • If they have both (a) and (b), but are unreliable for (b), you should be a secondary.
   • If (b) does not have a complete map or maps, you may need to create your own primary for that subnet.

   If you are just starting a new subnet (e.g. you are at a startup company and the person who knows anything about network administration is the IT person), then you probably want to be your own primary for the subnet. You should talk it over with your ISP. If your ISP is responsive and reliable, and doesn't mind that you constantly re-assign IP addresses and hosts, you should use them as your primary. Otherwise, if you are planning to do some very complicated DHCP, IP address sharing, NAT, or network customization, you probably should be your own primary. In other words, if you want your network to be resolvable and routable outside of your network, you may want to arrange with your ISP to give you primary domain DNS control for your subnet and have the ISP act as a "secondary" to your subnet domain. This configuration is common at many large universities. For example, each department or college group manages its own subnet within a large Class A or B network. The institution's top level DNS is actually a secondary for the various smaller subnet primaries.

   If you need to resolve Internet host names outside of the corporate network, but have an inadequate primary DNS on your network, you should become a secondary DNS for your local subnet. You can also add a forwarders entry to the corporate top-level gateway DNS so that you can resolve IP addresses outside of the corporate network. Other people can then configure their hosts to use your DNS as their default to use these features.

2. If you are running Solaris 7 or Solaris 8, examine the named.conf file. Each file is self explanatory and you can copy the /etc/hosts file and add Authoritative records (A) and pointer records (PTR) to your maps.

   Note: For Solaris 7 users who are familiar with BIND8 (old) format named.boot files and want to convert them to the new BIND9 format named.conf files, you can run the /usr/sbin/named-bootconf -i infile -o outfile utility.

   Edit all the files you need, usually:

   Mandatory files
   named.boot or named.conf (depending on OS version)
   named.cache
named.local

   Optional files (for primary DNS)
   named.mydomain
named.mydomain.rev
   [other reverse or forward maps]

   You may have multiple forward and reverse maps because this DNS may be supporting multiple domain names and subnets.
   

3. Edit the /etc/resolv.conf file. It should look like the following:

       domain mydomain.com
       nameserver 127.0.0.1     ;if DNS server runs on this host
       nameserver 129.200.9.1   ;if this is a remote client

   You can have multiple DNS entries in the resolv.conf file. Each entry is searched in top-to-bottom order until the server responds, or times out. Therefore, you should put the server that is the most robust and responds the fastest at the top of the list. When a DNS is successfully queried, it is general practice for the client to use only that server for querying, even if the DNS responds that there are no entries. If the DNS you configured to use on the client is not resolving all of the hosts you know exist, you should contact the administrator for that DNS or simply change to a server that can resolve all the names. If a DNS server is down, you may experience a long wait before the client application fails and switches to use the next DNS. This can vary from 15 to 60 seconds per DNS entry in the resolv.conf file. If you are experiencing DNS resolution delays repeatedly and have access to another server, you should change the resolv.conf file to use another DNS.
   

4. Create a symbolic link in /etc/ to either the named.boot or named.conf file. For example, if you unpacked the file in /var/named on a Solaris 2.6 system, type at the command line:

       ln -s /var/named/named.boot /etc/named.boot

   Start the DNS server by typing:

       /usr/sbin/in.named

5. Test the DNS by running some queries to test forward and reverse resolution. You can use the following forward test:

       /usr/sbin/nslookup myhost

   A sample response looks like:

       Server: localhost
       Address: 127.0.0.1
    
       Name: myhost.mydomain.com
       Address: 129.200.9.1

   You should repeat your test using an IP address instead:

       /usr/sbin/nslookup 129.200.9.2

   A sample response looks like:

       Server: localhost
       Address: 127.0.0.1
    
       Name: myhost2.mydomain.com
       Address: 129.200.9.2

   If the DNS is set up to resolve Internet addresses, you can test this by typing:

       /usr/sbin/nslookup nuc.berkeley.edu

   A sample response looks like:

       Server: localhost
       Address: 127.0.0.1
    
       Non-authoritative answer:
   
       Name: nuc.berkeley.edu
       Address: 128.32.142.96

Disclaimer

This template is supplied "AS IS" without support or warranties.

[Jan 27, 2006] currentversions from Internet Systems Consortium, Inc.

• Current Release
  BIND 9.3.2 [ download ] [ security ] [ manual: html | pdf ]
• Maintenance Releases
  BIND 9.2.6 [ download ] [ security ] [ manual: html | pdf ]
  BIND 8.4.7 [ download ] [ security ]

docs.sun.com Solaris 10 What's New

BIND 9 is new in the Solaris Express 8/04 release. In the Solaris 10 3/05 release, the BIND version was upgraded to BIND version 9.2.4.

BIND is an open source implementation of DNS. BIND is developed by the Internet Systems Consortium (ISC). BIND allows DNS clients and applications to query DNS servers for the IPv4 and IPv6 networks. BIND includes two main components: a stub resolver API, resolver(3resolv), and the DNS name server with various DNS tools.

BIND enables DNS clients to connect to IPv6 DNS servers by using IPv6 transport. BIND provides a complete DNS client-server solution for IPv6 networks.

BIND 9.2.4 is a redesign of the DNS name server and tools by the Internet Systems Consortium (ISC). The BIND version 9.2.4 nameserver and tools are available in the Solaris 10 OS.

BIND 8.x-to-BIND 9 migration information is available in the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Additional information and documentation about BIND 9 is also available on the ISC web site at http://www.isc.org. For information about IPv6 support, see the System Administration Guide: IP Services.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Internal

• DNS Resource Records
• Solaris DNS Security Links

External

• Everything Solaris/DNS for dummies
• DNS Server Setup Template for the Solaris Operating Environment
• docs.sun.com Solaris 9 System Administration Guide Naming and Directory Services (DNS, NIS, and LDAP)
• docs.sun.com Solaris 8 Naming Administration Guide
• BIND 8 for NT >The primary BIND web site is, of course, the industry-sponsored consortium responsible for developing and maintaining BIND, ISC. If you want to master BIND, then sign-up for the ISC BIND users mailing list. It's very active and has some really excellent contributors, such as these "list stars" whose messages I suggest you pay attention to:
  • Barry Margolin
  • Cricket "his bug is on the cover" Liu
  • Jim Reid
  • Joseph S D Rao
  • Kevin Darcy
  • Mark Andrews
  • Michael Voight
  • Ralf Hildebrandt
  • Thor Kottelin
• BIND on-line configuration documentation the ISC detailed technical reference for named.conf
• BIND Operations Guide for BIND4, but much of the detailed info is still valid.
• ***** DNS Resources Directory (DNSRD) -- very good. Highly recommended. More up to date than this collection of links. Maintained by Andr�s Salamon. See also his excellent: DNS tools -- very comprehensive collection

• ISC BIND

• BIND operations guide

• BIND Documentation

• Men & Mice - DNS Related Links
  DNS Information Resources

• DNS Networking

• http://www.securecomputing.com/index.cfm?skey=430 -- list of DNS tutorials

• Unix SysAdm Resources DNS, LDAP, NIS, Directory & Naming Services Yahoo! DNS links DNS Networking search results in UGU IPv4 in-addr.arpa audit (..) -- statistics of DNS servers on the WEB
• AUDIT SUMMARY DATA
• W VERSION DISTRIBUTION SUMMARY
• http://soa.granitecanyon.com - free public dns
• http://www.no-ip.com - free & commercial dns
• http://www.zoneedit.com - free & commercial dns

Reference

Internet Systems Consortium, Inc.

BIND 9 Administrator Reference Manual

BIND FAQ from Nominum Home of DNS inventor. Paul Mockapetris, the inventor of the domain name system, is chief scientist and chairman of the board at Nominum.

Ask Mr DNS facility on the Acme site is a searchable DNS/BIND FAQ + list archive

Simple DNS Configuration Example (RIPE-192)

Probably the quickest way to get going, if you are using BIND 8 on Unix. Just cut and paste the examples and make a few changes for a working setup.

FAQ

FAQ document for the newsgroup comp.protocols.tcp-ip.domains by Chris Peckham. Here is a local copy of the most recently posted text version. You could also try a DNS book, DNSRD tips or Ask Mr. DNS.

FAQ for microsoft.public.windowsnt.dns

FAQ document for the Microsoft newsgroup microsoft.public.windowsnt.dns.

Linux DNS HOWTO

How to set up DNS on Linux, by Nicolai Langfeldt. There are some small problems with this document, but it has some useful tips.

Tutorials

DNS Server Setup Template for the Solaris Operating Environment

Everything Solaris/DNS for dummies

Name Service and Resolver Configuration discusses named and bind configuration. From The Network Administrators' Guide by Olaf Kirch/Andrew Anderson.

Setting up a basic DNS server for a domain by Craig Richmond

Good tutorial document, now somewhat out of date. Part of the BIND distribution.

BOG

Name Server Operations Guide for BIND by Paul Vixie (originally by Kevin J Dunlap and Michael J Karels). Generally known as the BOG; part of the BIND distribution. Here are local HTML (conversion by Graeme Cox), PostScript and text copies. For BIND 4.x

Dealing with Lame Delegations by Bryan Beecher Describes the lamers tool to detect and flag lame delegations.

DNS Demystified by Al Berg Short operational overview.

DNS for Internet Administrators by Andr�s Salamon Slides for one-day DNS course, from October 1996.

The Internet Cookbook: DNS by Robert J. Kohlhepp

Examples of building a DNS, with sample database files; from a series of articles in Network Computing Online, February 1997.

Features of BIND 8.2 by Cricket Liu

Summary of new features of BIND 8.2, by the author of the standard cricket book. 14-Jan-2000

Hedrick

`Keeping track of names and information: the domain system', Section 5 of Introducti on to the Internet Protocols by Charles L. Hedrick. This is a well-known paper from 1987, made available in HTML by Steven E. Newton.

Passive DNS Replication

Describes building partial zone files based on observing the query traffic at a third party name server, by Florian Weimer.

Setting Up Your Own DNS by Gary Kessler

Thorough practical overview.

Style Guide for Zone Files by Paul Vixie

The recommended style for manually maintained zone files, from the maintainer of BIND. Highly recommended.

A Survey of DNS Tools by Cricket Liu

A comparison of nslookup, dig, host, doc, dnswalk, dnsparse and h2n. Slides presented in February 1993.

10 DNS Errors That Will Kill Your Network by Bill Boswell

Common DNS errors in Microsoft Windows environments. Many of these problems are not specific to Windows. (checked 07-Sep-2004)

Tricks of the BIND Trade by Cricket Liu

Slides presented in February 1993. Some of the material is out of date for recent BIND versions.

Webmonkey's quick overview

Very quick overview of DNS from Webmonkey.

What is a domain? by Mark R. Horton

Introductory paper, similar to but easier to read than the fundamental RFCs. Part of the BIND distribution.

http://cramsession.brainbuzz.com/cramsession/microsoft/win2knet_infra/guide.asp

Spitzner, Lance. "DNS Access." 26 January 2000.
URL: http://www.enteract.com/~lspitz/rules/rule6.html (21 July, 2000).

Gray, Damon. "The "IN-ADDR.ARPA" domain and it's relation to DNS."
URL: http://www.wednet.edu/network/whitepapers/in-addr.arpa.domain-whitepaper.html (23 July, 2000).

DNS HOWTO -- Nicolai Langfeldt [email protected] HOWTO become a totally small time DNS admin.

1. Preamble

• 1.1 Legal stuff
• 1.2 Credits and request for help.
• 1.3 Dedication

2. Introduction.

3. A caching only name server.

• 3.1 Starting named

4. A simple domain.

• 4.1 But first some dry theory
• 4.2 Our own domain
• 4.3 The reverse zone

5. A real domain example

• 5.1 /etc/named.conf (or /var/named/named.conf)
• 5.2 /var/named/root.hints
• 5.3 /var/named/zone/127.0.0
• 5.4 /var/named/zone/land-5.com
• 5.5 /var/named/zone/206.6.177

6. Maintenance

7. Converting from version 4 to version 8

8. Questions and Answers

9. How to become a bigger time DNS admin.

Setting up DNS by Jeff Moe. This page explains the basics on how to get your nameserver up and going.

Files needed on primary nameserver (Change db.mydomain.com to db.[whatever your domain is] and db.192.168.222 to db.[whatever your class C is]):

• /etc/resolv.conf

• /var/named/db.cache

• /var/named/db.127.0.0

• /etc/named.boot

• /var/named/db.mydomain.com

• /var/named/db.192.168.222

Files needed on secondary nameserver

• /etc/resolv.conf

• /var/named/db.cache

• /var/named/db.127.0.0

• /etc/named.boot (secondary)

Note that the locations and names of these files can vary quite a bit, but this naming scheme will work fine.

• Text files of examples used here

• Common Mistakes

• Other sources of info

Index of pubdocsunix-tutorials courses

• dns.ps -- PostScript version
• dns.txt -- text version

• Domain Name System (DNS) -- course notes
• FAQ - DNS -- outdated (1993)
• Setting up a basic DNS Server for a domain -- Revision 1.1.2 Craig Richmond [email protected]
  3rd August 1993 Last modified 960804

• Help-Site Computer Manuals - Internet
  • DNS
• Scott Newton's TCP/IP tutorial, DNS section -- not impressive
• DNS Tips and Tricks from the DNS resources directory
• Setting up DNS
• Fast Guide to DNS -- too basic

RFCs

Nice collection can be found at Nominum-Resources-Standards Information-DNS RFCs

See also DNS related RFCs, DNS RFCs.

Search for RFCs is available at Internet Requests for Comments (RFC)

Major RFCs

• RFC 2168 - Resolution of URIs Using the DNS
• RFC1034 "Domain Names - Concepts and Facilities"
• RFC1033 "Domain Administrators Operations Guide"

Worth reading for zone administrators:

• RFC1912 "Common DNS Data File Configuration Errors"
• RFC1713 "Tools for DNS debugging", also translated to HTML

Reference documents about protocols and administrative rules:

• RFC1591 "Domain Name System Structure and Delegation"
• RFC1035 "Domain names - Implementation and Specification", also translated to HTML
• RFC1032 "Domain Administrators Guide"
• RFC1101 "DNS Encoding of Network Names and Other Types"

Full list (from DNS related RFCs):

RFC 805

Computer Mail Meeting Notes by J. Postel

The decision to introduce DNS-type names for mail addressing. Feb-1982

RFC 811

Hostnames Server by K. Harrenstien, V. White and E. Feinler

The original centralized hostname lookup server. Mar-1982

RFC 819

The Domain Naming Convention for Internet User Applications by Z. Su and J. Postel

Documents the original structural ideas of DNS. Aug-1982

RFC 882 obsoleted by RFC 1034. Nov-1983

RFC 883 obsoleted by RFC 1034. Nov-1983

RFC 920

Domain Requirements by J. Postel and J. Reynolds

Administrative document about domains. Will become historical shortly. Oct-1984

RFC 973 obsoleted by RFC 1034. Jan-1986

RFC 974

Mail Routing and the Domain System by Craig Partridge

Describes MX record processing. Jan-1986

RFC 1032

Domain Administrator's Guide by M. Stahl

Explains role of domain administrator. Nov-1987

RFC 1033 updated by RFC 1912.

Domain Administrators Operations Guide by M. Lottor

How-to guide, now somewhat out of date. Nov-1987

RFC 1034 updated by RFC 1101.

Domain Names--Concepts and Facilities by P. Mockapetris

Reference guide, covers just about everything. Nov-1987

RFC 1035 updated by RFC 1706.

Domain Names--Implementation and Specification by P. Mockapetris

Mechanics of the DNS. An HTML version with graphic illustrations is available (thanks to Russ Nelson). A local copy is also available. Nov-1987

RFC 1101 updates RFC 1034.

DNS Encoding of Network Names and Other Types by P. Mockapetris

How to add network names and netmasks to the DNS. Apr-1989

RFC 1122

Requirements for Internet Hosts -- Communication Layers edited by R. Braden

Not directly related to DNS, but section 4 discusses UDP and TCP issues that have important low-level effects on DNS. Oct-1989

RFC 1123

Requirements for Internet Hosts -- Application and Support edited by R. Braden

Includes chapter 6, about DNS. Oct-1989

RFC 1178

Choosing a Name for Your Computer by D. Libes

Good advice to keep in mind when naming computers. Aug-1990

RFC 1183

New DNS RR Definitions by C. Everhart, L. Mamakos and R. Ullmann and edited by P. Mockapetris

New resource records, not widely used. Oct-1990

RFC 1348 updates RFC 1035, obsoleted by RFC 1706. Jul-1992

RFC 1464

Using the Domain Name System To Store Arbitrary String Attributes by R. Rosenbaum

Using TXT records to store arbitrary strings in the DNS. May-1993

RFC 1480

The US Domain by A. Cooper and J. Postel

Policies and procedures related to the .US top-level domain. Jun-1993

RFC 1535

A Security Problem and Proposed Correction With Widely Deployed DNS Software by E. Gavron

Highlights subversion possibilities with default resolver search lists. Oct-1993

RFC 1536

Common DNS Implementation Errors and Suggested Fixes by A. Kumar, J. Postel, C. Neuman, P. Danzig and S. Miller

What to fix and how to fix it, for developers. Oct-1993

RFC 1537 obsoleted by RFC 1912. Oct-1993

RFC 1591

Domain Name System Structure and Delegation by J. Postel

Administrative details about the DNS name space. Mar-1994

RFC 1611

DNS Server MIB Extensions by R. Austein and J. Saperia

Interfacing SNMP to the server side of DNS, waiting to be implemented. May-1994

RFC 1612

DNS Resolver MIB Extensions by R. Austein and J. Saperia

Interfacing SNMP to the client side of DNS, waiting to be implemented. May-1994

RFC 1637 obsoletes RFC 1348, obsoleted by RFC 1706. Jun-1994

RFC 1664 obsoleted by RFC 2163.

Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables by C. Allocchio, A. Bonito, B. Cole, S. Giordano and R. Hagens

Mapping information for converting between X.400 and SMTP addressing into the DNS. Aug-1994

RFC 1706 obsoletes RFC 1348 and RFC 1637.

DNS NSAP Resource Records by B. Manning and R. Colella

How to add OSI-style NSAPs to the DNS using PTR records. Oct-1994

RFC 1712 obsoleted by RFC 1876.

DNS Encoding of Geographical Location by C. Farrell, M. Schulze, S. Pleitner and D. Baldoni

Paul Vixie wrote: `deprecated and retracted by its authors but the RFC editors accidentally published it anyway'. Nov-1994

RFC 1713

Tools for DNS debugging by A. Romao

Overview of some DNS tools. An HTML version is available. Nov-1994

RFC 1794

DNS Support for Load Balancing by T. Brisco

DNS support for balancing loads of many types. Apr-1995

RFC 1811 obsoleted by RFC 1816. Jun-1995

RFC 1816 obsoletes RFC 1811, obsoleted by RFC 2146. Aug-1995

RFC 1876 obsoletes RFC 1712.

A Means for Expressing Location Information in the Domain Name System by C. Davis, P. Vixie, T. Goodwin and I. Dickinson

Geographical location DNS records. Jan-1996

RFC 1884

IP Version 6 Addressing Architecture edited by R. Hinden and S. Deering

All about IPv6 addresses. Dec-1995

RFC 1886

DNS Extensions to support IP version 6 by S. Thomson and C. Huitema

Backward-compatible IPv6 DNS extensions, including new AAAA record type and new domain IP6.INT. Dec-1995

RFC 1912 obsoletes RFC 1537.

Common DNS Operational and Configuration Errors by D. Barr

Errors and common practice in operation of servers and format of data. An HTML version is available. Feb-1996

RFC 1956

Registration in the MIL Domain by D. Engebretson and R. Plzak

Describes the registration policy of the US Department of Defense domain. Jun-1996

RFC 1982

Serial Number Arithmetic by R. Elz and R. Bush

Defines how serial numbers are compared to determine if a zone has been updated. Aug-1996

RFC 1995

Incremental Zone Transfer in DNS by M. Ohta

A mechanism for use with NOTIFY which allows transferring only that part of the zone that changed. Aug-1996

RFC 1996

Notify: a mechanism for prompt notification of authority zone changes by P. Vixie

Describes new NOTIFY opcode for advising slave servers that the master's data has been changed. Aug-1996

RFC 2010

Operational Criteria for Root Name Servers by B. Manning and P. Vixie

Requirements for root name servers. Oct-1996

RFC 2052

A DNS RR for specifying the location of services (DNS SRV) by A. Gulbrandsen and P. Vixie

Generalised MX records for services other than mail. Oct-1996

RFC 2053

The AM (Armenia) Domain by E. Der-Danieliantz

Procedures for registering in the AM TLD. Oct-1996

RFC 2065

Domain Name System Security Extensions by D. Eastlake, 3rd and C. Kaufman

Digital signatures for data integrity and authentication in the DNS. An HTML version is available. Jan-1997

RFC 2136

Dynamic Updates in the Domain Name System (DNS UPDATE) by P. Vixie (editor), S. Thomson, Y. Rekhter and J. Bound

Atomic record-level addition and deletion of DNS information: WINS done properly. Apr-1997

RFC 2137

Secure Domain Name System Dynamic Update by D. Eastlake 3rd

Security for dynamic updates. Apr-1997

RFC 2146 obsoletes RFC 1816.

U.S. Government Internet Domain Names by Federal Networking Council

Registration procedures in the .GOV top-level domain, and first steps in the migration to .FED.US. May-1997

RFC 2163 obsoletes RFC 1664.

Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) by C. Allocchio

Update to RFC 1664, on storing information in the DNS for mapping between X.400 and RFC 822 email addressing. Defines new PX record and .X42D.xx second-level domain names for each country-specific TLD xx. Jan-1998

RFC 2168

Resolution of Uniform Resource Identifiers using the Domain Name System by R. Daniel and M. Mealling

Defines NAPTR (Naming Authority Pointer) record type, which maps URI namespace identifiers to domain names. Jun-1997

RFC 2181 updates RFC 1034, RFC 1035 and RFC 1123.

Clarifications to the DNS Specification by R. Elz and R. Bush

Clarifications regarding multi-homed servers, TTLs, zone cuts, SOA records, the TC (truncated) flag, authoritative/canonical names, and valid labels. An HTML version is available.

Jul-1997

RFC 2182 (also BCP 16)

Selection and Operation of Secondary DNS Servers by R. Elz, R. Bush, S. Bradner and M. Patton

How to select secondary servers. An HTML version is available.

Jul-1997

RFC 2219 (also BCP 17)

Use of DNS Aliases for Network Services by M. Hamilton and R. Wright

The IANA name for a protocol should be used as the domain name for the machine that supports that protocol at a site. An HTML version is available.

Oct-1997

RFC 2230

Key Exchange Delegation Record for the DNS by R. Atkinson

KX records for IP security, assuming Secure DNS. KX defines a host willing to act as a key exchanger for a given domain name. An HTML version is available. Nov-1997

RFC 2240

A Legal Basis for Domain Name Allocation by O. Vaughan

Proposes creation of uniform second-level domain names for commercial organisations, within the country-specific TLD's. Besides a bunch of typos, there appears to be very little of note in this document. Nov-1997

RFC 2247

Using Domains in LDAP/X.500 Distinguished Names by S. Kille, M. Wahl, A. Grimstad, R. Huber and S. Sataluri

Representing domain names as distinguished names (using a new X.500 attribute called DC) so that LDAP can contain DNS information. See also ids-dirnaming. An HTML version is available.

Jan-1998

RFC 2308

Negative Caching of DNS Queries (DNS NCACHE) by M. Andrews

Recommends that negative caching (the caching of information about non-existence of resource records) becomes mandatory in resolvers.

Mar-1998

RFC 2317

Classless IN-ADDR.ARPA delegation by H. Eidnes, G. de Groot and P. Vixie

How to do IN-ADDR.ARPA delegations on arbitrary boundaries, in a way compatible with existing software, by using CNAME records and new zones.

Mar-1998

• Paul Vixie's official BIND page, the reference DNS implementation on behve of Internet Software Consortium
• Internet Software Consortium -- non-profit organization; maintains free versions of BIND, DHCP and INN
• a Web gateway for DNS-related tools
• IP networks database, a reverse database created from the Internic's Whois info;
• Yahoo's index of Whois servers.

FAQs

• tcp-ipdomains-faq -- DNS faq
• REPOST comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 1 of 2)
• REPOST comp.protocols.tcp-ip.domains Frequently Asked Questions (FAQ) (Part 2 of 2)
• BIND FAQ maintained by Ronny H. Kavli (originally written by Craig Richmond)
• Linux DNS Howto
• GraniteCanyon's FAQ about DNS in general and their DNS hosting services in particular
• Setting up a basic DNS server for a domain

Usenet

comp.protocols.dns.bind Last 50 Messages

comp.protocols.dns.ops Last 50 Messages

Training

• dns_security_course from men and mice
• Verison DNS Training (two day course, not bad but expensive)
• Tutorial Program S13pm -- Lisa usually has one
• Tutorial Program T3 -- Paul Vixie tutorial for Usenix