Zone transfers can be lost forever
jean-christophe manciot
actionmystique at gmail.com
Thu Oct 17 08:33:35 UTC 2019
>
> 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 <dot at dotat.at> wrote:
> jean-christophe manciot <actionmystique at 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 <dot at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20191017/a5184662/attachment.htm>
-------------- next part --------------
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?
More information about the bind-users
mailing list