Zone transfers can be lost forever

Thu Oct 17 09:14:31 UTC 2019

Also, if I send the command "rndc notify sdxlive.com" on the primary, I get
in the logs:
*on the primary*:

17-Oct-2019 11:08:46.047 general: info: received control channel command
'notify sdxlive.com'
17-Oct-2019 11:08:46.053 notify: info: zone sdxlive.com/IN (signed):
sending notifies (serial 2019101614)

*on the secondary*:

nothing happens since it already has that version.

On Thu, Oct 17, 2019 at 11:06 AM jean-christophe manciot <
actionmystique at gmail.com> wrote:

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

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