If you want to ensure well working failover you must, at some point,
test it. Even better, you may want to regularly test it (check out
Netflix's Chaos Monkey).
One way to run a simulation would be to use a firewall rule or static
route to block access between your test client/recursive server
You're right: I misinterpreted "no name-server" as "no such host" (aka
NXDOMAIN), but actually your explanation makes more sense.
- Kevin
On 6/9/2014 6:07 PM, Barry Margolin wrote:
In article ,
Kevin Darcy wrote:
That scenario sti
In article ,
Kevin Darcy wrote:
> That scenario still shouldn't have led to an NXDOMAIN. If none of the
> delegated nameservers are responding, you'd get a timeout or SERVFAIL.
> So I think there's still some investigation to be done. But using dig
> instead of nslookup at least makes things
Again - thanks for the quick response - that'll teach me to post without
all the facts. I simply don't remember what the specific error was, darn
it. It might have been NXDOMAIN or SERVFAIL - I didn't write it down.
The test I was running was on a barely, if ever used, domain, so I was
pretty sure
That scenario still shouldn't have led to an NXDOMAIN. If none of the
delegated nameservers are responding, you'd get a timeout or SERVFAIL.
So I think there's still some investigation to be done. But using dig
instead of nslookup at least makes things clearer :-)
Of course, caching may compli
Thanks, Kevin, for your quick reply. In the last few minutes, I've come to
realize that my problem is likely that the domain is only registered with
two name servers - the one which were offline. Even though the zone has 6
NS records, the .com servers probably only know of the ones in the
registrat
Well, you shouldn't be getting an NXDOMAIN just because some of your
auth servers are off-line, but you could get some query timeouts if
performance to your failover servers is really bad (or blocked, due to
firewall rules, bad routes, etc.), or, if your expire times are *really*
low, and the m
7 matches
Mail list logo
