DNS recommendations - the paper

Content-Description: DNS recommendations
RIPE DNS-WG paper
					DNS recommendations
 
 
Originally by:
 
Hans Niklasson <hasse at swip.net>
Amar Andersson <amar at telia.net>

Reworked by:

Elmar K. Bins <ekb at ivm.net>
(use the dns-wg at ripe.net list for discussion :-) )


Remark to dns-wg:

Although (or maybe because of) being new to RIPE as an active person,
I was very unsatisfied with the status of this paper after having
attended Hans' presentation and thought that given experience with DNS
getting the paper ready would not take one too long.


Rationale:

So what this paper should deliver is a structured guide to what a DNS
administrator should regard when setting up her zones. Many of us know
their parameters by heart whereelse others are new to the business and
still have to look up parts of it. Not to mention copying broken zones
as I did for a long time (and it was a pain to fix all of them).
 
 
Scope: 
 
This documents act as a recommendation for configuring your DNS. This is
NOT a requirement, only a recommendation of things to think about when
setting up your DNS.
 
 
Purpose:
 
To decrease lame delegations and limit unecessary traffic due to resolving
problems, among other things.
 
 
Records:
-----------------------------------------------------------------------------
 
=================================
SOA	Start of Authority Record
=================================

Synopsis
	@ IN SOA <originating dns server> <dottified admin email>\
	         ( <serial number> <refresh> <retry> <expire> <minimum TTL> )


Example
	@ IN SOA ns.isp.net. netmaster.isp.net.
	         ( 1998100100 86400 3600 604800 345600 )
 

Semantics
		The SOA record gives the originating host's name, the email
		address of the person responsible for the zone, timeout values
		to be used by secondaries and the TTL preset/default.
		There is only one SOA record per zone.

	originating dns server:
		Canonical hostname of the DNS server authoritatively
		carrying this zone. In case of hidden primary setup,
		put the exposed primary. Don't forget to close with a dot.

	dottified admin email:
		The administrator's email address in a form where the "@"
		has been replaced by a dot. To regain the address, replace
		the first dot by an at sign.

	serial number:
		Changed zones are only reloaded if a higher serial number
		than the already known one is encountered, so be sure to
		increase this number with every change you want to be seen.
	    
	refresh:
		Secondaries check every <refresh> seconds, whether the SOA
		on the primary has changed. If yes, a zone transfer is done.

	retry:
		A secondary having been unable to do a zone transfer because
		of unreachable of the primary retries every <retry> seconds.

	expire:
		The zone's information is considered invalid by the secondary
		if the primary could not be reached for <expire> seconds.

	minimum TTL:
		This is the default value for all records in the zone file
		which can be overriden by values for the individual records.
		After <minimum TTL> seconds, the zone information on the
		caching nameserver becomes invalid and has to be re-fetched
		from an authoritative server.

		NOTE: This field was intended to be a minimum value for
		      all records in the zone but is now widely implemented
		      as giving the default.


Recommendations and remarks
	
	originating dns server:
		As stated above, insert the name of the originating
		server that is reachable from the Internet.

	dottified admin email:
		The email address here cannot contain dots left of
		the "@" sign, since it's always the _first_ dot
		that's being replaced.

		Remember: This email address must be valid. So it
		seems to be good practice to use a role account address
		instead of a personal address - just in case your admin
		leaves your company.

	serial number:
		There's a widely agreed upon form of the serial number
		that is both easily readable and less errorprone which
		reads YYYYMMDDnn with YYYY being the 4-digit year (year
		2000 is near), MM the 2-digit month, DD the day
		(again 2 digits) and nn the number of the latest update
		of the zone on the same day. All of those fields lest
		the year are left-padded with zeroes.

	refresh:
		This timeout determines the "currentness" of the
		secondaries' information about a zone. Set it to a lower
		value if changes to the zone are expected in the near
		future, so your secondary servers stay up to date.

		86400 (24 hours) seems a reasonable value to start with.

		NOTE: If you are running bind 8.x, you may keep this
		      value pretty high and have your DNS server send
		      notification signals to your secondaries. [jh]

	retry:
		The retry timeout should be fairly low to have the
		secondary regain authoritativeness as soon as possible
		after the primary has become available again.
		Of course, setting this too low will only mean wasting
		bandwidth.

		3600 (1 hour) seems a reasonable value although most
		of us are using longer retry timeouts.

	expire:
		Old data is, speaking of customers, almost always better
		than no data at all, so keep this value high enough to
		be able to buy and install a machine within expiry time
		if your primary dies.

		604800 (7 days) is the value used here. [ekb]

	minimum TTL:
		Like with the refresh value, if a quick change to the
		zone is expected in the near future, temporarily lower
		the minimum TTL. Don't forget to increase it to a
		reasonable value after the change is done, because this
		value is probably the most common source of bandwidth
		waste in the whole Internet ;-)

		345600 (4 days) may already be too short for a stable zone.




