Il 13/07/2015 20:47, John Miller ha scritto:
the zone being expired is the most likely. Check everything:
- physical connectivity between ns2 and ns1
That was the problem. I recently changed iptables rules on ns1 and
forgot to test this little thing. The other zones weren't failing
becaus
Am 13.07.2015 um 21:46 schrieb Anand Buddhdev:
On 13/07/15 21:31, Anand Buddhdev wrote:
So what could cause these SOA lookup failures in BIND on one server, but
not another? Could the developers tell me how BIND does SOA queries over
UDP, and is there any way to mimic this with dig?
Oops. I
On 13/07/15 21:31, Anand Buddhdev wrote:
> So what could cause these SOA lookup failures in BIND on one server, but
> not another? Could the developers tell me how BIND does SOA queries over
> UDP, and is there any way to mimic this with dig?
Oops. I just noticed Cathy Almond's response to Irwin
Dear BIND users and developers,
I have 2 BIND 9.10.2-P2 servers, on the same OS and OS version, on
different networks, configured as slaves for many zones.
On one server, everything works well, and there isn't even a single
error in the log. But on the other, I see lots of errors like this:
13-J
At 07 Jul 2015 13:47:45 +0100, Cathy Almond wrote:
>What can happen (and this is really really subtle) is that if there are
>some source ports that named could randomly select, but where
>intermediate firewalls or filters are just dropping, either the SOA
>refresh queries, or the responses, then
On Mon, Jul 13, 2015 at 2:15 PM, Lucio Crusca wrote:
>
> You have been persuasive enough, I'm definitely going to raise the expire
> value, but now the question is: are the SERVFAIL replies a consequence of
> the low expire value?
>
It doesn't help your cause _at_all_. There could be a few reas
Il 13/07/2015 20:21, Reindl Harald ha scritto:
zone transerfs are retried often, but that don't help with such low
expire times, the question still remains why they are failing on the
same host, but that's not a bind problem
I'm pretty sure it's not a bind problem (I'm not pretending it's
Am 13.07.2015 um 20:15 schrieb Lucio Crusca:
Il 13/07/2015 19:51, Darcy Kevin (FCA) ha scritto:
Half an hour is ridiculous, to be honest. Unless you have 24x7x365
eyes-on-glass looking for zone transfer failures *constantly* and
ready and able to *instantly* pounce on any such problems and fix
They are a consequence of a slave not being able to perform a refresh from the
master for a while. This may be because the zone is removed from the master
(but someone overlooked removing it from the slave(s) as well), bad permissions
set on the master, a communications error, to name a few. If
Il 13/07/2015 19:51, Darcy Kevin (FCA) ha scritto:
Half an hour is ridiculous, to be honest. Unless you have 24x7x365
eyes-on-glass looking for zone transfer failures *constantly* and
ready and able to *instantly* pounce on any such problems and fix them
within minutes.
You have been persuas
Expiration values should be set long enough to detect the zone-transfer
problems, and react to them, but not so long that if the zone does eventually
expire after being deliberately removed from the master (but not the slaves),
everyone is not sitting around, scratching their heads, going “what
On Jul 13, 2015, at 10:34 AM, Lucio Crusca wrote:
[ ... ]
> Yes the zone failed to update, I know because if I raise the seqno @ns1, it
> tries to update and it keeps failing. I don't understand why it fails. I
> doubt a Cisco router is to blame here because ns1 and ns2 are two guests of
> the
Il 13/07/2015 19:21, Reindl Harald ha scritto:
check if the zone failed to update from the master and has expired,
been there due a cisco router with "DNS ALG" enabled leading only a
few large zones fail to transfer
Yes the zone failed to update, I know because if I raise the seqno @ns1,
Something I'm noticing is that your SOA record fields are quite small:
aquilacorde.com.3600INSOAns1.virtualbit.it.
info.aquilacorde.com. 2015070601 1200 180 3600 3600
Specifically, your expiration time (first of the 3600s) is set to one
hour. This means that if ns2 hasn't contact
Am 13.07.2015 um 19:19 schrieb Lucio Crusca:
I have two nameservers, the master and its slave, and they work ok for
several zones. However for one of the zones (aquilacorde.com), the slave
replies with SERVFAIL, and I don't understand why
check if the zone failed to update from the master and
Hello,
I have two nameservers, the master and its slave, and they work ok for
several zones. However for one of the zones (aquilacorde.com), the slave
replies with SERVFAIL, and I don't understand why.
The master is ns1.virtualbit.it, the slave is ns2.virtualbit.it.
I've tried enabling debug
16 matches
Mail list logo
