RFC 1912

Common DNS Operational and Configuration Errors

📅 published February 1996, from ietf

Common DNS Operational and Configuration Errors 💅

Okay bestie, this is RFC 1912 and it is a whole mood 🎀

This one came out of the Network Working Group, written by D. Barr at The Pennsylvania State University 🎓. It's dated February 1996 and it's marked Informational 📖. It also obsoletes RFC 1537, so think of it as the glow-up that replaces that one ✨ It's an RFC, so the number is 1912 💖

Status of this Memo 📜

Okay so this memo is here to give info to the Internet community 🌸 It does not specify an Internet standard of any kind, so it's not a rulebook, it's more of a friendly heads-up 🫶 Distribution of this memo is unlimited, so you can share it with literally everyone 🦋

Abstract 🔮

This memo describes errors that show up a lot in two places: how Domain Name System (DNS) servers get operated, and the data those DNS servers hold 👀 It tries to sum up current Internet requirements and the common practice for running and configuring DNS. It also tries to summarize or expand on issues raised in [RFC 1537] ✨

1. Introduction 🧚

Running a nameserver is not a trivial task 😭 There are so many things that can go wrong, and you have to make a bunch of decisions about what data goes into the DNS and how to set up your servers. This memo is trying to cover the common mistakes and pitfalls, both in the DNS data and in how nameservers get run 💅 It also talks about some other relevant stuff, like server or resolver bugs, and a few political issues around how DNS operates on the Internet 👑

2. DNS Data 💖

This section is all about the problems people usually run into with the DNS data in their nameserver. We're talking about the zone data files that the nameserver loads into memory 🧠

2.1 Inconsistent, Missing, or Bad Data 🙈

Every Internet-reachable host should have a name!! The consequences are getting more and more obvious. Lots of services on the Internet won't talk to you if you aren't correctly registered in the DNS 💀

Make sure your PTR and A records match, bestie 🫶 For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed (more than one IP address), make sure that every single IP address has a corresponding PTR record, not just the first one. Failing to have matching PTR and A records can cause loss of Internet services, kind of like not being registered in the DNS at all 😱 Also, PTR records must point back to a valid A record, not an alias defined by a CNAME. It is highly recommended that you use software that automates this checking, or generate your DNS data from a database that automatically creates consistent data ✨

DNS domain names are made of "labels" separated by single dots 🍓 The DNS is super liberal about which characters are allowed in a domain name. But if a domain name is used to name a host, it should follow the rules that restrict host names. And if a name is used for mail, it must follow the naming rules for names in mail addresses 📬

