[dnsdist] force backend lookup for specific query name

Eldon Koyle ekoyle+dnsdist at gmail.com
Sat Jun 26 06:09:58 UTC 2021

On Fri, Jun 25, 2021 at 1:43 PM Lucas Rolff via dnsdist
<dnsdist at mailman.powerdns.com> wrote:
> Hi guys,
> I use dnsdist as a protection layer in front of my DNS servers, where I use the packet cache in dnsdist and allow things to be cached up to 5 minutes:
> pc = newPacketCache(500000, {maxTTL=300, minTTL=0, temporaryFailureTTL=60, staleTTL=60, dontAge=true, maxNegativeTTL=30})

I'm assuming you are caching replies to a domain which you are
authoritative for here.

> This works perfectly fine, and I have a decent cache hit ratio with normal traffic patterns, and obviously a lot higher during high QPS.
> Now, the issue is, I have things like Lets Encrypt which does DNS validation by doing a TXT query to _acme-challenge.<domain> and expects a certain value. However, the value might have been cached previously, meaning it returns the incorrect value for the domain, and thus the validation fail.

Keep in mind, this record will likely be cached by letsencrypt's
recursors, up to the TTL specified by your authoritative server.
Changing the behavior of dnsdist won't affect caching behavior on
other recursors, so the right fix would be to ensure the TTL on the
_acme-challenge.* record isn't too long.  Also keep in mind that an
NXDOMAIN will be cached by recursors.  If you're lucky, they will
honor the value in your SOA record for how long to cache an NXDOMAIN
(smallest of SOA TTL and the SOA MINIMUM field, see

> Is there any “easy” way to basically disable the packetcache for specific query names (ideally wildcarding the domain part of it), so it always causes a query to the backend/upstream servers?

I'm not sure if this is the best way, but you could create another
pool (https://dnsdist.org/guides/serverpools.html) with the same
upstream servers but without a packetcache, then add a rule like the
following (this is untested):

addAction(RE2Rule("_acme-challenge\..*"), PoolAction("uncached_pool"))


More information about the dnsdist mailing list