<div dir="ltr"><div>Both very fair suggestions :)</div><div><br></div><div>I should have stressed the fact that we already have a deployed set of PowerDNS servers, spread across several datacenters and AWS regions, and which a large number of (>2000) production systems are already hitting.  Ideally, we'd be able to update the existing PDNS servers in a minimally intrusive way to allow this "fail-through" scenario.  I'm not entirely sure, but from my reading on dnsdist it would require a fairly decent overhaul of the existing infrastructure and data flow.  That said, the level of effort might still be less than writing and deploying a Lua postresolv() hook :)<br></div><div><br></div><div>WRT Winifred's suggestion, I don't see an (obvious) way that forward-zones{-files} would be able to provide the desired "look here first, and return an authoritative answer IF it is found, else fail through to this other resolver" for a given single zone.  My understanding of forward-zones is that it makes the forwarding decision at the zone level, not based on success or failure of a lookup WITHIN a zone.  Please do correct me if I'm wrong though, as if it can do that your solution could well work for our use case.</div><div><br></div><div>Thanks for the responses!</div><div>Tom Williams<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 3, 2022 at 3:07 AM Aki Tuomi <<a href="mailto:cmouse@cmouse.fi">cmouse@cmouse.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 3 August 2022 6.53.11 UTC, Winfried Angele via Pdns-users <<a href="mailto:pdns-users@mailman.powerdns.com" target="_blank">pdns-users@mailman.powerdns.com</a>> wrote:<br>
>Hi Eli,<br>
><br>
>On 03.08.22 01:43, eli glynn via Pdns-users wrote:<br>
>> I've recently inherited a really ugly mess at my company, involving a muddle of PowerDNS, Route53, NS1, and just about every mixed up interaction you could imagine between them all.<br>
>> <br>
>> The biggest part of the jumble is the way PowerDNS was used as a poor-mans split horizon - we have a large number of records which point at internal (e.g. 10.x) ranges, with duplicate entries in Route53 AND/OR NS1 (don't ask) usually pointing at routable IPs.  There's a lot of badness beyond just that, but the majority of my pain is from that basic situation.<br>
>> <br>
>> Because the client systems are pointed at PDNS, and it considers itself authoritative, we're forced to duplicate ALL external records <br>
><br>
>Not sure if I got that right, but "clients" may only ask a Resolver (PowerDNS Recursor) and never an Auth (PowerDNS Authoritative).<br>
><br>
>> (overridden or not) within PDNS, or NXDOMAINs result.  This of course leads to two (or sometimes three) sources of truth for all RRs, and historically the needed due diligence has not been performed to keep them in sync.<br>
>> <br>
>> Long story short, in order to clean up the mess, I'm hoping to implement an "overlay" in PowerDNS, whereby PDNS only contains the RRs which it needs to override.  If a record would normally be identical to the external value (Route53 or NS1) then rather than duplicating it, I'd like PowerDNS to fail through and do a recursive lookup externally, returning that value to the client.  So basically, if an NXDOMAIN or NODATA would be returned for a zone PDNS considers itself authoritative for, it instead recurses and emits whatever comes back from there.<br>
>> <br>
>> It seems this should be doable using a `postresolve()` hook, or even better `nxdomain()` combined with `nodata()` to minimize Lua roundtrips.  But I'm having a heckuva time implementing the recursion part.  I can't find any canned tooling within Lua to do something theoretically simple (e.g. what in python you'd do with `import socket ; return socket.gethostbyname("blah")`).  I've also considered writing a custom backend but would prefer to keep things simple if at all possible<br>
>> <br>
>> I know this is an unusual use-case (though I can see where such an "overlay" could be very useful in a number of scenarios).<br>
>> <br>
>> Any feedback would be appreciated - suggestions, alternate approaches, or even a flat "you can't do that in PowerDNS" if such is the case - it will save me a lot of cycles if so :)<br>
><br>
>What about Recursoes "forward-zones" or "forward-zones-file" features? This way you could forward queries for your internal Domain Names to your internal Auhoritative Nameserver.<br>
><br>
><a href="https://doc.powerdns.com/recursor/settings.html#forward-zones" rel="noreferrer" target="_blank">https://doc.powerdns.com/recursor/settings.html#forward-zones</a><br>
><a href="https://doc.powerdns.com/recursor/settings.html#forward-zones-file" rel="noreferrer" target="_blank">https://doc.powerdns.com/recursor/settings.html#forward-zones-file</a><br>
><br>
>Winfried<br>
>_______________________________________________<br>
>Pdns-users mailing list<br>
><a href="mailto:Pdns-users@mailman.powerdns.com" target="_blank">Pdns-users@mailman.powerdns.com</a><br>
><a href="https://mailman.powerdns.com/mailman/listinfo/pdns-users" rel="noreferrer" target="_blank">https://mailman.powerdns.com/mailman/listinfo/pdns-users</a><br>
<br>
Or you could use dnsdist. See <a href="https://dnsdist.org" rel="noreferrer" target="_blank">https://dnsdist.org</a> - it is recommended for these kinds of things.<br>
-- <br>
Aki<br>
</blockquote></div>