The wasteful SOA query is a result of our internal code flow. You can reduce wasteful queries a bit with the new `consistent-backends` setting, but the SOA query will remain.
We (no longer) have a knob to disable metadata, but there's a cache that should also remember your empty response (the default value for `domain-metadata-cache-ttl` is 60 seconds).
If you have a SOA for example.com, pdns will never return REFUSED for anything inside example.com. The zone is there, so an answer must be present - either a name with records, a name with no records for that type, or the name does not exist. (The distinction between the latter two is why you mostly see ANY queries instead of the type the client asked for).
As far as I can tell, you should never be returning 'false' to anything, as that indicates failure, which is different than 'I know I do not have what you are asking for'. Think of it like this: your SQL database does not go 'oh no' when it has zero rows for you; it just gives you zero rows. A pdns remote backend should behave the same. If you return 'empty' for those lookups into domains you have nothing for, instead of false, I expect REFUSED will come out instead of SERVFAIL.
(And, if I'm correct in the previous paragraph, your PR is correct too :-) )
I can echo all of this - we also pay, we're very happy, the concurrency is nice (I believe they're bumping it to 80x soon - when my coworker asked "but what's the catch" I realised we pay by the CPU minute anyway so higher concurrency is a win for CircleCI -and- for US ;) ).
I've also hacked about the 'merge' problem but it's not entirely satisfying.
That all said, with GH actions currently being entirely free, and doing PRs better than CircleCI, we might shift our focus there.
Hello, PowerDNS developer here! Not trying to steal Tenta's thunder here, but you should know that the PowerDNS GeoIP backend can be used without a GeoIP database, in which case it might better be called the 'YAML backend'.
Additionally, if you file a feature request for JSON support in the bindbackend, we might consider it!
You said it right - can help defend. On the other end of your dnscrypt tunnel, the queries will still go out unencrypted. They will just be harder to correlate to you specifically.
It means that for those zones, they explicitly put the IPs of the edge servers in their resolver (Unbound) configuration, so that lookups of names in those zones don't have to go the root servers and then the TLD (like .com) servers, only to find out that the authority (the edge servers in their design) are in the next rack. Instead they will go directly to those edges. This gives them "Addtionally, public zones are completely resolvable within our network without needing to communicate with our external providers. This means any service that needs to look up api.github.com can do so without needing to rely on external network connectivity."
The wasteful SOA query is a result of our internal code flow. You can reduce wasteful queries a bit with the new `consistent-backends` setting, but the SOA query will remain.
We (no longer) have a knob to disable metadata, but there's a cache that should also remember your empty response (the default value for `domain-metadata-cache-ttl` is 60 seconds).
If you have a SOA for example.com, pdns will never return REFUSED for anything inside example.com. The zone is there, so an answer must be present - either a name with records, a name with no records for that type, or the name does not exist. (The distinction between the latter two is why you mostly see ANY queries instead of the type the client asked for).
As far as I can tell, you should never be returning 'false' to anything, as that indicates failure, which is different than 'I know I do not have what you are asking for'. Think of it like this: your SQL database does not go 'oh no' when it has zero rows for you; it just gives you zero rows. A pdns remote backend should behave the same. If you return 'empty' for those lookups into domains you have nothing for, instead of false, I expect REFUSED will come out instead of SERVFAIL.
(And, if I'm correct in the previous paragraph, your PR is correct too :-) )