Host is not resolved with DNSSEC

can’t verify a host with DNSSEC when I use Cloudflare DNS.

Here DNSSEC-Info is missing:
dig +dnssec +short @

Google can do it:
dig +dnssec +short @
A 7 4 0 20190116084157 20190109084157 59882 FRwZTaGfhI0a01wpgsa3F3SF3cBgD9vORfT/QSoPDjl5urX5M9aCUfyV dif/NoSj9Pxg7o05ENCJ4yfqctSty5i7P6TyOvmX39H0tqtOx1Tv8Lta BComVMueW0RJxaFrwDaUNzZINNnu/bj0rdasLmcReWfwVY6yUlD9HO/A gCQ=
A 7 4 0 20190117084144 20190110084144 10739 FbX6ud0GBZ60uDi26spml41HxqHmKRaeyGFKAizob1h7rjI4dfrxSRVc afSpuq2fIGe7bJpczu0qNHCKQBP9L2uKXsgquL6nefSav2Sqqoo3S6PF QrGRYzP7CDkrwUtWHGUZev3apBuHaa+QO0m2Jbq9Fl3XKlWGEVSoadDC ydg=

A check looks fine:

Whats the problem?

The problem is that uses name servers that send responses that are subtly untrue (bad type bitmaps in NSEC3) that cause problems for resolvers implementing an extremely aggressive version of RFC 8198 Aggressive Use of DNSSEC-Validated Cache. As far as I am aware, the only resolver that uses DNSSEC type bitmaps for synthesis is the open source Knot resolver, which Cloudflare uses for their service. The problematic name servers are F5 devices used for and other domains (the DNS violations tracker issue includes a number of Czech domains, presumably since Knot is a Czech product and is more commonly used there).

You are not seeing the DNSSEC records for any domains from because Cloudflare has disabled DNSSEC for because of this incompatibility. Since it doesn’t query for the DNSSEC records, it cannot return them.

See the Problem with and thread for more gory technical details (note that is not affected by this issue).

You can use any other DNSSEC-validating resolver, such as Google (, Verisign (, or Quad9 ( to resolve these domains with DNSSEC records.

If you strongly prefer Cloudflare, consider opening a feature request issue for the Knot resolver to allow disabling the aggressive DNSSEC cache feature for particular domains without disabling DNSSEC validation entirely. Google’s resolver has this capability (see this example with even gorier technical details). and it is a poor operational response to disable the security features of DNSSEC (which are working for these domains) because F5 name servers are breaking the aggressive use of DNSSEC negative response cache.

Knot resolver has a few related issues already, but they are about fixing the aggressive negative caching, not enabling more nuanced operational responses.

1 Like

If this reply can help or at least relate to this topic …

.de registry should support algorithm 13 if you wish to have DNSSEC with Cloudflare as Cloudflare currently gives us the values for DS record only with 13.

Similar what I have had for my Websites which were using ccTLD .hr ( / where it was the only supported as listed here:

  • 3, 5, 6, 7, 8, 10 algorithms (without the 13!)

So, situation was that at Croatian .hr ccTLD ( / registry until August last year, it was not even possible to choose algorithm 13 and have DNSSEC enabled for .hr domains, if the domain was added to Cloudflare and we want to have it working as well.

Moreover, since the last year, in mid April when it was urged and finally adopted in August 2020 to support algorithm 13 for .hr ccTLD domains (it took me three and a half months to get an response and answer from them), works perfectly.

I recommend if it is possible via multiple ways - you as a private person, some organization, some other, some University or Faculty, urge them - .de ccTLD registry - to update it as soon as possible.
In case of a trouble, there is always someone else who can do the monitoring and other related stuff like DNSSEC validations, maintenance, anycast, for a TLD in Europe like Netnod and others.