Troubleshooting Common DNS Misconfiguration Errors

Understanding DNS & Troubleshooting Common DNS Errors

DNS (Domain name system) may not be known to most people who use internet but it is the real backbone and the invisible force driving the whole internet without which we would be seeing numbers and IPs. The whole meaning of domain names exist 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.


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

When ever 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.


(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 its a ‘lame delegation’. Refer to (see 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 wont which will be ‘lame’ until it is setup properly.

To get more in depth understanding, lets 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 its 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


;; 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 wont 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.


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. Dont 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 addresss 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

8. Setup 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


will show the output of reverse dns.

9. Setup 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

10. Domain Keys

Domain keys is an authentication framework to digitally sign the email using public keys to prove email originating from partiular domain and not from a phishing or spam site. More information can be found

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

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

Once you setup domain keys you will see signed by in the mail header on every smtp email you send.

How to setup nameservers for your domain using BIND9

You can setup dns nameservers for your domain if you have VPS or dedicated server just from command line. You dont need a control panel or webbased interface to do this.

yum install bind

open /etc/named.conf, add the following lines…

zone “” {
type master;
file “/var/named/”;

create a file under /var/named/ (replace to your domain)

nano /var/named/

and paste the full sample bind zone (see below replacing to your domain)

Make sure you…

(a) have 2 ip addresses
(b) replace to your domain.
(c) change the ip addresses whereever xx.xx.xx.xx is present
(d) increment the serial last 2 digits by one for every change to the file
(e) dont forget the DOT at the end of domain

(3) Save changes to the file and restart bind.

service named restart

(4) Go to your domain registrar, register the new nameservers with 2 ips, then update the nameservers for your domain.

Visit to check for any dns errors or you may use DIG tool to fix dns problems.

;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


; 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

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

Enjoy DNS!