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