Troubleshooting Common DNS Misconfiguration Errors

Want to support HowtoForge? Become a subscriber!
Submitted by olddocks (Contact Author) (Forums) on Mon, 2009-10-26 18:10. :: DNS

Troubleshooting Common DNS Misconfiguration Errors

DNS (Domain name system) may not be known to most people who use the Internet but it is the real invisible force driving the Internet without which everyone would be seeing numbers and IPs. The whole meaning of domain names exists today just because of DNS.



The simplest way of explaining DNS in one line is to map domain name to IP address. I am not sure how many would know that when somebody types a domain name in IE/firefox, the browser forwards the DNS request asking for ip address from the resolver of ISP (ISP Provider) and the resolver contacts the root servers and then systematically retrieves the IP address within a matter of few milliseconds.

Understanding DNS and its working is one of the most difficult computer engineering subject and yet most experienced network administrators struggle in this topic when it comes to DNS zone file writing.

Before I proceed with this article, the following are the MOST IMPORTANT points you should remember as otherwise you wouldnt understand bit.


Points To Remember

1. An A Record must ALWAYS contain IP address (map host to IP)

Whenever you specify A record it must contain IP address on the Right side. The A record is so important in DNS without which the meaning of mapping hostnames to IP would be absurd. So remember this!

2. CNAME (Alias) must contain hostnames. No IPs here

3. NS an MX records must contain host names. No IPs allowed.

4. Use the DOT in the end, whenever you specify a domain name in the DNS zone file. This DOT is so important and if you forget this you will have nightmares with your dns configuration.

For example IN    NS

Why DOT? simply because it tells to start query from root servers (denoted by dot)

5. MX records (for mail servers)  should contain hostnames NOT IPs.


Common DNS Terms and their Meanings

(i) Glue Records

Glue records are A records that are associated with NS records to provide "bootstrapping" information to the NS records nameserver. (see RFC 1912 section 2.3)     IN     NS     IN    NS

ns1     IN     A
ns2    IN    A

In the above example we are mapping each NS records to IP address (A record) thus binding nameservers to IP (that is glue them).


(ii) LAME Nameserver Delegation

A nameserver which gives non-authoritative answer is usually called 'LAME'. Every domain must have atleast 2 nameservers and if i ask each of them, and if they have domain zone information, I will get authoritative answer. If not it's a 'lame delegation'. Refer to RFC 1912 section 2.8.

An example of lame delegation is     IN      NS     IN    NS is configured to have zone information about domain but was not configured properly and does not have any information about the domain. So ns1 will answer authoritatively wheras ns2 won't which will be 'lame' until it is set up properly.

To get more in depth understanding, let's use dig tool for

1. First we find the nameservers of

 dig NS

;; ANSWER SECTION:            158240  IN      NS            158240  IN      NS

2. Since we have received 2 nameservers, we ask each of them whether they give authoritative answer. If it's authoritative 'aa'  flag in the header  will be set in the answer received ('aa' is authoritative answer).

> dig NS
> dig NS

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;                   IN      NS

;; ANSWER SECTION:            172800  IN      NS            172800  IN      NS

Look in the flags.

flags: qr aa rd

Since 'aa' is set in the answer, then both the nameservers of provide authoritative answer. If it is lame delegation you won't get the authoritative answer.


You should not use CNAME (alias) along with NS records and it often confuses most resolvers causing loops and often leads to 'lame' delegation.     IN     NS     IN    NS    In    CNAME

So never use CNAME along with NS records.


(iii) Stealth Nameservers

Stealth Nameservers (or hidden nameservers) are mismatched/conflicting nameservers which exist at root level against of nameservers in the domain.

To illustrate this, when I ask parent servers about your domain for NS records at root level I get

but when I query nameservers of your domain for the NS records are not the same and comes like

Since and is hidden both are a 'stealth nameservers'. Although there is nothing wrong in it, it is advisable not to have any stealth nameservers both at root level and in your dns server.

You can use dig command to lookup NS records at root server level.

dig +trace NS

and to ask one of the nameservers of the domain.

dig NS

Look for any NS mismatch between the two queries. If there is a nameserver missing at root level, add the missing nameserver to your domain registrar. If the nameserver missing at domain level, add the nameserver to the  zone file of the domain and update all your secondary nameservers.


(iv) Open DNS Server

Running the dns server 'open' is a big security risk since it answers recursive queries both from inside and outside your network. It means anyone can query your server for IP address and your dns server will answer them.

To illustrate this, we have two nameservers running bind for domain

We ask ns1.example to resolve outside domain and if we get IP address (A record) in the answer section, then it means it is an 'open dns server'.


;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12107
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;                    IN      A

;; Query time: 32 msec

Since there is no ANSWER section or IP address both the nameservers does not constitute open dns server.

If you happen to run bind8 or later, all you have to do is set 'recursion no' within options to disable dns server answering recursive queries.