For a host name, the allowable characters in a label are only ASCII letters, digits, and the `-' character. Labels may not be all numbers, but they may have a leading digit (e.g., 3com.com) 🔢 Labels must end and begin only with a letter or digit. See [RFC 1035] and [RFC 1123]. (Labels were initially restricted in [RFC 1035] to start with a letter, and some older hosts still reportedly have problems with the relaxation in [RFC 1123].) Note there are some Internet hostnames that violate this rule (411.org, 1776.com) 🙃 The presence of underscores in a label is allowed in [RFC 1033], except [RFC 1033] is informational only and was not defining a standard. There is at least one popular TCP/IP implementation that currently refuses to talk to hosts named with underscores in them 🙅‍♀️ It must be noted that the language in [1035] is such that these rules are voluntary -- they are there for those who wish to minimize problems. Note that the rules for Internet host names also apply to hosts and addresses used in SMTP (See RFC 821) 📨

If a domain name is to be used for mail (not involving SMTP), it must follow the rules for mail in [RFC 822], which is actually more liberal than the rules above 🥰 Labels for mail can be any ASCII character except "specials", control characters, and whitespace characters. "Specials" are specific symbols used in parsing addresses. They are the characters "()<>@,;:\".[]" (The "!" character wasn't in [RFC 822], however it also shouldn't be used due to the conflict with UUCP mail as defined in RFC 976.) Since today almost all names used for mail on the Internet are also names used for hostnames, you rarely see addresses using these relaxed standards. Still, mail software should be made liberal and robust enough to accept them 💌

You should also be careful not to have addresses that are valid alternate syntaxes for the inet_ntoa() library call 🫣 For example, 0xe is a valid name, but if you typed "telnet 0xe", it would try to connect to IP address 0.0.0.14. It's also rumored that some broken inet_ntoa() routines treat an address like x400 as an IP address 👻

Certain operating systems have limits on the length of their own hostname. This isn't strictly an issue for the DNS, but you should know your operating system's length limits before you choose the name of a host 📏

Remember that many resource records (abbreviated RR) take on more than one argument 🧩 HINFO requires two arguments, and so does RP. If you don't supply enough arguments, servers sometimes return garbage for the missing fields 🗑️ If you need to include whitespace within any data, you must put the string in quotes 🎀

2.2 SOA records 🍓

In the SOA record of every zone, remember to fill in the e-mail address that will reach the person who maintains the DNS at your site (commonly referred to as "hostmaster") 📧 The @' in the e-mail must be replaced by a .' first, and you should not try to put an @' sign in this address. If the local part of the address already contains a .' (e.g., John.Smith@widget.xx), then you need to quote the .' by preceding it with a ' character (e.g., to become John\.Smith.widget.xx). Alternately (and this is the preferred way!), you can just use the generic name `hostmaster' and use a mail alias to redirect it to the appropriate people 💖 There's software that uses this field to automatically generate the e-mail address for the zone contact, and that software will break if this field is improperly formatted 💥 It is imperative that this address get to one or more real persons, because it's often used for everything from reporting bad DNS data to reporting security incidents 🚨

Even though some BIND versions let you use a decimal in a serial number, don't!! A decimal serial number gets converted to an unsigned 32-bit integer internally anyway. The formula for an n.m serial number is:

n*10^(3+int(0.9+log10(m))) + m

which translates to something rather unexpected 🙀 For example, it's routinely possible with a decimal serial number (perhaps automatically generated by SCCS) to be incremented so that it's numerically larger, but after the above conversion it yields a serial number that is LOWER than before. Decimal serial numbers have been officially deprecated in recent BIND versions 🗿 The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, nn=revision number). This won't overflow until the year 4294 🔮

Choose logical values for the timer values in the SOA record (note that the values below must be expressed as seconds in the zone data) ⏰

Refresh: How often a secondary will poll the primary server to see if the serial number for the zone has increased (so it knows to request a new copy of the data for the zone). Set this to how long your secondaries can comfortably contain out-of-date data. You can keep it short (20 mins to 2 hours) if you aren't worried about a small increase in bandwidth used, or longer (2-12 hours) if your Internet connection is slow or is started on demand. Recent BIND versions (4.9.3) have optional code to automatically notify secondaries that data has changed, which lets you set this TTL to a long value (one day, or more) 🔔
Retry: If a secondary was unable to contact the primary at the last refresh, wait the retry value before trying again. This value isn't as important as the others, unless the secondary is on a distant network from the primary or the primary is more prone to outages. It's typically some fraction of the refresh interval 🔁
Expire: How long a secondary will still treat its copy of the zone data as valid if it can't contact the primary. This value should be greater than how long a major outage would typically last, and must be greater than the minimum and retry intervals, so a secondary doesn't expire the data before it gets a chance to get a new copy. After a zone is expired, a secondary will still keep trying to contact the primary, but it will no longer provide nameservice for the zone. 2-4 weeks are suggested values 🥀
Minimum: The default TTL (time-to-live) for resource records -- how long data will remain in other nameservers' cache. ([RFC 1035] defines this to be the minimum value, but servers seem to always implement this as the default value.) This is by far the most important timer 👑 Set this as large as is comfortable given how often you update your nameserver. If you plan to make major changes, it's a good idea to turn this value down temporarily beforehand. Then wait the previous minimum value, make your changes, verify their correctness, and turn this value back up. 1-5 days are typical values. Remember this value can be overridden on individual resource records 🧁

