from:"jean\-christophe manciot"

Re: Zone transfers can be lost forever

2019-10-17 Thread jean-christophe manciot

>
> If the zone file on the primary can be edited by `named` (dynamic
> updates, signing, etc) then you need to `rndc freeze`, edit, `rndc thaw`
> instead.

 I did all that, even restarted the systemd service on the primary after
noticing the the issue.
Then, on *both* servers:

*named-checkzone -j -D -f raw -o - sdxlive.com
<http://sdxlive.com> /etc/bind/db.sdxlive.com.signed*

*zone sdxlive.com/IN <http://sdxlive.com/IN>: loaded serial 2019101614
(DNSSEC signed)OK*



On Thu, Oct 17, 2019 at 1:41 PM Tony Finch  wrote:

> jean-christophe manciot  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*:
> >
> > (serial 2019101614)
>
> Did you `rndc reload sdxlive.com` on the primary?
>
> If the zone file on the primary can be edited by `named` (dynamic
> updates, signing, etc) then you need to `rndc freeze`, edit, `rndc thaw`
> instead.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Hebrides, Bailey: Southeast backing northeast 4 to 6, occasionally 7 in
> Bailey. Rough or very rough, occasionally moderate later in Hebrides.
> Showers.
> Moderate.
>


-- 
Jean-Christophe
___
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

Re: Zone transfers can be lost forever

2019-10-17 Thread jean-christophe manciot

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 <
actionmysti...@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 @0x
> 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 @0x
> 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 <
> actionmysti...@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  wrote:
>>
>>> jean-christophe manciot  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
>&

Re: Zone transfers can be lost forever

2019-10-17 Thread jean-christophe manciot

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 @0x
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 @0x
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 <
actionmysti...@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  wrote:
>
>> jean-christophe manciot  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 p

Re: Zone transfers can be lost forever

2019-10-17 Thread jean-christophe manciot

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

> jean-christophe manciot  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.finchhttp://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 @0x 
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 @0x 
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 @0x 
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 @0x 
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

Zone transfers can be lost forever

2019-10-16 Thread jean-christophe manciot

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 @0x
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
@0x 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 @0x 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 @0x 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.signedzone 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?
-- 
Jean-Christophe
___
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

Re: Zone transfers can be lost forever

Re: Zone transfers can be lost forever

Re: Zone transfers can be lost forever

Re: Zone transfers can be lost forever

Zone transfers can be lost forever

5 matches

Site Navigation

Mail list logo

Footer information