Troubleshooting Common DNS Misconfiguration Errors
Troubleshooting Common DNS Misconfiguration ErrorsDNS (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.
IntroductionThe 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 Remember1. 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 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 RecordsGlue 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. 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 DelegationA 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 domain.com IN NS ns1.domain.com 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 won't which will be 'lame' until it is set up properly. To get more in depth understanding, let's use dig tool for example.com. 1. First we find the nameservers of example.com: dig example.com NS ;; ANSWER SECTION: 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 @b.iana-servers.net example.com NS 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 won't 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. So never use CNAME along with NS records.
(iii) Stealth NameserversStealth 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 but when I query nameservers of your domain for the NS records are not the same and comes like ns0.domain.com 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 ServerRunning 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 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 ;; global options: printcmd 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 {
(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 Writing1. No CNAME pointing to NS records domain.com. IN NS ns1.domain.com. 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
3. Proper GLUEAlways 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. Refer to RFC1912.
4. No duplicate MX records domain.com. IN MX mail.domain.com.
5. Allow Port 53 for both UDP and TCP connectionsIf 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
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. Instead use A record to map directly to IP address. mail IN A 11.33.55.77 ---> CORRECT Refer to RFC1912.
7. MX Records should not contain IP addresses domain.com. IN 10 MX mail.domain.com. ----> CORRECT The correct way of doing this is glue the mx host to A record. domain.com. IN MX 10 mail.domain.com. -----> CORRECT
8. NS records should NOT contain IP addressAlways specify nameservers for your domain with NS records. It should be a name and not ip address. domain.com. IN NS dns0.domain.com. -----> CORRECT
REVERSE DNS FOR MAIL DELIVERYFor 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) 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 IPsIn 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 recordSPF 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
Domain KeysIt 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 BIND9Just 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 domain.com, serial and email parameters. nano /var/named/domain.com.db Open /etc/named.conf and place the following lines: zone "domain.com" { Save changes to the file and restart bind. service named restart
Sample DNS Zone File for BINDUse this file to set up your domains and nameservers in BIND9: ;=================================================================
About The AuthorMr.Balakrishnan is an Internet entrepreneur and Linux administrator with interests in PHP programming and Linux applications. He can be reached at his blog site corpocrat.com or in his twitter page.
|



Recent comments
12 hours 37 min ago
12 hours 42 min ago
17 hours 41 min ago
1 day 22 min ago
1 day 1 hour ago
1 day 2 hours ago
1 day 6 hours ago
1 day 13 hours ago
1 day 17 hours ago
1 day 18 hours ago