 carpRejected
join:2002-10-30
1 edit | reply to sporkme
Re: [HELP] Prepending AS path in Multihomed setup You sound uninformed about solving it with DNS, Radware, etc. Works like a charm in many situations. |
|
 sporkmedrop the crantini and move it, sisterPremium,MVM
join:2000-07-01
Morristown, NJ
 ·Optimum Online
| said by carp:You sound uninformed about solving it with DNS, Radware, etc. Works like a charm in many situations. Quite the contrary. No matter what box you use for DNS load-balancing you are still relying on DNS, which I understand quite well. I also understand how broken DNS servers not under your direct control can completely bork up your plans when you rely on DNS for failover of inbound services.  |
|
 rolandeCertifiablePremium,Mod
join:2002-05-24
Columbus, OH
Linksys
AT&T Midwest
| said by sporkme:I also understand how broken DNS servers not under your direct control can completely bork up your plans when you rely on DNS for failover of inbound services. Really? I'd be interested to know what the scenarios were where you encountered the issues. The only issue I am aware of is primarily the 0 TTL issue with broken versions of BIND. Alternatively, if you are providing active/active geographic load balancing via DNS, you can run into issues with any clients using a provider's DNS that is serviced via Anycast.
In any case, we are talking about failover here. Failover should take place rarely for which the actual number of clients who might be impacted would be quite negligible anyway. So the argument can go either way fairly easily.
I have leveraged both 3DNS and the GSS product for global load balancing since 2002 in a couple of extremely high profile financial hosting environments serving literally millions of customers around the world. I have yet to be engaged in a troubleshooting call during a failover event, which app owners seem to incur on a regular basis for testing and DR events, where a user's DNS response was cached and stuck to the "offline" facility. I have witnessed the 0 TTL phenomenon on many occasions, not of my own doing, and I have seen Anycast client DNS cause out of state issues with applications. I'd love to know the issues you have experienced with "broken" DNS servers.
In the end, if a client has broken DNS, there isn't much you can do about it and it is not your responsibility, in any case. You build your own environment to support the standards. If others have issues because they are non-compliant, then it is up to them to resolve the problem.
--
Ignorance is temporary...stupidity lasts forever!
»www.thewaystation.com/
»blog.thewaystation.com/ |
|
sporkmedrop the crantini and move it, sisterPremium,MVM
join:2000-07-01
Morristown, NJ Reviews:
·Optimum Online
| said by rolande:said by sporkme:I also understand how broken DNS servers not under your direct control can completely bork up your plans when you rely on DNS for failover of inbound services. Really? I'd be interested to know what the scenarios were where you encountered the issues. I've not seen it with load balancing since I don't do that, but I've certainly seen misbehaving caching nameservers hold something much longer than the specified TTL. I have no idea what software said nameservers were running, my assumption was that it was not either BIND or DJBDNS... |
|
|
|
rolandeCertifiablePremium,Mod
join:2002-05-24
Columbus, OH Host:
Linksys
AT&T Midwest
| As an entity providing a hosted service, you can not take on the responsibility of "broken" client DNS servers. As long as you are obeying the standard, it is up to them to resolve their problem.
What if the customer decided it was in their best interest to provide extended BGP dampening? If your routes flap in BGP, you get blackholed from the customer for a period of time. This is the exact same situation and you can not be responsible for a broken configuration on the client's end.
Application layer failover is not a bad thing. It is actually better for us networking types because it takes the responsibility of resiliency off our shoulders.
--
Ignorance is temporary...stupidity lasts forever!
»www.thewaystation.com/
»blog.thewaystation.com/ |
|
