DDNS Registration behind Load Balancer

Kevin Darcy kcd at chrysler.com
Tue Jul 1 04:51:45 UTC 2008


Mark Andrews wrote:
>> 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.
>   
If the cache is BIND, it will return NOTAUTH (rather than NOTIMPL, since 
BIND *does* support Dynamic DNS code-wise). NOTAUTH responses are not 
failed over, so the bottom line is, as I stated in my previous message, 
that BIND would be unsuitable for use as "primary" (i.e. 
first-in-resolver-list-sequence) caching resolvers serving Wintel 
clients with automatic DNS registration enabled, if my understanding of 
their server-selection behavior is correct.

Some other implementation would have to be used in this case, such as 
Microsoft's own DNS product (surprise, surprise).

Frankly, I find it a little odd that NOTAUTH and REFUSED aren't failed 
over. SERVFAIL I can understand, because it's a catch-all for all sorts 
of problems and might be indicative of a more profound issue with the 
infrastructure. Aborting the Dynamic Update is the safe thing to do in 
the face of some essentially _unknown_ scenario.

But NOTAUTH/REFUSED just means the server you talked to isn't accepting 
your Dynamic Update (either because of its zone configuration or its 
security ACLs, respectively), why not fail over to some other server 
that *will*? Why is it that if you try to use Dynamic Update to a 
nameserver that doesn't happen to have the *code* to process it, you 
fail over, but if you try it against a server which doesn't have the 
*zone*config* or the *ACL* to allow it, you stop dead in your tracks? 
Not sure of the rationale behind this, it seems to unnecessarily limit 
architectural flexibility without buying any robustness. In fact, it 
seems to *harm* robustness in the case where you're migrating nameserver 
instances from authoritative nameservers to caching nameservers for a 
particular zone; you have to be very careful about the sequence in which 
you do that, since you might inadvertantly blow some auto-registering 
Wintel clients out of the water if you get it a little wrong. If clients 
failed over on NOTAUTH, then that would provide a cushion to implement 
the migration with minimal negative impact.

But, since this is bind-users rather than namedroppers, I'll guess I'll 
just put that out there and not invite further comment...

                                                                         
                           - Kevin



More information about the bind-users mailing list