Zone transfers can be lost forever

Thu Oct 17 09:06:57 UTC 2019

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

-- 
Jean-Christophe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20191017/4a13b58e/attachment-0001.htm>