<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'>
<p>Hi PDNS users, I need your advice:  (Note: there's a <strong>TL;DR:</strong> section at the bottom)</p>
<p>We've set up three nameservers (ns1, ns2 and ns3) with two ip addresses each: an internal 10.x.x.x and an external public ip.</p>
<p>Each server runs dnsdist, pdns_recursor, and two copies of pdns_server, like this:</p>
<p><span style="font-family: courier new, courier, monospace;">    dnsdist -> pdns_recursor -> pdns_server [internal]</span><br /><span style="font-family: courier new, courier, monospace;">            \</span><br /><span style="font-family: courier new, courier, monospace;">              pdns_server [external]</span></p>
<ul>
<li>Dnsdist is listening on 127.0.0.1, 10.x.x.x, and the external public ip, all on port 53.</li>
<li>pdns_recursor is listening on 127.0.0.2</li>
<li>pdns_server (internal) is listening on 127.0.0.3</li>
<li>pdns_server (external) is listening on 127.0.0.4</li>
<li>systemd_resolved is listening on 127.0.0.53 to satisfy local dns requests (Ubuntu 20.04 default configuration, with 127.0.0.2 as its resolver)</li>
</ul>
<div> </div>
<div>Requests come in to dnsdist, and based on their source address they're forwarded to 127.0.0.2 (internal) or 127.0.0.4 (external).</div>
<div>Pdns_recursor forwards requests to 127.0.0.3 (pdns_server internal) for zones listed in the forward zones file and recursively answers the rest.</div>
<div> </div>
<div>So far, so good; requests come in, replies go out, and external clients can't abuse our recursor or see our internal dns entries, yayyy!</div>
<div> </div>
<div>=====</div>
<div> </div>
<div>Here's where things start go off the rails:</div>
<div> </div>
<div>Our internal network grew "organically", and for reasons lost in the mists of time, we've got NAT gateways in our network, one of which is between ns3 and the other two name servers.</div>
<ul>
<li>When a zone is updated on ns1, it sends a notify to ns3, but the source ip is changed by the NAT gateway. </li>
<li>The notify-acknowledgement is sent back through the NAT gateway and ns1 gets it, since the gateway expected the response.</li>
<li>Ns3 then sends an SOA request to the NAT gateway (as that's where the notify came from), but it's lost because it's not related to the previous conversation.</li>
<li>Pdns_recursor seems to eat Notify and AXFR messages, so we've told Dnsdist to direct those to 127.0.0.3</li>
</ul>
<p>We've temporarily worked around the problem by adding an iptables rule to ns3 that says 'redirect packets sent to "port 53 on the gateway" to ns1', and it works.</p>
<p>======</p>
<p>Things are now going further off the rails here:</p>
<ul>
<li>Now we've added a bunch of independent sub-zones on small name servers in different parts of our company, and they're going to be using ns1, ns2 and ns3 as their secondary servers, whichever is closest. </li>
<li>Notifies are going to be flying all over, and packets from some of them will be going through the same NAT gateway that ns1 uses to get to ns3.</li>
<li>Because of that, the iptables rule is going to mess things up, as it assumes outgoing DNS requests to the NAT gateway should really go to ns1's internal address.</li>
</ul>
<p>Is there a way to get the SOA request from ns3 to go to the right place using pdns or dnsdist?</p>
<p>======</p>
<p>Now we're so far off the rails, we're in the middle of a cornfield:</p>
<ul>
<li>The internal and external pdns servers have different zone files (internal/external ip addresses, some hosts not listed in the external zones).</li>
<li>We're using the internal ips on ns1,2,3 for transferring internal zones, and the external ips for external ones.</li>
<li>We're attempting to use <a title="NetmaskGroupRule" href="https://dnsdist.org/rules-actions.html#NetmaskGroupRule" target="_blank" rel="noopener noreferrer"><code class="descname">NetmaskGroupRule</code></a> with src=false to have dnsdist direct requests internally/externally based on that.</li>
<li>The independent sub-zone name servers will be notifying the ns1,2,3 on both internal and external ips, and the NAT is going to mess up the source ips, iptables can't handle this.</li>
</ul>
<p>Can we use DoH/DoT to establish a TCP connection for the NOTIFY and reuse it for the SOA and AXFR?  The NAT respects open TCP connections much more than UDP conversations.</p>
<p>Should we manually add entries to the zone metadata to specify where zones are really hosted?  I really wanted to use the auto-secondary feature, but sometimes we can't have nice things.  :-/</p>
<p>Oh god, please don't tell me I have to set up a VPN between all the name servers.... :-(</p>
<p>Anyhow, I'd love to hear someone write a happy ending to this story.</p>
<p>======</p>
<p><strong>TL;DR:</strong> How do you get notifies + zone transfers to work when the source ip addresses of NOTIFY packets are unreliable?</p>
<div>Thanks!</div>
<div> </div>
<div>-- <br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><span style="font-size: 11pt;"><strong>CH (<a href="mailto:ch-and-pdns-users@ch.pkts.ca">ch-and-pdns-users@ch.pkts.ca</a>)</strong></span></div>
</div>
</body></html>