That domain doesn’t have DNSSEC enabled. It may be your ISP, can you see if it fails by setting router DNS to default or Google and setting your OS’s dns to 1.1.1.1?
@crkinard can you clarify where in that post you see a DNSSEC issue? DNSCrypt is a different technology.
What I’ve seen with these issues in the past is other DNS providers are more lax about validating the DNSSEC, allowing through sites which should rightfully be broken.
aljazeera.com. 300 IN CNAME 2-01-3b91-0003.cdx.cedexis.net.
2-01-3b91-0003.cdx.cedexis.net. 20 IN CNAME www.aljazeera.com.edgekey.net.
www.aljazeera.com.edgekey.net. 21600 IN CNAME e9106.dscg.akamaiedge.net.
e9106.dscg.akamaiedge.net. 20 IN A 23.210.132.235
When I Googled that DNSMasq error message, that was the only concrete explanation I found. For all I know, it could happen for lots of other reasons too.
There’s no issue with kresd’s own, internal DNSSEC validation – as far as I know – but there are issues with its responses that can break validating clients.
DNSCrypt for AsusWRT is a plugin for Asus routers to allow them to user DNSCrypt. However it also has support for using DNS over HTTPS (DoH).
In a recent update to the Asus router firmware they have added support for DNSSEC which works fine with other DNS servers. But when enabled with 1.1.1.1 it starts throwing “Insecure DS reply received” in the logs. Once again this doesn’t happen with other DNSSEC enabled DNS servers.
Now the conversation about this error took off in the DNSCrypt thread on the SNB forum and the conclusion was that Cloudflare wasn’t using the standard version of DNSSEC and that’s why the router wasn’t able to use it properly.
akamaiedge.net isn’t a signed zone. dscg.akamaiedge.net isn’t a zone cut, either. There’s no reason to send a DS query for dscg.akamaiedge.net. And as far as I can tell, there’s nothing wrong with the response, and I don’t see any difference between 1.1.1.1’s response and those of other resolvers.
I don’t know what DNSMasq’s algorithm is, but I can imagine reasons to send unnecessary DS queries – mainly to prioritize speed over sending the fewest queries. But anything about the response should be considered a debug or informational message. Not an indication of an error.
There are 3 things going on:
1.1.1.1’s DNSSEC validation is fine internally, as far as I know.
Under some circumstances, it doesn’t return certain DNSSEC information to the client, so a validating client may not be able to, er, validate.
We don’t have enough information to be sure what’s going on in this case. My last post probably covers a lot of it, though. In which case it’s #2.