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