<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">On 2019-05-29 02:52, frank+pdns--- via Pdns-users wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">On 29 May 2019, at 06:24, Christian Tardif <<a href="mailto:christian.tardif@servinfo.ca">christian.tardif@servinfo.ca</a>> wrote:<br /> <br /> Hi,<br /> <br /> I'm trying to get this to work:<br /> <br /> I have one master pdns in a docker container with bridge networking on 1 server, plus a slave pdns, also in a docker container with bridge networking on another server. On the master, I have a zone (until I get it to work) configured as I would do with any other dns servers (SOA, NS records (with the real IP of the master and slaves, as I need to reach them from this "external" ip).</blockquote>
<br /> Are both servers in a Docker Swarm network or are they standalone<br /> servers? If standalone, is migrating to a Swarm network an option? It<br /> would make things a lot easier, network-wise.</blockquote>
</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Not really, unfortunately. The hosts where this resides are already running kubernetes as docker containers. So why installing pdns within Kubernetes then? I can't, as this pdns is meant to be the primary DNS for the main network, which DNS the nodes need in order to be able to actually start kubernetes..  the chicken and egg issue...
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">When I'm doing an update on the zone in the master, I see that, on the slave server, that I'm receiving the NOTIFY, but coming from 172.17.0.1 (got from the docker bridge) but then, the slave tries to get either the SOA on NS records for the zone....  at 172.17.0.1, which leads to nothing, as this is a NAT.   How can I have the slave to unconditionally request the master server (on its real IP) for this zone about the SOA so this master/slave setup actually works?</blockquote>
<br /> In general. if you want to use the supermaster functionality when the<br /> NOTIFYs are coming from a different ip, you’ll need to change the ip<br /> of the master in the domains table of your backend to the “real” ip.<br /> You could do that using triggers in the database for instance (or have<br /> a script that you run every minute to update the records).<br /> <br /> However, let’s take a step back. Docker does outbound NAT, not 2-way<br /> NAT. Let’s assume on serverA, you run container1 (your master).<br /> container1 has (local) container ip 172.16.0.10. serverA has public ip<br /> 10.10.10.10.<br /> <br /> Your slave runs in container2 (172.17.0.20) on serverB (10.10.10.20). <br /> <br /> The NOTIFY container2 receives, should have a source ip address<br /> 10.10.10.10, which is the correct ip, as container2 should use that<br /> address to reach container1. (Assuming your Docker hosts aren’t in<br /> a/the same Swarm network). If you’ve told docker to map port 53 (tcp<br /> and udp) to your containers, then this setup should work.<br /> <br /> Could you describe your setup, describe which ports you’ve opened and<br /> where, and where exactly you see the NOTIFY coming from the wrong ip?</blockquote>
</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Sure I can. My setup, from this point of view, is a plain Docker setup, using bridge networking.</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">pdns master is running on host 192.168.213.11, and container ip is 172.17.0.4</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">pdns slave is running on host 192.168.213.12, and container ip is 172.17.0.3</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">both containers have gateway set to 172.17.0.1, and hosts have gateway set to 192.168.213.1</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Both containers publishes udp/53 and tcp/53  (as 0.0.0.0:53) so basically, I can connect to any of these two, targetting the 192.168.213.x IP</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">But when I do a zone update on the master container, docker logs of the pdns-slave shows these two things, for all the domains for which he should be authoritative:<br /><br />- Received NOTIFY for _this_particular_zone_ from 172.17.0.1 for which we are not authoritative</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">- Error resolving SOA or NS for _this_particular_zone_ at: 172.17.0.1: Query to '172.17.0.1' for SOA of '_this_particular_zone_' produced no answer</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Already, this 172.17.0.1 thing is strange, as this isn't the IP of any of the containers. And for sure, 172.17.0.1 won't return anything, as pdns isn't listening there...</div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Christian...</div>
</body></html>