===========================
NS	Name Server Records
===========================

Synopsis
	[<zone>] [<TTL>] IN NS <authoritative server>

Examples
	    IN NS ns.isp.net.		; NS for all of the zone's domain
	bla IN NS ns.cust.com. 		; subdelegation for bla.<zone>

Semantics
		As you might have guessed already, this record denotes
		the supposed-to-be authoritative DNS servers for the
		current zone (or the zone given).
	
	authoritative server:
		The <authoritative server> given must be the FQDN
		for the nameserver machine. Check its correctness in
		advance and don't forget the trailing dot.

Recommendations and remarks
	Have the zone's NS records, the registry's and RIPE's nameserver
	information consistent, and do not give nameservers with whose
	administrators you have not coordinated in advance. Remember that
	most registries require you to have at least two authoritative
	servers reachable via different routes.


 
==============================
MX	Mail Exchanger Records
==============================

Synopsis
	[<host/subdom name>] [<TTL>] IN MX <preference> <mailhost>

Examples
	    IN MX 100 relay.isp.net.	; fallback MX for domain <zone>
	    IN MX 10  mail.cust.com.	; final MX

	bla IN MX 100 relay.isp.net.	; fallback MX for bla.<zone>
	    IN MX 10  blamail		; blamail.<zone> needs an A record

Semantics
		MX records tell a foreign mail server where to deliver
		mail to addresses in our domain.

	preference:
		This field is the numerical preference for mail delivery
		to the machine mentioned. Lower values are tried first.

	mailhost:
		Mentions the name of a machine that accepts mail for our
		domain.

Recommendations and remarks
		FQDNs are preferred, local (to <zone>) hosts are can be
		used as well. Verify that A records exist for the MX
		hosts and don't forget the trailing dot on FQDNs.
		Have at least two MX records to ensure delivery.

		It is not a good idea to have MX records point to CNAME'd
		hosts. This will almost certainly get you into a lot of
		trouble. Use hosts with proper A records instead.
		

=======================
A	Address Records
=======================

Synopsis
	[<hostname>] [<TTL>] IN A <IPV4 address> [<IPV4 address> ...]

Examples
	mail IN A 123.45.67.8			; our mail host
	www  IN A 123.45.67.10 123.45.67.11	; multiple hardware
	     IN A 123.45.67.9			; <zone> as a hostname ;-)

Semantics
		A records contain the data that performs name-to-number
		translation.

Recommendations and remarks
		Do not use FQDNs in the <host> part. Hosts in subdomains
		à la "www.internal", which resolve to "www.internal.<zone>"
		are okay though. Remember that IP addresses do not end in
		a dot. Do not forget to maintain reverse delegation as well.


==============================
CNAME	Canonical Name Records
==============================

Synopsis
	<alias> [<TTL>] IN CNAME <hostname>

Example
	news IN CNAME news.isp.net.

Semantics
		CNAME records provide a means to give aliases to machines.
		This can be used to have entries in one zone have the same
		data as hosts in a completely different zone. If a hosts IP
		address changes in the other domain there is no maintenance
		necessary on our side to change the hosts IP address

Recommendations and remarks
		CNAME records are not being cached by name servers and thus
		should be used as rarely as possible to avoid unnecessary
		network traffic. It is not a good idea to have MX records
		point to CNAME'd hosts.


=======================
PTR	Reverse Records
=======================

Synopsis
	<ip-fragment> [<TTL>] IN PTR <hostname> [<hostname> ...]

Examples
	123.45.67.8 IN PTR mail.cust.com.
	10          IN PTR www.cust.com.

Semantics
		PTR records provide the reversed functionality of A records,
		resolving IP addresses to hostnames.

