I wrote this post ages ago, and therefore the information will sound a bit outdated, even if still accurate.
Prelude
DNS is the service on which Internet is based, however, quite strangely it is often overlooked.
In order to provide the best possible reliability, a lot of energy is placed on the hosting. All major e-commerce sites are load-balanced with redundant database back-ends, etc.
Without a resilient and reliable DNS server, no one can hope to smoothly run any Internet services. However, lots of highly redundant web servers are based on weak DNS foundations.
DNS is often misunderstood and it is assumed to be resistant to failure “by design”. Those who think like this will probably suffer a DNS outage sooner or later, however this could have easily been avoided by just taking a little care.
DNS resilience should be the second concern after routing resilience. According to experience (at least mine) lots of ISP and big accounts do not have reliable DNS Getting more Information
This document is not intended to explain DNS basics but to provide good practical advise. If you want to learn more about DNS and understand which DNS is good for you please consult the very good DJBDNS FAQ. located at http://cr.yp.to/djbdns/faq.html
You will probably find theses pages very interesting as well:
- http://www.djbdns.org/
- http://www.lifewithdjbdns.org/
- http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/
- http://www.fefe.de/djbdns
- http://www.bgpdns.org/
- http://www.ripe.net/ripencc/pub-services/db/whois/whois.html
- http://nms.lcs.mit.edu/projects/dns/
- http://www.cymru.com/Documents/secure-bind-template.html
Please, do not contact me to fix your DNS. Even so I am litterate with both DJBDNS and BIND, I do not wish to spend my time supporting it. Please refer to your ISP support department, read the FAQs, read newsgroups, Most BIND questions have already been answered numerous times.
However, please free to report any fault or inexactitude about this document
Good DNS record
Having a reliable and resilient DNS server is only the first step to secure DNS informtation. Hosting valid and well formed DNS information is crutial as well.
Lots of good books such as “DNS and BIND” will provide your with all the information you need to configure BIND. However, a well formed BIND file is only the start for good DNS management. Used DNS example
The following domains will be used as examples within this document: /var/named/domain.net on ns0.domain.net domain.net, the firm main domain name ie: bbc.co.uk, cnn.com, isp.net
$ORIGIN domain.net.
domain.net. 86400 IN SOA
ns0.domain.net. hostmaster.domain.net. (
2002020819 28800 7200 604800 86400 )
NS ns0.domain.net.
NS ns1.domain.net.
NS ns2.domain.net.
MX 10 mx
MX 20 secondary
mx A 10.0.0.25
A 10.0.0.26
A 10.0.0.27
A 10.0.0.27
secondary A 169.254.0.25
A 169.254.0.26
A 169.254.0.27
A 169.254.0.28
ns0 A 10.0.0.1
ns1 A 10.0.0.2
ns2 A 10.0.0.3
ns-secondary0 A 10.0.0.4
ns-cache0 A 10.0.0.5
ns-cache1 A 10.0.0.6
ns-staff0 A 192.168.0.254
smtp A 10.0.0.25
pop CNAME pop3
pop3 A 10.0.0.110
imap CNAME imap4
imap4 A 10.0.0.143
webmail A 10.0.0.443
www A 10.0.0.80
staff NS ns-staff0
NS ns-secondary0
/var/named/staff.domain.net on ns0-staff.domain.net staff.domain.net, a delegated domain used by the employee for their own site.
$ORIGIN staff.domain.net.
staff.domain.net.
86400 IN SOA
ns-staff0.domain.net. hostmaster.domain.net. (
2002021312 28800 7200 604800 86400 )
NS ns-staff0.domain.net.
A 192.168.0.80
MX 10 mx.domain.net.
MX 20 secondary.domain.net.
firewall A 192.168.0.254
smtp A 192.168.0.25
www CNAME firewall
* CNAME www
www.* CNAME www
/var/named/customer.com on ns0.domain.net customer.com, a domain managed by domain.net owned by one of its customer.
$ORIGIN customer.com.
customer.com. 86400 IN SOA
ns0.domain.net. hostmaster.domain.net. (
2002020819 28800 7200 604800 86400 )
NS ns0.domain.net.
NS ns1.domain.net.
NS ns2.domain.net.
MX 10 mx.domain.net.
MX 20 secondary.domain.net.
smtp CNAME smtp.domain.net.
pop CNAME pop.domain.net
imap CNAME imap.domain.net.
www CNAME www.domain.net.
/var/named/0.168.192.in-addr.arpa on ns0.domain.net 0.168.192.in-addr.arpais the domain which allow IP to Name DNS
$ORIGIN 0.168.192.in-addr.arpa.
0.168.192.in-addr.arpa.
86400 IN SOA
ns0.domain.net. hostmaster.domain.net. (
2002021415 28800 7200 604800 86400 )
NS ns0.domain.net.
NS ns1.domain.net.
NS ns2.domain.net.
0 A 255.255.255.0
PTR domain.net.
1 PTR server-at-ip-1.domain.net.
PTR another-server-at-ip-1.domain.net.
25 PTR smtp.staff.domain.net.
254 PTR firewall.staff.domain.net.
DNS records context
domain.net is an isp or firm domain. The DNS server ns0, ns1 and ns2 for domain.net. are known from the DNS root server (ie: have glue records).
This domain contains all the services that the user of the domain needs to access, such as:
- pop
- smtp
- www
The domain staff.domain.net. is a delegation controlled by the employee and customer.com is the customer domain. it is used for the staff web server
The staff.domain.net only has one DNS server as it is a non-important service. In this example, the DNS is provided by the same server which provides mail and web. This is the only case where you should allow a zone (and with reticence) to only have one DNS server as SOA.
DNS code of conduct
As a genaral rule, all services which are going to be used by an end-user (understand everyone outside the firm IT department) should always be on different IP address, even if all services are provided by single computers.
Whenever possible try to use reserved class C to preserve the pool of real world address.
This is important to make sure that you can migrate any service from the server at any time without disturbing end-users. Using FQDN is not sufficient as you can not be sure that end-users have not misconfigured their computers.
As a golden rule, it is important to not use any mail records for SMTP, POP, IMAP service as this limits your scalability options. There is no such thing such as a mail service.
Also, keep the SMTP and MX record separated. It allows to use simple round-robin for the MX service. Ultimately you could have to have all customer accessible services, such as SMTP, POP, IMAP and HTTP behind load balancers to provide the highest availibility possible.
In the case of SMTP, you can probably use the same server as for MX. However, the secondary MX server will most probably be situated outside your network to avoid mail bouncing in case of network outage.
Whenever possible try to use reserved class C to to preserve the pool of real world addresses. Reserved class C are IP addresses you can not find in the internet reserved for office and private network use. The most frequently used range are:
- 10.0.0.0/8
- 192.168.0.0/16
- 172.16.0.0/16
- 169.254.0.0/16 (for transfer networks)
Within the domain.net network, customers will use the IP of ns-cache0 and ns-cache1 as their resolving DNS. ns0 and ns1.domain.net should only be queried by other DNS servers for authoritative answers.
The staff.domain.net domain make use of wildcards (star) to catch all DNS name not already present in the list.
As a consequence, the employee will be able to use surname-name.staff.domain.net and www.surname-name.staff.domain.net as names for their web site. No DNS change will be necessary when new staff start or leave the firm.
Be reminded that the use of CNAME record with MX information is not allowed.
As well, if a customer is using your own mail servers, you should never redefine the MX service. Just use your own mx record in their zone file.
Finally, do not redefine customer services pointing to your server per IP but always alias them with CNAME records.
As DNS is a caching system, changes that need quick propagation change must be prepared. To do so you can change the TTL (Time To Live) of a record which represents how long a DNS will keep DNS information. The TTL is expressed in second and is placed just after the name.
Please bear in mind that the first changes performed on the DNS zone file will take up to the previous TTL to be known by all the internet. Restarting your own cache DNS server can speed-up local updates.
For example, if you are planning to move your web server of room and IP.
Initial record
www A 10.0.0.80
Make sure you have low TTL on your www record. Then wait for the information to propagate. TTL change to 5 minutes
# www A 10.0.0.80
www 300 A 10.0.0.80
You can move the web server to the new IP as if there are problems you can change the IP address to the previous one in less than 5 minutes.
New information
# www A 10.0.0.80
www A 10.0.0.60
Do not forget to restore the default TTL once everything is fine. Built in failover limitation
Unlike the web, DNS was designed with service failure in mind. As it is a crucial service, it is possible to have more than one DNS server answering authoritatively for a domain. However, a common mistake is to think that having two DNS means you are safe. You should make sure that your DNS are on different networks.
In order to achieve the best possible reliability, ISP often have peering agreements to host each others DNS servers.
For example, serious ISP often have one of their Authoritative DNS servers located on another backbone. It provides them protection against BGP problems and Telco faults.
This is very important for mail servers which are performing reverse DNS looking, whithout this precaution any serious outage would cause mail bouncing.
As well, additional protection against malicious plannified Deny Of Service can be deployed to insure the highest DNS uptime possible. Number of DNS
For example, a small/medium ISP will have:
- Two authoritative DNS servers in its network
- One authoritative DNS servers located remotely
- One secondary DNS server for its customers wanting control of their zone
- Four caching DNS servers for customers
DNS servers should be presented to the customer classed by proximity depending on their location (for obvious performance reason, DNS is mostly UDP).
Hopefully, DNS can be allocated dynamicly per customer at connection time for most DSL, ISDN or Modem like connection making it easy to change and scale. Local DNS
Every service relies heavily on DNS such as SMTP servers should use its own DNS server and have local resolv.conf like: /etc/resolv.conf
search mydomain.com
domain mydomain.com
nameserver 127.0.0.1
nameserver 10.0.0.1
nameserver 10.0.1.1
Where 10.0.0.1 and 10.0.1.1 are trusted DNS for the server to use should the local DNS server fail. Delegation
Delegation can typically be used when you feel the need to register a new domain name such as : domain-forum.com, domain-resellers.com, domain-users.com, domain-staff.com, etc.
As well, it allows content filter application (such as N2H2, WebSense or SurfControl) to block sub-site without affecting the main site. Ie: webnews.firm.com is better than www.site.com/webnews (Some NewsGroups can provide adult material which may be unsuitable for young surfers).
Delegation allows you to create new domains, independant of your master domain name. These domains are real domains and as such can have different DNS servers as well as different mail or web servers.
The previous example names can be changed as follows: delegated name
| forum.domain.com | is better than | domain-forum.com |
|---|---|---|
| resellers.domain.com | instead of | domain-resellers.com |
| users.domain.com | instead of | domain-users.com |
| staff.domain.com | instead of | domain-staff.com |
One obvious advantage is that you do not have to pay for a new domain name.
In addition, it is nearly impossible for a firm to market and advertise more than one domain name and network identity. By using delegation, end users feel secure as they recognise a known domain name.
Delegation can also be used to manage your DNS record. For example, if you provide DSL or a similar kind of connectivity, you may have in your DNS something like:
- dsl-10-0-0-1.domain.com
- dsl-10-0-0-2.domain.com
- …
- dsl-10-0-0-253.domain.com
This will make the DNS zone file to fill quickly, which is both bad for management and performance. This can be avoided with the creation of a dsl.domain.com zone:
- 10-0-0-1.dsl.domain.com
- 10-0-0-2.dsl.domain.com
- …
- 10-0-0-253.dsl.domain.com
This is only possible if you have DNS management tools with easy front-end. and remember to add these delegations to your /etc/resolv.conf to not have to tape the FQDN (Fully Qualified Domain Name)
Zone delegation works quite well with split horizon, you can have a delegated domain for each office like london.domain.com and paris.domain.com, these domains are invisible outside the offices’ firewalls.
Used in conjonction with the web, it is very handy to manage localisation: www.uk.domain.com can be situated within the uk firm isp when www.fr.domain.com can be hosted in france. Whois and Zone Transfer
Whois is a tool to find information for a domain. It will return the authoritative DNS servers as well as well as some information regarding the registar.
For example the output of “whois bind.com” is:
Whois Server Version 1.3
Domain names in the .com, .net, and .org domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
Domain Name: BIND.COM
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com
Name Server: NS1.DNS.WEBACT.COM
Name Server: NS2.DNS.WEBACT.COM
Name Server: NS3.DNS.WEBACT.COM
Name Server: NS4.DNS.WEBACT.COM
Updated Date: 07-jan-2002
>>> Last update of whois database: Tue, 5 Mar 2002 05:19:23 EST <<<
The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and
Registrars.
Found InterNIC referral to whois.networksolutions.com.
The Data in the VeriSign Registrar WHOIS database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information about
or related to a domain name registration record. VeriSign does not guarantee
its accuracy. Additionally, the data may not reflect updates to billing contact
information. By submitting a WHOIS query, you agree to use this Data only
for lawful purposes and that under no circumstances will you use this Data to:
(1) allow, enable, or otherwise support the transmission of mass unsolicited,
commercial advertising or solicitations via e-mail, telephone, or facsimile; or
(2) enable high volume, automated, electronic processes that apply to VeriSign
(or its computer systems). The compilation, repackaging, dissemination or
other use of this Data is expressly prohibited without the prior written
consent of VeriSign. VeriSign reserves the right to terminate your access to
the VeriSign Registrar WHOIS database in its sole discretion, including
without limitation, for excessive querying of the WHOIS database or for failure
to otherwise abide by this policy. VeriSign reserves the right to modify these
terms at any time. By submitting this query, you agree to abide by this policy.
Registrant:
Quest Technologies, Inc (BIND2-DOM)
2107 O St. NW
Washington, DC 20037
US
Domain Name: BIND.COM
Administrative Contact:
WebAct Administration (HFJTVUVSUO) abuse@WEBACT.COM
WebAct
2107 O St. NW
Washington, DC 20037
US
202-872-0883
Fax- 208-460-8163
Technical Contact:
WebAct Network Operations Center (DWOHKUSAGO) noc@WEBACT.COM
WebAct
2107 O St. NW
Washington, DC 20037
US
202-872-0883
Fax- 208-460-8163
Billing Contact:
WebAct Accounts Payable (XYYGBUVAFO) billing@WEBACT.COM
WebAct
2107 O St. NW
Washington, DC 20037
US
202-872-0883
Fax- 208-460-8163
Record last updated on 07-Jan-2002.
Record expires on 24-Aug-2002.
Record created on 23-Aug-1996.
Database last updated on 5-Mar-2002 03:30:00 EST.
Domain servers in listed order:
NS1.DNS.WEBACT.COM 207.76.173.19
NS2.DNS.WEBACT.COM 207.76.173.20
NS3.DNS.WEBACT.COM 207.76.173.128
NS4.DNS.WEBACT.COM 207.76.173.129
Zone transfer is a way to get a carbon copy of a zone file from a DNS. Some ISP are blocking this feature to pervent massive security weakness scan (security through obscurity).
Software
Misconfigured DNS servers can cause very hard to debug problems. These problems can remain undetected for month.
If you are serious about DNS you have four options:
- To not use BIND 4.x
- To not use BIND 8.x
- To not use BIND 9.x
- To use a software to manage your BIND files
It should be obvious for the reader that I do like D. J. Bernstein’s DJBDNS.
But if after have spent some time reading the DJBDNS site you still want to use BIND, you should use management software for BIND. BIND configuration files are confusing and mistake prone. A badly placed character in a configuration file could cause BIND to refuse reloading or starting.
I was very pleased with a web software called NameSurfer I advise you to take a look at something similar (it was far from free) if you do decide to host your own zones.
Conclusion
When you manage your DNS:
- have at least one authoritative DNS outside your network
- have a clear zone file template for your customers
- splitting service on different IP to force customer to use the right FQDN
- differenciate MX, SECONDARY MX, and SMTP to be able to scale your mail
- use subdelegation
- use some tools to keep your reverse DNS correct
##Glossary
A reserved class C IP is an IP address you can not find on the internet. it is reserved for office and private network use. The available ranges are listed at: http://again.net/cidr. You can as well consult the rfc1918. Authoritative DNS
An authoritative DNS, a abuse of language for DNS servers containing authoritative DNS records, is a DNS which contains the source information for a domain and is registered as such within Internet and answers as such when asked. Glue Record
A glue record is an IP kept by a DNS in order to be able to locate another DNS server. This is used when a DNS is is authoritative for its own domain name.
IE: if ns0.domain.net is authoritative for domain.net, the DNS servers in charge of the .net record need to record the IP of ns0.domain.net in order for other DNS servers to contact it. SOA
NS: DNS record which indicates to the DNS server which server should act authoritatively.
A: DNS record which indicates to the DNS server which server contains DNS information for a given zone
PTR: DNS record which indicates the IP address for a given name
Split horizon, DNS record which indicates the name of a server given its IP. This is not managed automagically by DNS from the A and CNAME record. As a consequence the information can be missing or wrong.
Split horizon DNS are used in conjunction with NAT and firewalls. It means that the DNS answers to the internal DNS queries for local hosts and that it can figure out the IP of external hosts as well.
FQDN: Fully Qualified Domain Name, the name used to name a computer with DNS including the full domain name. Ie: smtp.cnn.com is a FQDN, www or cnn.com are not
The DNS root servers, www.domain.net is in fact an abreviation for www.domain.net. which last dot represent the root DNS server of the Internet (Internet DNS server are a tree structure).
Conclusion
I hope you found this information useful even if this document did not present the problems associated with:
- reverse zone
- secondary problems
- zone transfert from ISP to ISP.
)