As you can see, the typical values above for the timers vary widely 🌈 Popular documentation like [RFC 1033] recommended a day for the minimum TTL, which is now considered too low except for zones with data that vary regularly. Once a DNS stabilizes, values on the order of 3 or more days are recommended. It is also recommended that you individually override the TTL on certain RRs that are often referenced and don't often change, giving them very large values (1-2 weeks) 🦋 Good examples of this are the MX, A, and PTR records of your mail host(s), the NS records of your zone, and the A records of your nameservers 🫶

2.3 Glue A Records ✨

okay so glue records are A records that hang out with NS records to give the nameserver some "bootstrapping" info 🥾 Here's the vibe:

podunk.xx.      in      ns      ns1.podunk.xx.
                in      ns      ns2.podunk.xx.
ns1.podunk.xx.  in      a       1.2.3.4
ns2.podunk.xx.  in      a       1.2.3.5

Those A records? They're the "Glue records" 🧚

Glue records are required only in forward zone files for nameservers that live in the subdomain of the zone being delegated. You shouldn't have any A records in an in-addr.arpa zone file (unless you're using RFC 1101-style encoding of subnet masks) 🙅‍♀️

If your nameserver is multi-homed (meaning it has more than one IP address), you must list all of its addresses in the glue 💅 Otherwise you get cache inconsistency because of differing TTL values, and some lookups won't find all the addresses for your nameserver. not it 💀

Some people get in the bad habit of adding a glue record whenever they add an NS record "just to make sure" 🙃 Please don't. Duplicate glue records in your zone files make life so much harder when a nameserver moves to a new IP address or gets removed. You'll spend hours wondering why random people still see the old IP address for some host, only to find out someone forgot to change or remove a glue record in some other file 😭 Newer BIND versions will ignore these extra glue records in local zone files, which is nice of them 🫶

Older BIND versions (4.8.3 and previous) have a real problem. They insert these extra glue records into the zone transfer data sent to secondaries. If one of those glues is wrong, the error can spread to other nameservers. If two nameservers are secondaries for each other's zones, one can keep passing old glue records back to the other forever 🌀 The only way to get rid of the old data is to kill both of them, remove the saved backup files, and restart them. And those same versions also tend to get infected more easily by bogus data from other non-secondary nameservers (like the root zone data). Chaos, honestly 🔥

2.4 CNAME records 🦋

A CNAME record is not allowed to coexist with any other data. Like, at all. If suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record 🙅‍♀️ Especially do not try to combine CNAMEs and NS records like this!:

podunk.xx.      IN      NS      ns1
                IN      NS      ns2
                IN      CNAME   mary
mary            IN      A       1.2.3.4

Inexperienced admins try this all the time because it seems like an obvious way to let your domain name also be a host 🤦‍♀️ But DNS servers like BIND will see the CNAME and refuse to add any other resources for that name. Since no other records are allowed alongside a CNAME, the NS entries get ignored. And that means all the hosts in the podunk.xx domain get ignored too!! 😱

If you want your domain to also be a host, do this instead:

podunk.xx.      IN      NS      ns1
                IN      NS      ns2
                IN      A       1.2.3.4
mary            IN      A       1.2.3.4

Don't go overboard with CNAMEs ✋ Use them when renaming hosts, but plan to get rid of them (and tell your users). HOWEVER, CNAMEs are super useful and encouraged for generalized server names: ftp for your ftp server, www for your Web server, gopher for your Gopher server, news for your Usenet news server, etc. ✨

Don't forget to delete the CNAMEs tied to a host when you delete the host they point at 🧹 Those "stale CNAMEs" are just a waste of resources, bestie.

Also, don't use CNAMEs together with RRs that point to other names, like MX, CNAME, PTR and NS. (PTR is the exception if you want to implement classless in-addr delegation.) For example, this is strongly discouraged 🚫

podunk.xx.      IN      MX      mailhost
mailhost        IN      CNAME   mary
mary            IN      A       1.2.3.4

[RFC 1034] in section 3.6.2 says this shouldn't be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME 🙅‍♀️ It creates unnecessary indirection when accessing the data, so DNS resolvers and servers have to work harder to get the answer. If you really, really want to do it anyway, you can get the same result by using a preprocessor such as m4 on your host files 🧚

