RFC 1537

Common DNS Data File Configuration Errors 🎀

okay bestie, this is RFC 1537 from the Network Working Group 🌸 It's Request for Comments: 1537, and it's written by P. Beertema from CWI ✨ It's in the Informational category and dated October 1993. The header doesn't list anything it obsoletes or updates, so it's just vibing on its own 💅

---

Status of this Memo 📜

So the memo says it 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 🦋

Okay so because there isn't a ton of documentation or automated tools, DNS zone files have mostly been set up by system admins, by hand 💀 Some of the rules for writing the data files are rather subtle, and a few common mistakes show up in domains all over the world 🌍

This doc is an attempt to list the "surprises" admins might find hiding in their zone files 👀 It describes the symptoms of the malady and prescribes medicine to cure it 💊 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 🌈

This one is lowkey the big one 👑 I've found that quite a few nameservers have their various timers set (far) too low. Especially for top level domain nameservers, this causes unnecessary traffic over international and intercontinental links 😩

Unfortunately, the examples 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, a quick explainer on the timers in the SOA record 💅

• 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 can't reach the primary server, it tries again every "retry" time.
• Expire: If the primary server can't be reached for "expire" time, 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 its 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'd recommend these values 🇺🇳

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

For other servers, I'd suggest these 🍓

          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, people put unnecessary glue (A) records in their zone files 🙄 Even worse, I've seen wrong glue records for an external host in a primary zone file! 😱 Glue records need only be in a zone file if the server host is within the zone and there is no A record for that host elsewhere in the zone file.

Old BIND versions ("native" 4.8.3 and older versions) had the problem that wrong glue records could enter secondary servers in a zone transfer 💀

3. "Secondary server surprise" 🫣

I've seen it happen on various occasions where hosts got bombarded by nameserver requests and nobody knew why 😭 On investigating, it turned out that such a host was supposed to (i.e., the information was in the root servers) run secondary for some domain (or reverse (in-addr.arpa)) domain, without that host's nameserver manager having been asked or even told! 🙃

Newer BIND versions (4.9 and later) fixed this problem. At the same time though, the fix has the disadvantage that it's far less easy to spot this problem 🫠

Practice has shown that most domain registrars accept registrations of nameservers without checking if primary (!) and secondary servers have been set up, informed, or even asked. 😤 It should also be noted that a combination of long-lasting unreachability of primary nameservers, (therefore) expiration of zone information, plus static IP routing, can lead to massive network traffic that can fill up lines completely 🚨

4. "MX records surprise" 💌

Kinda similar to the last one, ngl 💅 Sometimes nameserver managers enter MX records in their zone files that point to external hosts, without first asking or even informing the systems managers of those external hosts 🙈 This has to be fought out between the nameserver manager and the systems managers involved. Only as a last resort, if really nothing helps to get the offending records removed, can the systems manager turn to the naming authority of the domain above the offending domain to get the problem sorted out 🧑‍⚖️

5. "Name extension surprise" 🪞

Sometimes you run into weird names that look like an external name with a local domain stuck on the end 🤨 This is caused by forgetting to end a name with a dot 💀 Names in zone files that don't end with a dot are always expanded with the name of the current zone (the domain the zone file stands for, or the last $ORIGIN) ✨

Bestie, the dot matters!! 🥹

Example, zone file for foo.xx:

   pqr          MX 100  relay.yy.
   xyz          MX 100  relay.yy           (no trailing dot!)

When fully written out, this stands for:

      pqr.foo.xx.  MX 100  relay.yy.
      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)

10. Safety measures and specialties 🛡️✨

Okay, bestie, nameservers and resolvers are NOT flawless 💀. Bogus queries should be kept from getting forwarded up to the root servers, because they just cause pointless intercontinental traffic 🌍✈️. The known bogus ones that you can easily handle locally are queries for 0 and broadcast addresses. To catch them, every nameserver should run primary for the 0.in-addr.arpa and 255.in-addr.arpa zones. The zone files only need a SOA and an NS record. Simple, iconic 💅.

Each nameserver should also run primary for 0.0.127.in-addr.arpa. That zone file should contain a SOA and NS record, plus this entry:

         1    PTR     localhost.

There was a LOT of discussion about whether to append the local domain to it 🙈. The verdict was that "localhost." was the best solution, and the reasons were:

• "localhost" itself is used and expected to work on some systems.
• Translating 127.0.0.1 into "localhost.my_domain" can make some software connect to itself over the loopback interface when it didn't want to 😭.

Also, all domains that contain hosts should have a "localhost" A record in them. Non-negotiable 🫶.

