In message , Raymond Drew Walker writes:
>
> Apologies,
>
> Our workaround was actually the addition of 2 lines:
>
>check-names master ignore;
>check-names response ignore;
"check-names master ignore;" or "check-names ignore;" at the zone
level, is all that is required to have upd
Apologies,
Our workaround was actually the addition of 2 lines:
check-names master ignore;
check-names response ignore;
Without the second ‘response’ clause, the update does not error, but does not
get applied to the record.
—
Raymond Walker
Software Systems Engineer StSp.
ITS - N
Our current workaround is to add the following to NAMED configuration:
check-names master ignore;
Is there a more preferred solution?
…or perhaps a different way of looking at this issue?
—
Raymond Walker
Software Systems Engineer StSp.
ITS - Northern Arizona University
From: Ray Walker mailt
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
Hello,
I've got 6 name-servers, 2 in each of 3 global regions. Each name-server
has a net connection. Each name-server is authoritative. the domains it
server have all six NS records.
My question has to do with redundancy. If one of my "regions" goes down, I
would have expected that a query agains
Running BIND 9.9.5:
On moving to a hidden primary setup, dynamic updates to zones we are master for
with “unallowed characters” (underscores in our case) have started to fail with
the error "bad owner name (check-names)” In the past (pre hidden primary) they
did not fail.
In the past we have n
Jorge Fábregas wrote:
>
> This change is going to impact thousands of users for us and I'm a bit
> worried about it. How do you deal with DNSSEC bogus data?
We don't do anything special to reduce the problem. It has not caused
noticable pain or complaints from our users.
We have I think had on
11 matches
Mail list logo
