Help with unresolvable domain (subdomain, actually)

[Kevin Darcy]

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