DDNS Registration behind Load Balancer

Mark Andrews Mark_Andrews at isc.org
Fri Jun 27 01:48:03 UTC 2008


> Mark Andrews wrote:
> >> On Jun 26, 2008, at 4:05 PM, Kevin Darcy wrote:
> >>     
> >>> Chris Buxton wrote:
> >>>       
> >>>> On Jun 26, 2008, at 1:53 PM, Linux Addict wrote:
> >>>>
> >>>>         
> >>>>> Greeting!!
> >>>>>
> >>>>> I am configuring a DNS setup where its mix of Linux and Windows  
> >>>>> hosts.
> >>>>> I decided to go with BIND rather than MS DNS Server. I have Windows
> >>>>> hosts doing dynamic registration to the BIND Master Server.
> >>>>>
> >>>>> The next step on my project is add Load Balancer with 3 servers. I  
> >>>>> was
> >>>>> thinking of one master and 2 slaves initially. Then it struck me  
> >>>>> that
> >>>>> when a Windows Host does DDNS registration against the Load Balancer
> >>>>> VIP, and when the Load Balancer redirects the traffic to one of the
> >>>>> slave server, it will not accept the changes as its only secondary.
> >>>>>
> >>>>>           
> >>>> Not true. 'allow-update-forwarding { any; };'.
> >>>>
> >>>>
> >>>>         
> >>> That'll work as long as the OP only has masters and slaves, but  
> >>> doesn't
> >>> allow the flexibility to add caching-only resolvers in the future.
> >>>
> >>> I still think the best approach is to have the DHCP server(s), rather
> >>> than the clients themselves, register the client names in DNS. It also
> >>> raises less security issues.
> >>>       
> >> I completely agree. I was just pointing out to the OP that one of his  
> >> assertions was untrue.
> >>
> >> Chris Buxton
> >> Professional Services
> >> Men & Mice
> >>     
> >
> > 	Caching only name servers are a authorgonal issue.  Your
> > 	load balancer may be able to look at the DNS OPCODE and
> > 	redirect all UPDATE requests to one machine.
> >   
> It's not orthogonal if there is a proliferation of caching-only 
> resolvers at remote sites, with no load-balancers in front of them, or 
> no load-balancers capable of the OPCODE-based redirection you describe. 
> We don't have a lot of information about the OP's network topology 
> and/or their plans for the future, so we can only speculate in that regard.

	UPDATE requests are sent to authoritative servers.  They
	are *not* sent to caches.   At worst the probing for the
	zone to update can add a cached NXDOMAIN response.  Named
	doesn't cache negative responses to SOA queries so that it
	is possible to discover the containg zone without introducing
	side effects.
 
> One thing we can be fairly certain of, however, is that there is some 
> sort of DHCP infrastructure in place -- if all the clients have static 
> IPs it presumably wouldn't be necessary to update DNS dynamically at all 
> -- and it seems to me cleaner and more straightforward to have the DHCP 
> server do the DNS update, rather than the client.
> 
> Another missing piece of the puzzle is: why put the master *and* the 
> slaves behind the same load-balancer VIP? Seems to me, at a minimum, 
> you'd want to segregate the slaves from the master, since they serve 
> different functions. If the client *must* do the Dynamic Update, for 
> some reason, perhaps it could fail over to the master's address after 
> the Dynamic Update request gets REFUSEd by the slave VIP.

	No, the correct response is NOTIMPL.  The client does not
	implememt the forwarding of UPDATE requests to the master.
	REFUSED should result in the client immediately returning.
	(Yes there are update clients that continue on refused).

	This allows the client to distingish between a slave that
	has forward the UPDATE request to a master which then refused
	it and a slave that is not configured to forward updates.

	Mark

>                            - Kevin
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org


More information about the bind-users mailing list