Re: Change source IP at outgoing packet send by Bind9 as forwarder.

[Grant Taylor via bind-users]

On 10/17/19 3:16 PM, CpServiceSPb . wrote:
But when Bind9 forwards queries to external servers, it do it via wan 
interface but uses at the first onset server external IP as sources, 


I'm not surprised by this.


which is not changed by SNAT or MASQUERADE Iptables.


It can be, but it depends on your iptables rules.

So how is to change Bind9 , what and where is to set up and waht setting 
that Bind9 would send forwarding packet via wan interface but would use 
address what it is binded to or internal, if it is binded to 127.0.0.1 
and 192.168.0.1 ?


To me, this is not a BIND setting.  Rather I think it is a Linux routing 
setting.


Run the following command and check the results.

   ip route get $RemoteDNSIP

You will quite likely see that Linux is going to send traffic via the 
configured router using the WAN IP as the source IP address.


This is functionally what BIND is doing.  It's creating a UDP datagram / 
TCP segment and asking the Linux kernel to turn it into an IP packet and 
send it.


You can use ip routes and ip rules to influence this process.  More 
specifically, you can tell Linux to source packets to specific 
destinations* /from/ the LAN IP.


*specific destinations are usually IP addresses.  But I am quite sure 
that there are ways to match traffic to UDP and / or TCP port 53.  You 
may need ip rules or possibly to mark packets with iptables, et al.


The only time that I've seen this be a problem is when something like a 
VPN or strict filtering on the far end is in place such that the WAN IP 
is not allowed / is not able to communicate with the remote server. 
Yet, the LAN IP is.


Cause Linux to use the LAN IP as the source for this specific traffic.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Change source IP at outgoing packet send by Bind9 as forwarder.

[Noel Butler]

OK, it might be too early and i'm not getting your question, I'm only
half way through my first coffee of the day... 

But if you have 192.168.0.1 as  lan, and the wan, lets say is 1.1.1.1,
and needs to resolve a hostname, it has to go to the big wide world of
internets, and it can only do that using 1.1.1.1, therefor thats the
only way it will work, your internal LAN IP is not asking the root
serves or subsequent in chain, your WAN IP is, because routing, pvt
address space etc, you know... 

On 18/10/2019 07:16, CpServiceSPb . wrote:

> I have Bind9 on Ubuntu 18.04 x64 LTS working as a cache and forwarding one.
> There are some forwarders IPs.
> 
> Server has 2 NICs (lan and wan) .
> 
> BInd9 binds strictly to localhost and lan NICs, that is to 127.0.0.1 and
> 192.168.0.1.
> But when Bind9 forwards queries to external servers, it do it via wan
> interface but uses at the first onset server external IP as sources, which
> is not changed by SNAT or MASQUERADE Iptables.
> Unlike other soft, for example Asterisk, what is binded to lan interface
> only and uses internal (192.168.0.1) IP as source for outgoing packet and
> then iptables changes source address of such outgoing packets from internal
> to external using either SNAT or MASQUERADE.
> 
> So how is to change Bind9 , what and where is to set up and waht setting
> that Bind9 would send forwarding packet via wan interface but would use
> address what it is binded to or internal, if it is binded to 127.0.0.1 and
> 192.168.0.1 ? 
> ___
> 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

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument___
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

[Noel Butler]

Edit the primary zone,  just put a TXT record in it, saying anything,
gibberish even,  save and reload the zone 

let us know so we can check it for currency on both your NS1 and NS2 

If you followed Tony's advice there is no reason it is not in sync and I
don't see an issue. 

On 18/10/2019 05:48, jean-christophe manciot wrote:

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

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument___
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

Change source IP at outgoing packet send by Bind9 as forwarder.

[CpServiceSPb .]

I have Bind9 on Ubuntu 18.04 x64 LTS working as a cache and forwarding one.
There are some forwarders IPs.

Server has 2 NICs (lan and wan) .

BInd9 binds strictly to localhost and lan NICs, that is to 127.0.0.1 and
192.168.0.1.
But when Bind9 forwards queries to external servers, it do it via wan
interface but uses at the first onset server external IP as sources, which
is not changed by SNAT or MASQUERADE Iptables.
Unlike other soft, for example Asterisk, what is binded to lan interface
only and uses internal (192.168.0.1) IP as source for outgoing packet and
then iptables changes source address of such outgoing packets from internal
to external using either SNAT or MASQUERADE.

So how is to change Bind9 , what and where is to set up and waht setting
that Bind9 would send forwarding packet via wan interface but would use
address what it is binded to or internal, if it is binded to 127.0.0.1 and
192.168.0.1 ?
___
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

[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
 /etc/bind/db.sdxlive.com.signed*

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

[Tony Finch]

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

[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 ): transfer of
> '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 ): transfer of
> '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 '17-Oct-2019 10:56:09.031
> general: info: zone 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 :
> Transfer started.17-Oct-2019 10:56:09.033 xfer-in: info: transfer of
> '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
> : transferred serial 201910161417-Oct-2019
> 10:56:09.040 xfer-in: info: transfer of '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
> ' 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 :
> 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 , 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 

Re: Zone transfers can be lost forever

[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 ): transfer of
'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 ): transfer of
'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 '17-Oct-2019 10:56:09.031
general: info: zone 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 :
Transfer started.17-Oct-2019 10:56:09.033 xfer-in: info: transfer of
'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
: transferred serial 201910161417-Oct-2019
10:56:09.040 xfer-in: info: transfer of '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
' 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 :
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 , 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.

Re: Zone transfers can be lost forever

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