> > 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
Hi there, Here's the context: Ubuntu 19.10 / Debian bullseye 11 bind9 9.15.4 zone "sdxlive.com" { type master; file "/etc/bind/db.sdxlive.com"; // Publishing and activating dnssec keys auto-dnssec maintain; // Using inline signing inline-signing yes; allow-transfer { w.x.y.z; }; ... } I'm experiencing a peculiar situation in both aforementioned distributions: - I have modified a zone file and incremented its serial number on the master to 2019101515 - the debug log shows that the zone transfer has successfully taken place on the primary towards the secondary server: 15-Oct-2019 16:54:59.075 xfer-out: info: client @0xaaaaaaaaaaaa w.x.y.z#54219 (sdxlive.com): transfer of 'sdxlive.com/IN': IXFR started (serial 2019092407 -> 2019101515) 15-Oct-2019 16:54:59.075 xfer-out: info: client @0xaaaaaaaaaaaa w.x.y.z#54219 (sdxlive.com): transfer of 'sdxlive.com/IN': IXFR ended: 1 messages, 14 records, 1412 bytes, 0.001 secs (1412000 bytes/sec) 15-Oct-2019 16:55:14.078 xfer-out: info: client @0xbbbbbbbbbbbb w.x.y.z#58529 (sdxlive.com): transfer of 'sdxlive.com/IN': AXFR started (serial 2019101515) 15-Oct-2019 16:55:14.078 xfer-out: info: client @0xbbbbbbbbbbbb w.x.y.z#58529 (sdxlive.com): transfer of 'sdxlive.com/IN': AXFR ended: 1 messages, 36 records, 2906 bytes, 0.001 secs (2906000 bytes/sec) - actually, the zone transfer could not have succeeded because the port 53 was closed on the secondary server for the master - indeed, the secondary server has no knowledge of the new data: # named-checkzone -D -f raw -o - sdxlive.com db.sdxlive.com.signed zone sdxlive.com/IN: loaded serial 2019092407 (DNSSEC signed) - whatever I try, it seems impossible to retransfer the zone data now that the port 53 is open: on the primary: rndc freeze sdxlive.com serial number --> 2019101614 rndc thaw sdxlive.com A zone reload and thaw was started. Check the logs to see the result. # grep -P "16-Oct-2019 .* xfer-out: .* -> 2019101614" /var/log/named/debug.log # on the secondary server: # named-checkzone -D -f raw -o - sdxlive.com db.sdxlive.com.signed zone sdxlive.com/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 master to the secondary server(s) even though only the serial number has changed So, are these + bugs + some missing features + or am I missing something?
_______________________________________________ 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