[dns-operations] GSLB options?

[Roland Dobbins]

On Oct 29, 2009, at 4:01 AM, Paul Vixie wrote:

> what problems do you still have, that are amenable to DNS-based GSLB  
> ("stupid DNS tricks"), where the cost of
> having those problems is higher than the cost of solving them?

One can achieve lowered latency to clients, greater flexibility for/ 
likelihood of patching and other PM-type activities, increased  
resilience in the face of backhoe attacks, and so on, and so forth.

Concur with you 100% that GSLB-type solutions don't reduce costs -  
they increase costs significantly.  As you indicate, the decision as  
to whether or not to go down this path must be made with an  
understanding of the tradeoffs in complexity, capex, opex, and other  
'externalities'.

GSLB isn't a universal panacea and often isn't justifiable when one  
performs a complete cost/benefit analysis.  But for folks who a) truly  
need it and b) are willing to pay for it, it can be made to work quite  
well - and I put anyone who really needs 'DR' in that category, as  
'DR' never, ever works due to the well-known issues of lack of  
prioritization, inadequate capex, inadequate opex, and refusal of  
management permission to test.

Nor can operationally useful GSLB be achieved merely by manipulating  
DNS, either, as you also wisely imply (and have said elsewhere many  
times in the past, heh); that's another huge misconception surrounding  
GSLB, that one can simply play around with DNS alone and be good to  
go.  It's much more complex than that.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

Sorry, sometimes I mistake your existential crises for technical
insights.

			-- xkcd #625