Building Scalable DNS Cluster using LVS - Revision history

ZaphodB: /* [http://doc.powerdns.com/built-in-recursor.html PowerDNS recursor] */

2008-10-30T17:57:51Z

‎[http://doc.powerdns.com/built-in-recursor.html PowerDNS recursor]

2007-07-04T12:48:45Z

‎PowerDNS recursor

2007-07-04T12:48:09Z

‎BIND9

2007-07-04T12:47:38Z

‎BIND9

2007-07-04T12:46:12Z

‎BIND9

2007-07-04T12:44:29Z

‎BIND9

2007-07-04T12:41:11Z

‎Introduction

2007-07-04T12:37:45Z

‎Configuration Example

2007-07-04T12:28:15Z

‎Architecture

2007-05-10T14:56:12Z

‎Architecture

@@ Line 75: / Line 75: @@
 === [http://doc.powerdns.com/built-in-recursor.html PowerDNS recursor] ===
-This one is a recursive-only Nameserver with very limited authorative DNS capabilities. The author of this Example uses PowerDNS recursor (v.3.1.4) exclusively for his caching-only DNS cluster by now and is glad that while giving roughly the same queries per second performance it generates less SERVFAIL answers and is generally several times more robust than BIND9.
+This one is a recursive-only Nameserver with very limited authorative DNS capabilities. The author of this Example uses [http://doc.powerdns.com/built-in-recursor.html PowerDNS recursor] exclusively for his caching-only DNS cluster by now and is glad that while giving roughly the same queries per second performance it generates less SERVFAIL answers and is generally several times more robust than BIND9.
 === added redundancy via iBGP ===

@@ Line 73: / Line 73: @@
 BIND 9.4 line makes use of this new internal malloc library by default now, but disabling threading will probably free you from the hickups some BIND9 users are experiencing.
-=== PowerDNS recursor ===
+=== [http://doc.powerdns.com/built-in-recursor.html PowerDNS recursor] ===
 This one is a recursive-only Nameserver with very limited authorative DNS capabilities. The author of this Example uses PowerDNS recursor (v.3.1.4) exclusively for his caching-only DNS cluster by now and is glad that while giving roughly the same queries per second performance it generates less SERVFAIL answers and is generally several times more robust than BIND9.

@@ Line 53: / Line 53: @@
   iptables -t nat -A PREROUTING -i eth1.109 -s $net -d 194.97.173.124 -p udp --dport 53 -j DNAT --to-destination 10.3.53.2:53
-=== BIND9 ===
+=== [http://www.isc.org/index.pl?/sw/bind/ BIND9] ===
-When i wrote this example we were using two <a href="http://www.isc.org/index.pl?/sw/bind/">BIND</a> processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something JINMEI Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:
+When i wrote this example we were using two BIND processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something JINMEI Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:
   If you go with disabling threads, you may also want to enable
   "internal memory allocation".  (I hear that) it should use memory more

@@ Line 55: / Line 55: @@
 === BIND9 ===
-When i wrote this example we were using two BIND processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something JINMEI Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:
+When i wrote this example we were using two <a href="http://www.isc.org/index.pl?/sw/bind/">BIND</a> processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something JINMEI Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:
   If you go with disabling threads, you may also want to enable
   "internal memory allocation".  (I hear that) it should use memory more

@@ Line 69: / Line 69: @@
   #define ISC_MEM_USE_INTERNAL_MALLOC 0
   #endif
-Try it and you will keep it. ;) Btw. IIRC the upcoming BIND 9.4 line makes use of this new internal malloc library by default.
+Try it and you will keep it. ;)
 === PowerDNS recursor ===

← Older revision		Revision as of 12:41, 4 July 2007
Line 4:		Line 4:

	Scalable DNS cluster can help provide scalability and availability of DNS service.		Scalable DNS cluster can help provide scalability and availability of DNS service.
		+
		+	The Example below is about setting up a cluster for recursive DNS but you can just as well use the same method for authorative DNS as well. Just remember that clients who use your cluster as a secondary nameservice would need to also-notify{} each of your realservers, not just the service-IP.

	== Architecture ==		== Architecture ==

@@ Line 51: / Line 51: @@
   iptables -t nat -A PREROUTING -i eth1.109 -s $net -d 194.97.173.124 -p udp --dport 53 -j DNAT --to-destination 10.3.53.2:53
-We are using two BIND processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something Jinmei Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:
+When i wrote this example we were using two BIND processes on the same machine for BIND9 currently just runs faster when it is not threading. Here is something Jinmei Tatuya told me on the bind9-workers Mailinglist which turned out to be very true:
   If you go with disabling threads, you may also want to enable
   "internal memory allocation".  (I hear that) it should use memory more
@@ Line 68: / Line 69: @@
 Try it and you will keep it. ;) Btw. IIRC the upcoming BIND 9.4 line makes use of this new internal malloc library by default.
 If you have more than one Loadbalancer at different locations and you can convince your local Networker to let you speak BGP4+ to his routers you can use quagga with something like the following configuration to failover the service IP to the second LB if the first one goes down:

@@ Line 7: / Line 7: @@
 == Architecture ==
-DNS is a simple service, there is no affinity between requests from the same client. DNS usually run at UDP port 53 and TCP port 53.
+DNS is a simple service, there is no affinity between requests from the same client. DNS usually listens for queries at UDP port 53 and TCP port 53.
-LVS can simply load balance UDP port 53 and TCP port 53 among a set of DNS servers, and there is no need to setup the persistent option.
+LVS can simply load balance UDP port 53 and TCP port 53 among a set of DNS servers, and there is no need to setup any persistence options.
 == Configuration Example ==

← Older revision		Revision as of 14:56, 10 May 2007
Line 7:		Line 7:
	== Architecture ==		== Architecture ==

		+	DNS is a simple service, there is no affinity between requests from the same client. DNS usually run at UDP port 53 and TCP port 53.
		+
		+	LVS can simply load balance UDP port 53 and TCP port 53 among a set of DNS servers, and there is no need to setup the persistent option.

	== Configuration Example ==		== Configuration Example ==