[dnsdist] Unexpected behavior with SpoofCNAMEAction

Remi Gacogne remi.gacogne at powerdns.com
Mon May 31 07:34:22 UTC 2021

Hi Eldon,

On 5/26/21 7:22 PM, Eldon Koyle via dnsdist wrote:
> I'm trying to spoof a CNAME reply to enforce safe search, but running
> into unexpected behavior.
> I have a rule like:
>      -- try to match all possible google TLDs, optionally with www.
>      addAction(RE2Rule("(www\\.)?google(\\.co)?\\.[a-z]+"),
> SpoofCNAMEAction("forcesafesearch.google.com", {ttl=300}))
> When visiting google.com, I see:
>      * client: google.com IN A ?
>      * dnsdist:  google.com IN CNAME forcesafesearch.google.com
>      * client: forcesafesearch.google.com IN AAAA ?
>      * dnsdist: forcesafecearch.google.com IN AAAA 2001:4860:4802:32::78
> The client only gets an AAAA record, and I am on an IPv4-only network,
> so the client is unable to communicate.
> It seems the client is expecting dnsdist to follow the CNAME  and
> return the target A record along with the CNAME in the first response
> (which makes sense performance-wise, but I'm not sure whether it is
> required by a standard).
 >> Is there a way to tell dnsdist to follow the CNAME and return the
> requested record type along with the spoofed CNAME?

It's unfortunately common for stub resolvers to expect that the server 
will have followed a CNAME, and to not bother checking whether this is a 
true (a SOA record should have been present, had the target of the CNAME 
not have any A record).
Unfortunately dnsdist doesn't know how to follow a CNAME, because it's 
not a resolver. The PowerDNS Recursor can do that [1], because it does 
perform the actual resolution.
A different solution might be to directly return a A, but of course you 
would need to make sure that the value remains up to date. It could be 
done via the Lua "maintenance" function [2], but it requires a bit of 
Lua code.


Best regards,
Remi Gacogne
PowerDNS.COM BV - https://www.powerdns.com/

More information about the dnsdist mailing list