Chained records (like CNAMEs pointing to CNAMEs) might make administration easier, but they're known to tickle bugs in some resolvers that don't check loops correctly 🐛 As a result, some hosts may not be able to resolve those names.

Having NS records that point to a CNAME is bad and may conflict badly with current BIND servers. Current BIND implementations will actually ignore those records, which can lead to a lame delegation 💀 BIND also does a certain amount of security checking to prevent spoofing of DNS NS records. Plus, older BIND servers reportedly get caught in an infinite query loop trying to figure out the address for the aliased nameserver, sending a continuous stream of DNS requests. Nightmare behavior 😭

2.5 MX records 💌

It is a good idea to give every host an MX record, even if it points to itself! 💖 Some mailers cache MX records, but they'll always need to check for an MX before sending mail. If a site doesn't have an MX, then every piece of mail may cost one more resolver query, since the answer to the MX query often also contains the IP addresses of the MX hosts. Internet SMTP mailers are required by [RFC 1123] to support the MX mechanism ✅

Put MX records even on hosts that aren't meant to send or receive e-mail 📬 If there's a security problem involving one of these hosts, some people will mistakenly send mail to postmaster or root at the site without checking first whether it's a "real" host or just a terminal or personal computer that isn't set up to accept e-mail. If you give it an MX record, the e-mail can be redirected to a real person 🫶 Otherwise the mail just sits in a queue for hours or days until the mailer gives up.

Don't forget that whenever you add an MX record, you need to tell the target mailer if it should treat the first host as "local". (The "Cw" flag in sendmail, for example) 🎀

If you add an MX record that points to an external host (for example, for backup mail routing), be sure to ask that site's permission first 🙏 Otherwise they could get pretty upset and take action, like throwing your mail away, or appealing to higher authorities like your parent DNS administrator or network provider. Drama you do not want 💀

2.6 Other Resource Records 🌈

2.6.1 WKS

WKS records are deprecated in [RFC 1123] 🥀 They serve no known useful function, except internally among LISP machines. Don't use them 🙅‍♀️

2.6.2 HINFO

Okay, the HINFO debate. Some people will argue these are a security problem, because they broadcast what vendor hardware and operating system you have, so people can run systematic attacks on known vendor security holes 😬 If you do use them, you should keep up to date with known vendor security problems. That said, they do serve a useful purpose ✨ Don't forget that HINFO requires two arguments: the hardware type and the operating system.

HINFO is sometimes abused to carry other information. The record is meant to provide specific information about the machine itself. If you need to express other information about the host in the DNS, use TXT 📝

2.6.3 TXT

TXT records have no specific definition, so you can put most anything in them 🌸 Some people use it for a generic description of the host. Others put in specific info like its location, primary user, or even a phone number 📞

2.6.4 RP

RP records are relatively new 🐣 They're used to specify the e-mail address (see first paragraph of section 2.2) of the "Responsible Person" for the host, plus the name of a TXT record where you can get more information. See [RFC 1183] 🧾

2.7 Wildcard records 🃏

Wildcard MXs are mostly useful for non IP-connected sites. A super common mistake is thinking a wildcard MX for a zone will apply to all hosts in the zone 🙈 It won't. A wildcard MX only applies to names in the zone that aren't listed in the DNS at all. e.g.,

podunk.xx.      IN      NS      ns1
                IN      NS      ns2
mary            IN      A       1.2.3.4
*.podunk.xx.    IN      MX      5 sue

Mail for mary.podunk.xx will be sent to itself for delivery 📮 Only mail for jane.podunk.xx or any hosts you don't see above will be sent to the MX. For most Internet sites, wildcard MX records aren't useful. You need explicit MX records on every host 💅