options {
recursion no;


(v) Zone Transfers (AXFR request)

Zone transfers are done by secondary nameservers to retrieve latest and updated zone information for domain from master or primary nameserver. Zone transfers should only be made available to secondary nameservers and not to the open world as it is a big security risk and may expose the internals of your network to the attacker.

To request a zone transfer for we need to ask the master nameserver first. See the below example with dig.


If you see the output with full zone file, then you have to disable the zone transfer. In most cases you will see connection failed or REFUSED which means zone transfer is not allowed and its a good thing.


Common DNS Errors in Zone file Writing

1. No CNAME pointing to NS records     IN     NS     IN    NS    In    CNAME -----> WRONG

Placing CNAME along with NS the all of namservers will fail and will result in lame delegation. Don't do that!

Refer to RFC1912 2.4 and RFC2181 10.3.


2. Avoid running DNS servers on IPs on same subnet (/24) or on same server.

The whole purpose of DNS is for nameservers to be spread over different geographical locations so that if one dns fails the other would work. Although it is very common practice to run both nameservers on same server or subnet, it would not provide fault tolerance. If the server fails your nameservers will fail and your site wont load.

ns1 IN A 75.33.22.xx -----> same subnet /24
ns2 IN A 75.33.22.xx -----> same subnet /24


3. Proper GLUE

Always add glue to your NS records to the IP addresses using A record, failing which one of your nameservers will fail. IN NS IN NS

ns1 IN A -----> GLUE
ns2 IN A -----> GLUE

Refer to RFC1912.


4. No duplicate MX records IN MX IN MX  ----> DUPLICATE


5. Allow Port 53 for both UDP and TCP connections

If you use firewall make sure you do not block port 53 for DNS tcp and udp requests. By default dns lookups use UDP protocol while zone transfers and notifications use TCP protocol of port 53.

Port 53 UDP = Dns Requests
Port 53 TCP = Zone transfers


6. CNAMEs cannot co-xist with MX hosts.

Do not specify CNAME or aliases pointing to MX records. IN MX 10
mail IN CNAME  ----------> WRONG

Instead use A record to map directly to IP address.

mail IN A ---> CORRECT

Refer to RFC1912.


7. MX Records should not contain IP addresses IN 10 MX ----> CORRECT IN 20 MX  -----> WRONG

The correct way of doing this is glue the mx host to A record. IN MX 10 -----> CORRECT
mail IN A ----------> CORRECT


8. NS records should NOT contain IP address

Always specify nameservers for your domain with NS records. It should be a name and not ip address. IN NS -----> CORRECT IN NS  75.xx.xx.xx -----------> WRONG



For proper mail delivery, the following anti-spam methos are very important to make sure the email is delivered to users inbox. Most public email service providers yahoo, hotmail and gmail do use these parameters to flag email is spam or not.

(i) Setup Reverse IP for your mail server with PTR in DNS (needs Dedicated IP)
(ii) Setup SPF Record in your DNS
(iii) Setup Domain Keys

I have seen on many occasions if you use shared hosting plan, most emails do land up in spam/bulk folder in the users inbox. So use a dedicated server.


Set up reverse IPs for Mailserver IPs

In order to setup reverse IP, first you will need to place a request to your hosting provider (since they own Ip address) and ask them to setup a reverse IP to your mail server. Once that is done you have to place a line using PTR in your domain zone file.

To test reverse ip lookup:

host <ip-address>

will show the output of reverse dns.


Set up SPF record

SPF record is setup using TXT record in your dns zone file. It looks like what is shown below. Visit for more information about setup and configuration. IN TXT "v=spf1 a mx ip4: -all"

To query SPF record using dig:

dig TXT


Domain Keys

It basically contains 2 records (with and without selector) placed under TXT using underscore along with generated public key.

The ’sel’ is a selector and can be selector name.


How to set up DNS nameservers for your domain using BIND9

Just go to your linux console and type the following commands.

yum install bind

Create a new zone file for your domain and insert the sample zone file (see below). You have to change, serial and email parameters.

nano /var/named/

Open /etc/named.conf and place the following lines:

 zone "" {
type master;
file "/var/named/";

Save changes to the file and restart bind.

service named restart


Sample DNS Zone File for BIND

Use this file to set up your domains and nameservers in BIND9:

;for ANY Domain (Just change to your site)


$TTL 14400

; SOA Record
; Specify Primary nameserver
; Serial should increment every update
@ 14400 IN SOA (
                                2009092902 ; Serial in YYYYMMDDXX (XX is increment)
                                10800; refresh seconds
                                3600; retry
                                604800; expire
                                38400; minimum
; Website IP Address specified in A record

       IN A xx.xx.xx.xx

; Minimum 2 DNS nameserver names

       IN NS
       IN NS

; Mapping all Nameservers and their corresponding IPs (GLUE)

ns1  IN A xx.xx.xx.xx
ns2  IN A xx.xx.xx.xx

; Specify any subdomains and www entry here using CNAME record

www     IN CNAME
ftp     IN CNAME
server     IN CNAME
webmail IN CNAME

; Setup MX record (mail exchanger with priority) IN MX 10

; set A record for mail
mail IN A xx.xx.xx.xx


About The Author

Mr.Balakrishnan is an Internet entrepreneur and Linux administrator with interests in PHP programming and Linux applications. He can be reached at his blog site or in his twitter page.

Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Patrik Wallstrom (not registered) on Mon, 2009-10-26 18:55.

First, an open AXFR policy is not a security risk. Normally you don't put any confidential information in DNS, since all of the information in DNS is supposed to be public information...

If you want to check the quality of your delegation from the parent zone you can use the DNSCheck tool developed by .SE. It is also available as an open source tool, but for most people it is much easier to use the web interface:

Submitted by pbu (not registered) on Wed, 2009-10-28 20:28.
Allowing AXFR requests to public would expose internal structure of your network and this could lead to various network attacks and spoofing. I would be happy restricting zone transfers only to my slave server IPs.