On 3/2/2011 10:34 AM, David Sparro wrote:


On 3/1/2011 5:27 PM, Kevin Darcy wrote:
See my other post. This is designed-in behavior for Cisco GSSes, since
there is no "service unavailable, try again later" RCODE.


When the question is "what is the ip address of 'foo'" an answer of "the web server is down" in nonsensical.

Hmmm... matter of perspective I suppose. Load-balancer architecture sees DNS as just the externally-visible portion of a whole subsystem. The SERVFAIL, in their view, does not communicate a DNS problem _per_se_, but a problem with the whole subsystem. It's more of a "what you're trying to get to is unavailable right now" message, communicated, in their view, _through_ DNS (as a sort of conduit), not necessarily _about_ DNS. They don't see it as specifically meaning "I've got a DNS problem".

I'm not saying I agree with this perspective, only that I've dealt with load-balancer vendors enough (Cisco in particular) to understand that this is where they're coming from.

Besides, what alternative is there? If the load-balancer returns an address that it knows to not be working, then it's purposely causing the client to go into a relatively-slow connection-timeout failure mode. Is that responsible behavior? If it gives a "normal" response that is lacking answer information (NODATA, NXDOMAIN), then this response gets negatively cached, and the negative cache entry may delay clients from re-trying the resource even after it recovers. So, what's left? NOTIMP? FORMERR? REFUSED? NOTAUTH? Those aren't any better than SERVFAIL from a strictly functional perspective, and are even more misleading and confusing with respect to the real source of the problem.

- Kevin


_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to