Francesco Altomare
Hasenheide 9
10967 Berlin (Germany)
Mobile: +49 151 65623284

Blog

DNS: Advanced aspects of DNS #2

Advanced aspects of DNS

Welcome back to DNS crash course for intermediate enthusiasts. We have already learnt the basics and it’s time to move on to something more substantial.

DNS NameServers

If you recall, we had talked about zones which is the domain namespace. The top level domains delegate authority to smaller units which are called zones. The information about domain namespace is stored on NameServers. Each specific NameServer has authority over a specific zone. The concept of zones has been introduced to make management of domains possible. Otherwise top level domains have to take up the entire task of managing their domain which would have been impossible. By delegating into zones, these top level domains have to only delegate for their domain. The delegation activity does not stop at the top level. A subdomain can further divide into zones and NameServers.
Those who have some knowledge of OOPs or Object Oriented Programming would be familiar with pointers. In fact pointers are also used in data structures. The domain namespace is also similar in nature. When you delegate information to a subdomain about a zone, you send pointers to the NameServer(s) that are authoritative for that subdomain. When one of your NameServers is asked for data in the subdomain, it can reply with a list of the right NameServers to contact, since you can point to several NameServers at a time.

Master and Slave DNS NameServers

It’s very important to understand the concept and implementation of Master and Slave NameServers. A primary master or simply master NameServer for a zone reads the information directly from a file which is located in the same Server. A single master NameServer may contain information on more than one zone. On the other hand a secondary master or slave NameServer for a zone fetches information from a primary master NameServer. A slave NameServer is actually a misnomer. It seems to convey the message that it is dependent on another for its operation, which is not true. A secondary master or slave NameServer for a zone pulls data from the primary NameServer of that zone. This is called zone transfer. Both master and slave NameServers are authoritative for that zone. You must note that a slave can also load data from another slave. A Master NameServer can act as a slave for another zone. This arrangement of master and slave has been made to facilitate management of DNS. There are many advantages to this arrangement like load balancing and redundancy.

Hidden Master DNS NameServers

There are situations when you don’t want your NameServers to appear in the NS records for its zone. Moreover a Hidden Master DNS NameServers does not act as a resolver. You are certain to ask a question here – why do you require a Hidden Master DNS NameServers at all? A Primary Master acts as a resolver and therefore remains busy. If you wish to bring it down for any reason like maintenance, some of the queries may go unresolved during this period resulting in unacceptable delays. Therefore no administrator would like to shut down a Master for any reason. Since Hidden Master DNS NameServers does not participate in resolving process, it can take its own time to reload a zone without any adverse effect. Remember that DNS management process involves many issues and may lead to unforeseen situations. Essentially, Hidden Master DNS NameServers give an administrator ample time to play with configuration changes.

Resolving entries Round-Robin style and concerns for failure

Round-Robin has been a traditionally popular method to manage server loads. In this method, traffic is directed from one server to another in Round-Robin fashion. The overall load is therefore balanced and distributed on all the servers. This has some limitations. For example, the DNS server has no way to know when a particular server in the Round-Robin faces failure. As a result, it will keep sending traffic to all the servers irrespective of their operational status. End users who are trying to access a website residing on a server in the Round-Robin which has failed will experience problems without the administrator becoming aware of the situation. Moreover, load balancing is likely to go haywire because the traffic load is now shared by fewer servers. In certain situations, when the servers are experiencing high traffic, this may even lead to server crashes. Therefore, use of DNS servers for Round-Robin load balancing is not an ideal solution.

What’s TTL and when to keep it low or high?

By now we know that DNS is a complex set of servers which helps in converting domain names into a set of IP numbers. Ideally, a name should be resolved as quickly as possible. To achieve this objective, TTL or ‘Time to Live’ for each DNS record is specified. It’s the time for which a resolver is cached. If a DNS query is received before the expiry of TTL, the resolver immediately responds without any need to do a lookup further away in the DNS tree.
By keeping the TTL high, the user experience can be enhanced when they are visiting the same website. Meanwhile, it is possible that the website has undergone a change. This change is propagated through the internet but the resolver has no way to know about it, until the cache expires. Till this moment, the resolver holds the old DNS record. Obviously, the TTL should neither be very high nor low. This must be set depending on the circumstances and on the number of queries received.

Does it make sense to run your in-house BIND Server?

This topic has been debated to death by technical people. In-house DNS server has its advantages and disadvantages. We can set the TTL as we desire and play with the settings. Sometimes there can be substantial value addition. But overall, having an in-house DNS server is a painful experience. It can turn out to be costly and you are just one step away from disaster. You have to keep looking out for vulnerabilities and security threats.

Using your crappy Registrar’s DNS or to go for a Public Third Party Service?

Using Registrar’s DNS can be a good or bad experience. Generally, since registrars are into the business for other services, DNS is not their primary activity and this shows. They lack reliability and should be avoided if possible. Some technical experts swear on public DNS services like Google DNS. They are certainly faster and more reliable than the one provided by the ISP.
Nowadays, there are numerous third party DNS providers who promise a lot more than just resolution. CDN, content delivery networks integration with DNS is supported by some third party providers. Geo-locational load balancing along with high availability make such services attractive. Other benefits include:

a) Redirection of end users to an alternate location via DNS if the Primary destination fails
b) Redirection of end users to a different localized website based on language
c) Loopholing out malicious countries under a DDoS attack without having to establish HTTP conns to deny attackers

In this post we learnt more about DNS and the inherent disadvantage of using traditional Round-Robin to resolve DNS. With the advent of CDN or Content Delivery Network, it has now become critical to use the latest third party services and integrate DNS. We will discuss some salient issues connected with CDN in our next post.

  • Linked In
  • Google

Tags: , ,

Leave a Reply

Your email address will not be published. Required fields are marked *