DDNS Registration behind Load Balancer

[Mark Andrews]

> Mark Andrews wrote:
> >> 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.  
> You sure about that? My understanding, and what I've been told by 
> numerous Microsoft "experts", is that Windows clients that are set to 
> automatically register themselves in DNS ignore NS, SOA.MNAME, etc. and 
> just use whatever is in their resolver list, which often includes 
> caches. RFC 2136 provides a nice loophole for this, of course, by saying 
> that "Requestors are expected to [...] know or be able to determine the 
> name servers for that zone" without putting any limits or restrictions 
> on how they determine this.

	If they do this and send it to a server that is not
	authoritative it will return NOTAUTH or NOTIMPL depending
	apon whether it understands UPDATE or not.

> Unfortunately I can't test this behavior this since we have 
> auto-registration turned off by policy in our environment.
> >   
> >> 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).
> >   
> Yes, you are right.
> 
> Unfortunately, if the Windows behavior I described above is true, then 
> this means BIND can't be used as the cache in this scenario, since BIND 
> provides no way to "turn off" Dynamic Update *completely* for a 
> particular instance (i.e. so that it will generate the required NOTIMPL 
> responses). The most you can do is send back REFUSED, but as you pointed 
> out, this doesn't trigger failover.

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