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.
INTRODUCTION
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. 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
example.com. IN NS ns1.example.com.
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)
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.ns1 IN A 11.33.55.77
ns2 IN A 22.44.66.88
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
domain.com IN NS ns1.domain.com
domain.com IN NS ns2.example-server.net
ns1.domain.com is configured to have zone information about domain but ns2.exserver.net 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 example.com
1. First we find the nameservers of example.com
dig example.com NS
;; ANSWER SECTION:
example.com. 158240 IN NS a.iana-servers.net.
example.com. 158240 IN NS b.iana-servers.net.
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 @b.iana-servers.net example.com NS
> dig @a.iana-servers.net example.com NS;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60896
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:
;example.com. IN NS;; ANSWER SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
Look in the flags
flags: qr aa rd
Since ‘aa’ is set in the answer, then both the nameservers of example.com provide authoritative answer. If it is lame delegation you wont get the authoritative answer.
CAUTION:
You should not use CNAME (alias) along with NS records and it often confuses most resolvers causing loops and often leads to ‘lame’ delegation.
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net
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
ns0.domain.com
ns2.domain.com
ns3.domain.com
but when i query nameservers of your domain for the NS records are not the same and comes like
ns0.domain.com
ns2.domain.com
ns.example-dns.net
Since ns.example-dns.net and ns3.domain.com 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 @K.root-servers.net example.com NS
and to ask one of the nameservers of the domain
dig @ns0.domain.com example.com 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 example.com
ns1.example.com
ns2.example.com
We ask ns1.example to resolve outside domain google.com and if we get IP address (A record) in the answer section, then it means it is an ‘open dns server’
dig @ns1.example.com google.com
dig @ns2.example.com google.com;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12107
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:
;google.com. 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 example.com we need to ask the master nameserver first. See the below example with dig.
dig @ns1.example.com example.com
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
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.
domain.com. In CNAME ns9.example-server.net -----> 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
http://tools.ietf.org/html/rfc2181
http://tools.ietf.org/html/rfc1912
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.
domain.com. IN NS ns1.domain.com.
domain.com. IN NS ns2.domain.com.ns1 IN A 1.2.3.4 —–> GLUE
ns2 IN A 2.4.6.9 —–> GLUE
Refer to RFC1912: http://tools.ietf.org/html/rfc1912
4. No duplicate MX records
domain.com. IN MX mail.domain.com.
domain.com. IN MX mail.domain.com —-> 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.
domain.com. IN MX 10 mail.domain.com.
mail IN CNAME domain.com. ----------> WRONG
Instead use A record to map directly to IP address
mail IN A 11.33.55.77 ---> CORRECT
Refer to RFC1912 http://tools.ietf.org/html/rfc1912
7. MX Records should not contain IP addresses.
domain.com. IN 10 MX mail.domain.com. ----> CORRECT
domain.com. IN 20 MX 11.22.33.44 -----> WRONG
The correct way of doing this is glue the mx host to A record.
domain.com. IN MX 10 mail.domain.com. -----> CORRECT
mail IN A 11.33.55.77 ----------> 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
domain.com. IN NS dns0.domain.com. —–> CORRECT
domain.com. IN NS 75.xx.xx.xx ———–> WRONG
REVERSE DNS FOR MAIL DELIVERY
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
host
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 http://openspf.org for more information about setup and configuration.
domain.com. IN TXT “v=spf1 a mx ip4:11.33.55.77 -all”
To query SPF record using dig
dig domain.com 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 http://domainkeys.sourceforge.net/
It basically contains 2 records (with and without selector) placed under TXT using underscore along with generated public key.
sel_domainkey.example.com IN TXT (with selector)
_domainkey.example.com 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
(1)
open /etc/named.conf, add the following lines…
zone “domain.com” {
type master;
file “/var/named/domain.com.com.db”;
};
(2)
create a file under /var/named/domain.com.db (replace example.com to your domain)
nano /var/named/domain.com.db
and paste the full sample bind zone (see below replacing domain.com to your domain)
Make sure you…
(a) have 2 ip addresses
(b) replace domain.com 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 http://intodns.com to check for any dns errors or you may use DIG tool to fix dns problems.
;=================================================================
;SAMPLE BIND DNS Zone FILE
;for ANY Domain (Just change domain.com to your site)
;================================================================; Before you start DONT FORGET THE DOT AND SERIAL INCREMENT
$TTL 14400
$ORIGIN domain.com.; SOA Record
; Specify Primary nameserver ns1.domain.com
; Serial should increment every update
@ 14400 IN SOA ns1.domain.com. webmaster.domain.com. (
2009092902 ; Serial in YYYYMMDDXX (XX is increment)
10800; refresh seconds
3600; retry
604800; expire
38400; minimum
);
; Website IP Address specified in A recordIN A xx.xx.xx.xx
; Minimum 2 DNS nameserver names
IN NS ns1.domain.com.
IN NS ns2.domain.com.; 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 domain.com.
ftp IN CNAME domain.com.
server IN CNAME domain.com.
webmail IN CNAME domain.com.; Setup MX record (mail exchanger with priority)
domain.com. IN MX 10 mail.domain.com.; set A record for mail
mail IN A xx.xx.xx.xx
Enjoy DNS!
