DNS server load

domain-name-system

We are trying to determine what we will need in terms of hardware and bandwidth to run a DNS server which will be an authority for say 5,000 domains. The web servers get a few hits per second. (These are small sites, hence the slanted numbers).

We were planning on using BIND or some other unix-friendly DNS server daemon for this, probably on Linux or FreeBSD. I have no idea how many DNS queries this type of www load will generate, or how much bandwidth it would use, or how expensive the queries are in terms of processing and memory use.

Does anyone here have experience with DNS in the wild?

Best Answer

The only stats I have on DNS are from my personal server farm (personal site, projects, hosting for freelance clients) as I don't run the DNS machines at work. This is for about 6 domains, with about 15,000 WWW views per month. The servers are both older HP Proliants, dual 1.4GHz pentium, 2GB RAM, and both are hosting more than DNS (also DHCP and a slew of other services). I have a script that pulls query stats every hour. I'm seeing an average of 21M queries on my primary server and 100k queries on my secondary each day. The BIND process doesn't even show up in top.

Related Solutions

Windows – What’s the command-line utility in Windows to do a reverse DNS look-up

ping -a w.x.y.z

Should resolve the name from the IP address if the reverse lookup zone has been set up properly. If the reverse lookup zone does not have an entry for the record, the -a will just ping without a name.

Why is DNS failover not recommended

By 'DNS failover' I take it you mean DNS Round Robin combined with some monitoring, i.e. publishing multiple IP addresses for a DNS hostname, and removing a dead address when monitoring detects that a server is down. This can be workable for small, less trafficked websites.

By design, when you answer a DNS request you also provide a Time To Live (TTL) for the response you hand out. In other words, you're telling other DNS servers and caches "you may store this answer and use it for x minutes before checking back with me". The drawbacks come from this:

With DNS failover, a unknown percentage of your users will have your DNS data cached with varying amounts of TTL left. Until the TTL expires these may connect to the dead server. There are faster ways of completing failover than this.
Because of the above, you're inclined to set the TTL quite low, say 5-10 minutes. But setting it higher gives a (very small) performance benefit, and may help your DNS propagation work reliably even if there is a short glitch in network traffic. So using DNS based failover goes against high TTLs, but high TTLs are a part of DNS and can be useful.

The more common methods of getting good uptime involve:

Placing servers together on the same LAN.
Place the LAN in a datacenter with highly available power and network planes.
Use a HTTP load balancer to spread load and fail over on individual server failures.
Get the level of redundancy / expected uptime you require for your firewalls, load balancers and switches.
Have a communication strategy in place for full-datacenter failures, and the occasional failure of a switch / database server / other resource that cannot easily be mirrored.

A very small minority of web sites use multi-datacenter setups, with 'geo-balancing' between datacenters.

Best Answer

Related Solutions

Windows – What’s the command-line utility in Windows to do a reverse DNS look-up

Why is DNS failover not recommended

Related Topic