Now for the drama 🔥. If you maintain zone files with the Serial written in dotted decimal notation (like when people use SCCS to keep the files), beware of a bug in all BIND versions. If the serial number is in Release.Version (dotted decimal) notation, it becomes virtually impossible to move up to a higher release. The way that notation gets turned into an integer makes the serial LOWER than the one from the former release. Absolutely unhinged 💀.

Because of that, and because the Serial is an (unsigned) integer according to STD 13, RFC 1035, it is recommended not to use dotted decimal notation 🌸. The recommended approach is to use the date (yyyymmdd), with an extra digit (yyyymmddn) if there is or could be more than one change per day in a zone file 📅.

Very old versions of DNS resolver code had a bug that makes queries for A records with domain names like "192.16.184.3" go out. This happens when users type in IP addresses and the resolver doesn't catch it before sending a DNS query. The problem has been fixed in every resolver implementation we know of, but if it still pops up, it is VERY serious 😱. All those queries would go to the root servers looking for top level domains like "3" and so on. It is strongly recommended to install the latest publicly available BIND version, plus all available patches, to get rid of these and other problems 🧚.

Running a secondary nameserver off another secondary nameserver is possible, but not recommended unless it's really necessary 🙅‍♀️. There are known cases where it led to problems like bogus TTL values. This can be caused by older or flawed implementations, but secondary nameservers should, in principle, always transfer their zones from the official primary nameserver 🍓.

11. Some general points 🎀

The Domain Name System and nameservers are purely technical tools. They aren't meant to exert control or push politics on anyone 🕊️. The naming authority's job is that of a clearing house. Anyone who registers a subdomain under a particular (top level) domain becomes the naming authority for it and is therefore its sole responsible party 👑. So requests to enter MX or NS records for such a subdomain MUST be honored by the registrar of the next higher domain. No excuses, periodt 💅.

These practices are NOT allowed, sorry bestie 🙅‍♀️:

• Imposing specific mail routing (MX records) when registering a subdomain.
• Making registration of a subdomain depend on the use of certain networks or services.
• Using TXT records as a means of (free) commercial advertising.

In that last case, a network service provider could decide to cut off a particular site until the offending TXT records have been removed from the site's zone file 🚫.

Of course, there are obvious cases where a naming authority can refuse to register a subdomain, and can require a proposed name to be changed before it gets registered. Think of DEC trying to register a domain IBM.XX 😂💀.

There are also cases where you have to check the authority of the person applying. Not every systems manager should be able to register a domain name for a whole university 🎓. The naming authority can impose extra rules, as long as they don't violate or conflict with the rights and interests of the subdomain registrars. For example, a top level domain registrar may require that there be only primary subdomains "ac" and "co", and that subdomains get registered under those primary subdomains 🧠.

The naming authority can also step in during exceptional cases like the one in point 4, such as by temporarily removing a domain's entry from the nameserver zone files. This should be done only with extreme care, and only as a last resort 🫠.

When adding NS records for subdomains, top level nameserver managers should keep in mind that the people setting up nameservers for a subdomain are often rather inexperienced 🥺. They can make mistakes that easily make the subdomain completely unreachable, or cause unnecessary DNS traffic (see point 1). So it is highly recommended that, before entering such an NS record, the (top level) nameserver manager runs a couple of sanity checks on the new nameserver 🔍. Check things like: SOA record and timers OK? MX records present where needed? No obvious errors made? Listed secondary servers operational?

Some things can't be caught by those checks though 😬:

• Resolvers set up to use external hosts as nameservers.
• Nameservers set up to use external hosts as forwarders without permission from those hosts.

Be careful when registering 2-letter subdomains too 🌈. It's allowed, but it means abbreviated addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in and under that subdomain. When someone asks you to register one, always let them know this consequence. Take the name "cs", which is commonly used for Computer Science departments. It's also the top level domain for Czecho-Slovakia, so within the domain cs.foo.bar, user@host.cs is ambiguous. It could mean a user on the host host.cs.foo.bar, or a user on the host "host" in Czecho-Slovakia 🤯. (This example does not take into account the recent political changes in the mentioned country.)

References 📚

[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.

[2] Mockapetris, P., "Domain Names Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.

[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, CSNET CIC BBN, January 1986.

[4] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, ACES Research Inc., October 1993.

[5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, USC/Information Sciences Institute, USC, October 1993.

Security Considerations 😱🔐

Security issues are not discussed in this memo. 💀

Author's Address 💌

Piet Beertema
CWI
Kruislaan 413
NL-1098 SJ Amsterdam
The Netherlands

Phone: +31 20 592 4112
FAX:   +31 20 592 4199
EMail: Piet.Beertema@cwi.nl

Editor's Address 🦋

Anant Kumar
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695

Phone:(310) 822-1511
FAX:  (310) 823-6741
EMail: anant@isi.edu