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

2019-10-17 Thread 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

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

2019-10-17 Thread 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

Re: Zone transfers can be lost forever

2019-10-17 Thread 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

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

2019-10-17 Thread 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

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

Re: Zone transfers can be lost forever

2019-10-17 Thread 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

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

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

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