IPv6 and DNSSEC broken to 384.15 or 384.16_a2 with Cloudflare-DOT

[eclp]

One of the two settings, either "DNS Rebind protection" and/or "DNSSEC support" on the WAN settings tab breaks my IPv6 connection and also DNSSEC.

It happens even after a complete factory reset (L&LD) of my AX88U, either with 384.15 or 384.16_a2 with minimal configuration. Interestingly and although I have completely disabled DNSSEC rootcanary.org shows me correct test results and also here, dnssec.vs.uni-due.de as if I had activated DNSSEC in the router.

I am using Cloudflare-DOT (IPv4 and IPv6) and never had the slightest problem (since implementation in the firmware). Could it be that the Cloudflare itself has changed something? On the test page internet.nl I'm getting strange results independent of the two settings. The two cloudflare test pages 1.1.1.1/help and cloudflare.com/ssl/encrypted-sni only give correct results if "DNS Rebind protection" and/or "DNSSEC support" are deactivated.

All very strange. Any help is welcome!

 

[EmeraldDeer]

I am using DNS Rebind protection without issue.

I am also using Cloudflare DoT. I do not recommend "Enable DNSSEC support". I prefer not to have the router do the DNSSEC work.

I would rather have Cloudflare do the DNSSEC work and set the DNSSEC bit in the DNS reply to dnsmasq. This is on by default and explains why the DNSSEC tests are successful.

 

[Simon W]

I too have been observing some strange results with Cloudflare DoT - have previously used this setup without issue, yet a few days ago I've started having problems (has taken me a while to post!). This has been using 384.16_A2 and B1.

At first I thought it was an interaction with IPv6 causing the problem (I'd briefly enabled IPv6 support.. before realising my ISP doesn't support IPv6 yet!) and this is when my problems started - intermittently not being able to resolve certain domains or at least not being able to connect to them (which got me thinking was I being served an old cached IPv6 address by mistake?). I reset / reconfigured from ground upwards, so hopefully ruling out my brief visit into IPv6 land, and narrowed it down to DoT being setup to use Cloudflare - if I either disabled DoT or used another provider (Google) then the problems immediately went away. Currently I've left my setup using Google my DoT provider.

Interestingly, I noticed the domains I seemed to be having problems with were Cloudfare-hosted domains, though my sample number was too small for this to be a definitive pattern.

Finally, and potentially completed unrelated, I noticed another Cloudflare anomaly last night: I was doing some WAN latency testing and as usual used 1.1.1.1 as my control target (easy to type in!) - I started getting failures - this was unexpected as I was testing for changes in latency and NOT actual routing! Scratched my head for a good half an hour, trying various wi-fi and then wired clients, all with the same results - I could ping my gateway router fine, but responses from 1.1.1.1 were being intermittently dropped. I then did what I should have done in the first place: I tried pinging something else = success! Entirely repeatable: responses from 1.1.1.1 = sporadic, 8.8.8.8 (or anywhere else non-Cloudflare) = 100%. I've of course just tried to repeat the test now and 1.1.1.1 seems to be being reliable again. Perhaps they are or at least have been struggling with recent increased internet traffic?