Also, if I send the command "rndc notify sdxlive.com" on the primary, I get in the logs: *on the primary*:
17-Oct-2019 11:08:46.047 general: info: received control channel command 'notify sdxlive.com' 17-Oct-2019 11:08:46.053 notify: info: zone sdxlive.com/IN (signed): sending 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 2019101709 and order a retransfer on the secondary with "rndc > retransfer sdxlive.com", I get in the logs: > *on the primary*: > > *17-Oct-2019 10:56:09.038 xfer-out: info: client @0xcccccccccccc > a.b.c.d#49155 (sdxlive.com <http://sdxlive.com>): transfer of > 'sdxlive.com/IN <http://sdxlive.com/IN>': AXFR started (serial 2019101614)* > *17-Oct-2019 10:56:09.039 xfer-out: info: client @0xcccccccccccc > a.b.c.d#49155 (sdxlive.com <http://sdxlive.com>): transfer of > 'sdxlive.com/IN <http://sdxlive.com/IN>': AXFR ended: 1 messages, 36 > records, 2906 bytes, 0.001 secs (2906000 bytes/sec)* > > *on the secondary*: > > > > > > > > > *17-Oct-2019 10:55:39.015 general: info: received control channel command > 'retransfer sdxlive.com <http://sdxlive.com>'17-Oct-2019 10:56:09.031 > general: info: zone sdxlive.com/IN <http://sdxlive.com/IN>: refresh: retry > limit for master e.f.g.h#53 exceeded (source 0.0.0.0#0)17-Oct-2019 > 10:56:09.031 general: info: zone sdxlive.com/IN <http://sdxlive.com/IN>: > Transfer started.17-Oct-2019 10:56:09.033 xfer-in: info: transfer of > 'sdxlive.com/IN <http://sdxlive.com/IN>' from e.f.g.h#53: connected using > a.b.c.d#4915517-Oct-2019 10:56:09.040 general: info: zone sdxlive.com/IN > <http://sdxlive.com/IN>: transferred serial 201910161417-Oct-2019 > 10:56:09.040 xfer-in: info: transfer of 'sdxlive.com/IN > <http://sdxlive.com/IN>' from e.f.g.h#53: Transfer status: > success17-Oct-2019 10:56:09.040 xfer-in: info: transfer of 'sdxlive.com/IN > <http://sdxlive.com/IN>' from e.f.g.h#53: Transfer completed: 1 messages, > 36 records, 2906 bytes, 0.006 secs (484333 bytes/sec)17-Oct-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> wrote: > >> wow something has chewed up your message and vomited it out again but some >>> of the remnants are vaguely legible... >>> >> I don't know what happened, but some IP addresses & other fields have >> been intentionally obfuscated. The original first message have been >> attached to this answer. >> >> I'm not sure this belief is entirely solid, given what the logs said. >>> >> The logs on the primary show no error during the transfer, although it >> did not occur in reality. >> >> You have to use the -j option to include any changes recorded in the >>> zone's journal, otherwise you are 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 <d...@dotat.at> wrote: >> >>> jean-christophe manciot <actionmysti...@gmail.com> wrote: >>> >>> wow something has chewed up your message and vomited it out again but >>> some >>> of the remnants are vaguely legible... >>> >>> > - the debug log shows that the zone transfer has *successfully* taken >>> place >>> > on the primary towards the secondary server: >>> > >>> > - actually, the zone transfer could not have succeeded because the >>> port 53 >>> > was closed on the secondary server for the master >>> >>> I'm not sure this belief is entirely solid, given what the logs said. >>> >>> > - indeed, the secondary server has no knowledge of the new data: >>> > >>> > # named-checkzone -D -f raw -o - sdxlive.com [snip] >>> >>> You have to use the -j option to include any changes recorded in the >>> zone's journal, otherwise you are almost certainly looking at a stale >>> version of the zone. >>> >>> If a zone is loaded and running, I usually find it is easier to use `dig >>> axfr` (or `host -lA` if I don't want DNSSEC clutter), instead of >>> named-compilezone, and `dig soa` instead of `named-checkzone`. >>> >>> You can try `nsdiff -m primary -s secondary zone` to verify that the zone >>> files are consistent <http://www.dotat.at/prog/nsdiff/>, e.g. >>> >>> $ nsdiff -m pri0.dns.cam.ac.uk -s auth0.dns.cam.ac.uk cam.ac.uk >>> nsdiff: loading zone cam.ac.uk. via AXFR from auth0.dns.cam.ac.uk >>> zone cam.ac.uk/IN: loaded serial 1571232847 (DNSSEC signed) >>> OK >>> nsdiff: loading zone cam.ac.uk. via AXFR from pri0.dns.cam.ac.uk >>> zone cam.ac.uk/IN: loaded serial 1571232847 (DNSSEC signed) >>> OK >>> $ >>> >>> [ I'm obviously massively biased, but `nsdiff` is amazingly reassuring >>> when you are doing big DNS provisioning infrastructure changes. ] >>> >>> > - whatever I try, it seems impossible to retransfer the zone data now >>> that >>> > the port 53 is open on the primary: >>> >>> You can: >>> >>> * run `rndc retransfer` on the secondary >>> >>> * run `rndc notify` on the master to maybe prompt a retransfer, depending >>> on whether the secondaries are up to date >>> >>> * bump the serial on the primary again to prompt a retransfer by >>> persuading the secondaries they are out of date >>> >>> A primary can't force a transfer to a secondary, it can only send the >>> secondary a NOTIFY to suggest that the secondary might want to transfer. >>> >>> Tony. >>> -- >>> f.anthony.n.finch <d...@dotat.at> http://dotat.at/ >>> Northwest Fitzroy, Sole: Southwesterly 4 to 6, increasing 7 or gale 8. >>> Rough >>> or very rough becoming very rough or high. Showers. Good, occasionally >>> poor. >>> >> >> >> -- >> Jean-Christophe >> > > > -- > Jean-Christophe > -- Jean-Christophe
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
