Browse Prior Art Database

Common DNS Data File Configuration Errors (RFC1537)

IP.com Disclosure Number: IPCOM000002368D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 9 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Beertema: AUTHOR

Related Documents

10.17487/RFC1537: DOI

Abstract

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. This memo provides information for the Internet community. It does not specify an Internet standard.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Network Working Group P. Beertema Request for Comments: 1537 CWI Category: Informational October 1993

Common DNS Data File Configuration Errors

Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.

Abstract

This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time.

Introduction

Due to the lack of extensive documentation and automated tools, DNS zone files have mostly been configured by system administrators, by hand. Some of the rules for writing the data files are rather subtle and a few common mistakes are seen in domains worldwide.

This document is an attempt to list "surprises" that administrators might find hidden in their zone files. It describes the symptoms of the malady and prescribes medicine to cure that. It also gives some general recommendations and advice on specific nameserver and zone file issues and on the (proper) use of the Domain Name System.

1. SOA records

A problem I’ve found in quite some nameservers is that the various timers have been set (far) too low. Especially for top level domain nameservers this causes unnecessary traffic over international and intercontinental links.

Unfortunately the examples given in the BIND manual, in RFC’s and in some expert documents give those very short timer values, and that’s most likely what people have modeled their SOA records after.

First of all a short explanation of the timers used in the SOA record:

Beertema [Page 1]

RFC 1537 Common DNS Data File Configuration Errors October 1993

- Refresh: The SOA record of the primary server is checked every "refresh" time by the secondary servers; if it has changed, a zone transfer is done.

- Retry: If a secondary server cannot reach the primary server, it tries it again every "retry" time.

- Expire: If for "expire" time the primary server cannot be reached, all information about the zone is invalidated on the secondary servers (i.e., they are no longer authoritative for that zone).

- Minimum TTL: The default TTL value for all records in the zone file; a different TTL value may be given explicitly in a record when necessary. (This timer is named "Minimum", and that’s what it’s function should be according to STD 13, RFC 1035, but most (all?) implementations take it as the default value exported with records without an explicit TTL value).

For top level domain servers I would recommend the following values:

86400 ; Refresh 24 hours 7200 ; Retry 2 hours 2592000 ; Expire 30 days 345600 ; Minimum TTL 4 days

For other servers I would suggest:

28800 ; Refresh 8 hours 7200 ; Retry 2 hours 604800 ; Expire 7 days 86400 ; Minimum TTL 1 day

but here the frequency of changes, the required speed of propagation, the reachability of the primary server etc. play a role in optimizing the timer values.

2. Glue records

Quite often, peo...

Processing...
Loading...