DDNS Registration behind Load Balancer

[Mark Andrews]

> 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 Balance
> r
> >>>>>>>>> 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 als
> o
> >>>>>>> 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 rega
> rd
> >>>>         
> >> .
> >>     
> >>>>     
> >>>>         
> >>> 	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.

	Which is not how Microsoft says the clients do it.

	http://support.microsoft.com/kb/317590		(Windows 2000)
	http://support.microsoft.com/kb/816592		(Windows 2003)

	The SOA query uses the local cache.  The UPDATE goes direct.
	If the master is unreachable
	The NS query uses the local cache.  The UPDATE goes direct to the
	listed nameservers.

	Now if yoiu can find documentation that says otherwise please
	post the URL.

> > 	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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org