DDNS Registration behind Load Balancer

[Kevin Darcy]

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.

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.

                                                                         
                              - Kevin