ed-checkzone -j -D -f raw -o - sdxlive.com
<http://sdxlive.com> /etc/bind/db.sdxlive.com.signed*
*zone sdxlive.com/IN <http://sdxlive.com/IN>: loaded serial 2019101614
(DNSSEC signed)OK*
On Thu, Oct 17, 2019 at 1:41 PM Tony Finch wrote:
> jean-christophe manciot wrote:
>
&
ing notifies (serial 2019101614)
*on the secondary*:
nothing happens since it already has that version.
On Thu, Oct 17, 2019 at 11:06 AM jean-christophe manciot <
actionmysti...@gmail.com> wrote:
> However, if I increment the serial number (SN) on the primary from
> 2019101614 to 2019
10:56:09.040 notify: info: zone sdxlive.com/IN <http://sdxlive.com/IN>:
sending notifies (serial 2019101614)*
As you can see, only the previous zone release has been transferred, not he
latest SN.
On Thu, Oct 17, 2019 at 10:33 AM jean-christophe manciot <
actionmysti...@gmail.com> w
e almost certainly looking at a stale
> version of the zone.
>
Noted.
* run `rndc retransfer` on the secondary
>
That works, thanks.
On Wed, Oct 16, 2019 at 3:43 PM Tony Finch wrote:
> jean-christophe manciot wrote:
>
> wow something has chewed up your message and vomited it o
/IN: loaded serial 2019092407 (DNSSEC signed)
As a summary:
+ there should be some kind of zone transfer control to check whether the
transfer has really taken place or not
+ there should be a way to manually force a immediate zone transfer from
the ma
Hello,
I'm trying to find out what the server behavior should be in the following
situation:
client -> server1 -> server2
client asks server1 to recursively resolve a name
server1 does not know and asks server2
server2 sends an ICMP Port Unreachable to server1
Is there something server1 can
Hi,I use nsupdate to update each minute some textfields
representingstatus of several kind of information.
The update performs correctly but some times, (once every ten ortwenty
times) nsupdate outputs an error like :
Communication with XX.XX.XX.XX#53 failed: operation canceled could not
talk to s
7 matches
Mail list logo
