Does 1.1.1.1 really run DNSSEC?

SSE and Zero trust 1.1.1.1
1

I have 1.1.1.1 (and its backup as well as IPv6) loaded into my router. The thing is it is spewing errors:

Insecure DS reply received, do upstream DNS servers support DNSSEC?

Sometimes many times with the same timestamp. Sometimes not for a long while.

Asus RT-AC86U
Merlin 384.6

2

What domains are you trying to reach?

3

No way of really telling unless I keep going to random links and tail the syslog. I really do not have time for that.

4

This is virtually always an issue in the underlying domain’s DNSSEC configuration.

5

Yet I do not get these errors swapping back to Google or other DNS servers.

6

Did some reading on the firmware makers forums. Seems Cloudflare is not using full/proper DNSSEC spec.

I wonder how long this will take to get fixed.

1 Like
7

Just noticed https://www.aljazeera.com/ is not resolving and the router is throwing the error every time I try.

8

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?

9

@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.

1 Like
10

I think this might be kresd #359.

aljazeera.com. has said invalid configuration:

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.

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q3/012392.html

(Relating to a different domain and resolver.)

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.

11

Updated the firmware to the next beta.

dnsmasq (2.80test4)

Now displaying a little bit more information.

Insecure DS reply received for dscg.akamaiedge.net, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

12

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.

13

akamaiedge.net isn’t a signed zone. :confused: 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.1’s DNSSEC validation is fine internally, as far as I know.
  2. Under some circumstances, it doesn’t return certain DNSSEC information to the client, so a validating client may not be able to, er, validate.
  3. 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.