<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>This is great, thank you!</p>
<p>I'd been staring at the problem for too long, my objectivity was gone. These suggestions clear out some cobwebs!</p>
<p>Thanks again.</p>
<p>CH</p>
<p>On 2022-11-17 11:58 PM, Brian Candler wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><span style="white-space: nowrap;">On 17/11/2022 22:48, Michael Hallager via Pdns-users wrote:</span>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">I recommend you fix your underlying issues now by getting all your servers onto the same net block or net blocks which can route between each other without NAT.</blockquote>
<br /> Also I'd suggest fixing the other underlying issue, which is that a single IP address is used for answering both recursive DNS and authoritative DNS. If you put the recursor and [ext] authoritative on different IPs, then dnsdist can vanish and a lot of complexity disappears.<br /> <br /> Since the [ext] authoritative servers would have their own dedicated public IPs, then there would be no issue with notifies and zone transfers between them.<br /> <br /> The [int] authoritative servers can all be bound to private IPs, and can be VPN'd together. The only clients which send requests to them are their local recursors.<br /> <br /> <span style="white-space: nowrap;">Unfortunately this does involve config changes, but you have two options:</span><br /> <br /> 1. Change the IP address of the recursors: you must change all the client machines to point to these new IPs<br /> 2. Change the IP address of the ext authoritative servers: you must change either the NS records in your public zones, or the A records associated with your NS records (and glue records where you have them)<br /> <br /> If you choose option 1, and you bind your recursive servers to private IPs, then you don't need any extra public IP addresses.<br /> <br /> However for performance reasons, it's better if you can give your recursors public IP addresses as well. This is so that the outbound queries they send don't have to go via NAT, which could generate a lot of NAT states in the NAT router they are sitting behind. But of course, the int recursor *can* share the same public IP address as the ext authoritative.<br /> <br /> So you could build it like this, if you don't need to serve recursor clients on the public Internet, and you can put two 10.x.x.x private IPs on each server:<br /> <br /> <span style="white-space: nowrap;">* pdns_server [external] binds to public IP port 53</span><br /> * pdns_recursor binds to internal IP 1 port 53 . It uses the public IP for outbound queries, and forwards requests for local domains pdns_server [internal]<br /> * pdns_server [internal] binds to internal IP 2 port 53 (and/or to a 127 address; the second internal IP is for these servers to do zone transfers)<br /> <br /> <span style="white-space: nowrap;">Regards,</span><br /> <br /> <span style="white-space: nowrap;">Brian.</span><br /> <br /> </div>
</blockquote>
<p><br /></p>
<div>-- <br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><span style="font-size: 11pt;"><strong>CH </strong><ch-and-pdns-users@ch.pkts.ca></span></div>
</div>
</body></html>