Recommendations and remarks
         	Make sure that your PTR and A records match.
		Having a customer use machines without PTR records will
		resume in unresponsive FTP servers, which often do reverse
		lookups for security purposes.
	


=========================
HINFO	Host Info Records
=========================

Synopsis
	<host> [<TTL>] IN HINFO <CPU> <OS>

Examples
	play IN HINFO i586 Linux-2.1.107

Semantics
		HINFO records contain information about the CPU type and the
		operating system running on a host.

Recommendations and remarks
		Giving away information about CPU and operating system may
		open security holes. There seem to be a few reasons to be
		this open to the Internet community, some of which can be
		found in RfC 1035. I would strongly recommend not using
		HINFO records for security reasons. The Internet is no
		more the safe haven it has been.

		The values here were once required to be standardized CPU
		and OS names (see RfC 1010 and descendants), but are more
		or less free strings nowadays.


==============================================
WKS	Well Known Service Description Records
==============================================

Synopsis
	<host> [<TTL>] IN WKS <address> <protocol> <service> [<service>...]

Examples
	mail IN WKS 123.45.67.8 UDP domain
	     IN WKS 123.45.67.8 TCP smtp domain

Semantics
	The Well Known Services record describes the record provided
	by a particular protocol on a particular interface. The protocol
	is usually UDP or TCP, although it can be any of the protocols in
	/etc/protocols. The services can be any of the /etc/services
	services that use a port below 256.

Recommendations and remarks
	The WKS record is seldom used.



====================
TXT	Text Records
====================

Synopsis
	<host> [<TTL>] IN TXT <text>

Examples
	news IN TXT Yesterday's news are today's olds.

Semantics
	The values found in TXT records are entirely up to free interpretation.


-----------------------------------------------------------------------------


General recommendations, remarks and tips
-----------------------------------------------------------------------------

Glue records
	"Glue records" is a term that describes entering A records into
	a zone for machines whose hostnames do not lie within <zone>.
	With these glue records one tries to achieve resolution for foreign
	machines that are being used e.g. as name servers or mail exchangers.

	Glue records should almost never be necessary, provided the ISP
	has set up their nameservers properly. If this is not the case,
	why would you trust them to have their mail relays functioning?

	If you use glue records, don´t add unnecessary ones. This can cause
	resolving problems if the host changes IP address.
 
Trailing dots: 
        Don´t forget to add a dot (".") to the end of the domain/hostname. If this
	is forgotten, this will have the DNS add <zone> to the domain/hostname
	again. This will cause resolving problems.

	Something like
	  IN MX 10 mail.cust.com

	Will lead to
	  IN MX 10 mail.cust.com.cust.com.
	when fully resolved.
 
 
Legal characters: 
        Only A-Z/a-z (case does not matter), 0-9 and - are recommended.
	In fact, the full range of 8 bit characters is allowed everywhere
	but in hostnames. Yet to be on the secure side, do not use more
	than the range mentioned above. Some services may be more restricted
	than DNS.
 
 
General Points:
        Always use the latest version of the DNS software for your platform.
	If you use bind, you should consider changing to the 8.x versions.
	4.x is expected to be obsoleted soon. Check for updates regulary,
	as new versions provide current security and bug fixes.
 
 
Additional reading and references:

        RFC1034
	( Domain Names - Concepts and Facilities )

	RFC1035
	( Domain Names - Implementation and Specification )
 
        RFC1537 ( RFC1912 )
        ( Common DNS Operational and Configuration Errors )
 
        "DNS & BIND 2nd Edition" by Paul Albitz & Cricket Liu 
        from O´Reilly & Associates Inc.
        
        ftp://ftp.ripe.net/internet-drafts/draft-ietf-dnsind-classless-
        inaddr-04.txt
        ( For reverse delegation methods for blocks smaller than /24,
        256 addresses )
 
        http://www.dns.net/dnsrd/
        ( DNS Resources Directory )



=== fin ===

Regards,
	Elmi.

-- 
  | \  / |\/|  Gesellschaft fuer Internet, Vernetzung und Mehrwertdienste mbH
  |  \/  |  |  Zissener Str. 8 - D-53498 Waldorf - +49 2636 9769-0 - Fax -999

 The Net People.       Elmar K. Bins (ekb at ivm.net)        http://www.ivm.net/