Wildcard MXs can be bad, because they make some operations succeed when they should fail 😩 Picture this: someone in the domain "widget.com" tries to send mail to "joe@larry". If the host "larry" doesn't actually exist, the mail should bounce immediately. But because of domain searching, the address gets resolved to "larry.widget.com", and because of the wildcard MX, that's a valid address according to DNS. Or maybe someone just made a typo in the hostname part of the address. The message then gets routed to the mail host, which rejects it with strange error messages like "I refuse to talk to myself" or "Local configuration error" 🤡

Wildcard MX records are good when you have a large number of hosts that aren't directly Internet-connected (for example, behind a firewall), and for administrative or political reasons it's too difficult to have individual MX records for every host, or to force all e-mail addresses to be "hidden" behind one or more domain names 🏰 In that case, you must divide your DNS into two parts: an internal DNS and an external DNS. The external DNS will have only a few hosts and explicit MX records, plus one or more wildcard MXs for each internal domain. Internally, the DNS will be complete, with all explicit MX records and no wildcards 🧠

Wildcard As and CNAMEs are possible too, but they're really confusing to users and a potential nightmare if you use them without thinking first 💀 Because of domain searching again, any telnet/ftp attempts from within the domain to unknown hosts could get directed to one address. One such wildcard CNAME (in *.edu.com) caused Internet-wide loss of services and potential security nightmares due to unexpected interactions with domain searching. It resulted in swift fixes, and even an RFC ([RFC 1535]) documenting the problem 📜👑

2.8 Authority and Delegation Errors (NS records) 🫶

Okay bestie, every domain is required to have at least two nameservers 💅, and more is preferred. Make sure you have secondaries outside your own network 🌸. If the secondary isn't under your control, periodically check up on them and make sure they're getting current zone data from you 🔍. Asking their nameserver about your hosts should always get an "authoritative" answer. If it doesn't, that's called a "lame delegation" 🙈. A lame delegation happens when a nameserver has been given responsibility for a zone (through NS records) but isn't actually doing nameservice for that zone, usually because it isn't set up as a primary or secondary for it 💀.

The "classic" lame delegation looks like this:

           podunk.xx.      IN      NS      ns1.podunk.xx.
                           IN      NS      ns0.widget.com.

So "podunk.xx" is a brand new domain 🧚, and "ns1.podunk.xx" has been set up to do nameservice for the zone. They haven't finished everything yet, though. The hostmaster at "ns0.widget.com" never got around to setting up as a proper secondary, so that server has no information about podunk.xx, even though the DNS says it's supposed to. Things can go different ways depending on which nameserver gets asked. At best, you get some extra DNS traffic from the lame delegation. At worst, hosts don't resolve and your email bounces 😭.

Also, sometimes a nameserver gets moved to another host or dropped from the list of secondaries. Because NS records get cached, lots of sites will still think that host is a secondary long after it stopped providing nameservice 👀. To avoid lame delegations while those caches age out, keep providing nameservice on the old nameserver for the maximum of the minimum plus refresh times for the zone and the parent zone (see section 2.2). Iconic patience behavior, honestly 🦋.

Whenever a primary or secondary is removed or changed, it takes a fair amount of human coordination between everyone involved (the site itself, its parent, and the site hosting the secondary) 🤝. When a primary moves, make sure all secondaries have their named.boot files updated and their servers reloaded. When a secondary moves, make sure the address records at both the primary and parent level get changed.

It's also been reported that some distant sites like to grab popular nameservers like "ns.uu.net" and just add them to their NS records, hoping they'll magically do extra nameservice for them 🙃. That's an even worse form of lame delegation, since it piles more traffic onto an already busy nameserver. Please contact the hostmasters of sites that have lame delegations 📞. Various tools can detect or actively find lame delegations, and there's a list of contributed software in the BIND distribution you can check out.

