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
