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
_______________________________________________ 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