Make sure your parent domain has the same NS records for your zone that you do. (Don't forget your in-addr.arpa zones too!) 🫠 Do not list too many (7 is the recommended maximum). That just makes things harder to manage, and a long list is only really needed for very popular top-level or root zones. You also risk overflowing the 512-byte limit of a UDP packet in the response to an NS query. If that happens, resolvers will "fall back" to TCP requests, and that means more load on your nameserver 📈.

When you pick geographic locations for secondary nameservers, it's important to minimize latency and increase reliability, and network topologies matter here 🗺️. For example, if your site sits on the far end of a slow local or international link, consider a secondary on the other side of that link to cut down average latency. Ask your Internet service provider or parent domain contact about any secondaries that might be available to you ✨.

3. BIND operation 🎀

This section covers common problems people run into while actually operating the nameserver (specifically BIND) 🧚. The data has to be correct, as explained above, but the nameserver also has to be operated correctly, or that data never gets made available. Main character energy requires both 👑.

3.1 Serial numbers 🔢

Each zone has a serial number. Its job is keeping track of who has the most current data. If and only if the primary's serial number for the zone is greater will the secondary ask the primary for a copy of the new zone data (see special case below) 💖.

Don't forget to change the serial number when you change data! 😤 If you don't, your secondaries won't transfer the new zone information, and you'll be confused for hours. Automating the incrementing of the serial number with software is also a good idea 🤖.

If you make a mistake and bump the serial number too high, and you want to reset it to a lower value, use this procedure:

Take the "incorrect" serial number and add 2147483647 to it. If the number exceeds 4294967296, subtract 4294967296. Load the resulting number. Then wait 2 refresh periods to let the zone propagate to all servers ⏳.
Repeat the above until the resulting serial number is less than the target serial number.
Up the serial number to the target serial number.

This procedure won't work if one of your secondaries is running an old version of BIND (4.8.3 or earlier) 💀. In that case, you'll have to contact the hostmaster for that secondary and have them kill the secondary servers, remove the saved backup file, and restart the server. Be careful when editing the serial number. DNS admins really don't like killing and restarting nameservers, because you lose all that cached data 😭.

3.2 Zone file style guide 📝

Here are some useful tips for structuring your zone files. Following them will help you spot mistakes, and help you avoid making more 🦋.

Be consistent with the style of entries in your DNS files. If your $ORIGIN is podunk.xx., try not to write entries like:

           mary            IN      A       1.2.3.1
           sue.podunk.xx.  IN      A       1.2.3.2

or:

           bobbi           IN      A       1.2.3.2
                           IN      MX      mary.podunk.xx.

Either use all FQDNs (Fully Qualified Domain Names) everywhere, or use unqualified names everywhere. Or have FQDNs all on the right-hand side but unqualified names on the left. Above all, be consistent 🫶.

Use tabs between fields, and try to keep columns lined up. It makes missing fields way easier to spot 👀 (note that some fields, such as "IN", are inherited from the previous record and may be left out in certain circumstances). You don't need to repeat the name of the host when you're defining multiple records for one host. Keep all the records for a host together in the file too. It'll make things way more straightforward when it's time to remove or rename a host 🧹.

Always remember your $ORIGIN! If you don't put a . at the end of an FQDN, it isn't recognized as an FQDN. If it isn't an FQDN, the nameserver will append $ORIGIN to the name. Double check, triple check those trailing dots 🌟, especially in in-addr.arpa zone files, where they matter the most.

Be careful with the syntax of the SOA and WKS records (the records that use parentheses). BIND is not very flexible about how it parses these records. Check the BIND documentation before you go wild 🙈.

3.3 Verifying data ✅

Verify the data you just entered or changed by querying the resolver with dig (or your favorite DNS tool; many are included in the BIND distribution) after every change. A few seconds of double checking can save hours of trouble, lost mail, and general headaches 💅. Also be sure to check syslog output when you reload the nameserver. If you have grievous errors in your DNS data or boot file, named will report them via syslog 🚨.

It is also highly recommended that you automate this checking, either with software that runs sanity checks on the data files before they're loaded into the nameserver, or with software that checks the data already loaded in the nameserver. Some contributed software that does this is included in the BIND distribution 🫶.

4. Miscellaneous Topics 🌈

4.1 Boot file setup 🥾

Certain zones should always be present in nameserver configurations:

           primary         localhost               localhost
           primary         0.0.127.in-addr.arpa    127.0
           primary         255.in-addr.arpa        255
           primary         0.in-addr.arpa          0

These zones are set up either to provide nameservice for "special" addresses, or to help stop accidental queries for broadcast or local addresses from being sent off to the root nameservers 🛑. All of these files contain NS and SOA records, just like the other zone files you maintain. The exception is that you can probably make the SOA timers very long, since this data will never change 💜.

The "localhost" address is a "special" address that always refers to the local host. It should contain the following line:

           localhost.      IN      A       127.0.0.1

The "127.0" file should contain the line:

           1    PTR     localhost.

There's been some extensive discussion about whether or not to append the local domain to it. The conclusion was that "localhost." is the best solution 🏆. The reasons given include:

"localhost" by itself is used and expected to work in some systems.
Translating 127.0.0.1 into "localhost.dom.ain" can cause some software to connect back to the loopback interface when it didn't want to, because "localhost" is not equal to "localhost.dom.ain".

The "255" and "0" files should not contain any additional data beyond the NS and SOA records 🙅.

Note that future BIND versions may include all or some of this data automatically, without any additional configuration ✨.

4.2 Other Resolver and Server bugs 🐛

Very old versions of the DNS resolver have a bug that causes queries for names that look like IP addresses to go out. The user supplied an IP address, and the software didn't realize it didn't need to be resolved 🤦. This has been fixed, but it still pops up now and then. It matters because this bug means those queries get sent directly to the root nameservers, piling onto an already heavy DNS load 😩.

Running a secondary nameserver off another secondary nameserver is possible, but it is not recommended unless your network topology makes it necessary. There are known cases where it has led to problems like bogus TTL values 🫠. While older or flawed DNS implementations may cause this, you should not chain secondaries off of one another. It builds up extra reliability dependencies and adds delays to updates of new zone data 🔗.

4.3 Server issues 💻

DNS operates primarily via UDP (User Datagram Protocol) messages. Some UNIX operating systems, trying to save CPU cycles, run with UDP checksums turned off. People have debated the merits of this for ages 🗣️. However, as CPU speeds have increased, performance considerations matter less and less. It is strongly encouraged that you turn on UDP checksumming, to avoid corrupted data not only with DNS but also with other services that use UDP (like NFS) 🛡️. Check your operating system documentation to verify that UDP checksumming is enabled 🫶.

References 📚

okay bestie, here's the full reading list this doc leaned on, all the receipts 🧾✨

[RFC 974] Partridge, C., "Mail routing and the domain system", STD 14, RFC 974, CSNET CIC BBN Laboratories Inc, January 1986.
[RFC 1033] Lottor, M, "Domain Administrators Operations Guide", RFC 1033, USC/Information Sciences Institute, November 1987.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, IETF, October 1989.
[RFC 1178] Libes, D., "Choosing a Name for Your Computer", FYI 5, RFC 1178, Integrated Systems Group/NIST, August 1990.
[RFC 1183] Ullman, R., Mockapetris, P., Mamakos, L, and C. Everhart, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC 1535] Gavron, E., "A Security Problem and Proposed Correction With Widely Deployed DNS Software", RFC 1535, ACES Research Inc., October 1993.
[RFC 1536] 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.
[RFC 1537] Beertema, P., "Common DNS Data File Configuration Errors", RFC 1537, CWI, October 1993.
[RFC 1713] A. Romao, "Tools for DNS debugging", RFC 1713, FCCN, November 1994.
[BOG] Vixie, P, et. al., "Name Server Operations Guide for BIND", Vixie Enterprises, July 1994.

5. Security Considerations 🔐

okay so this one is quick and kinda honest: security issues are not discussed in this memo 💀

heads up, bestie: if you came here looking for security tea, this doc doesn't spill any 🙈

6. Author's Address 🖋️

here's who wrote it, the lovely David Barr at Penn State 🦋

David Barr
The Pennsylvania State University
Department of Mathematics
334 Whitmore Building
University Park, PA 16802

Voice: +1 814 863 7374
Fax: +1 814 863-8311
EMail: barr@math.psu.edu

that's the whole doc, period 🌈💅

📦 where this page comes from

ietf: rfc1912 1996-02
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms