Problem with and

Okay, thanks for the answer.

What is the situation at

Can you be more specific? The domain doesn’t resolve or some of its subdomains?

The oneplus website always looks like this to me:

I get the picture with different browsers.
On different PCs
As well as on the mobile phone.
As soon as I use Google or Quad9 as DNS, the website is displayed correctly.

Can you provide a more detailed example (DNSViz link?) of the “slightly invalid” NSEC3 records for Is it not possible to disable aggressive NSEC3 caching without disabling DNSSEC validation? Since uses NSEC3, Google Public DNS works since it only does aggressive NSEC caching, but does not implement aggressive NSEC3 caching.

The problem with is unrelated, since that domain doesn’t use DNSSEC at all. It is more likely to be an issue with QNAME minimization.

The issue with is that the NSEC3 records returned for NODATA proof contain a wrong bitmask of types that exist. If you ask for such record:

$ kdig TXT +dnssec | grep NSEC3 | grep -v RRSIG 86400	IN	NSEC3	1 0 1 804B4661061795C4 rlkadlagu4vtnj8o1lef3f48a0q7km29 HINFO

The last field in the NSEC3 record is the bitmask of DNS types that exist for this name. You can verify that this is indeed the hash for

$ knsec3hash  804B4661061795C4 1 1
rlkadlagu4vtnj8o1lef3f48a0q7km28 (salt=804B4661061795C4, hash=1, iterations=1)

What this record is saying that for, only HINFO exists. But that’s clearly not true, as A exists when you ask for it:

$ kdig +short A +dnssec
A 7 3 60 20180828164140 20180821164140 32954 ZNpbRSbCVqVgamXrCH9mn1vV5mRCjCik0wND5FVEyaduvxA3UVM0IxlsuD7bzNTkoZ9bRRMPwlFEFwZKNgdnLo336LJ8/bC/6W5MrPwJAk/qqqUrWeZJ98OCd1PqMyNIW+VSh+nFSy6CbK87Ke8zgd5oglxHSZJYkATLRqWlZ+E=
A 7 3 60 20180829164135 20180822164135 53960 cOqxlDzdBOtR3bhepKfuphNctf5tZ4ZZ6uZL4XDIfBmldKvQP7EUsmzf924lHFe+zRCrWknScf681hbU9pqmwnjNudjDHavaFpjbeviGUxS/OwFuVlOzPEmbhFQRRhN1EWFFqZSVapgjfAswhqt81PUUtKW9Wn4Xf1figoWfF/k=

It’s not possible to exclude one domain from aggressive NSEC3 caching without opt-out currently.


Oh, that’s interesting. So the name servers are doing RFC 4470/4471 white lies one better and putting just HINFO in the RR type bitmap so that you can’t even enumerate RR types without 64k queries. Could their selection of HINFO for that purpose have possibly been inspired by Cloudflare’s responses to ANY queries or your black lies? :slight_smile: They would have done better to stick to the implementation of the latter (no need for NSEC3) and say that things exist (even if they don’t) rather than claiming they don’t exist even though they do.

We should give those a name, I would suggest yellow lies (postbank color)? It’s a bit like the bald-faced lies the name servers were returning (I’m glad to see they have fixed this by rectifying their zones).

Relevant to this would be some (off-topic) discussion I had with Vladimír Čunát on the Knot resolver issue tracker.

Since the minimally covering NSEC(3) records in white, black, or yellow lies don’t provide any really useful information for aggressive NSEC(3) caching, it would be better not to use them at all.

1 Like

Sadly the issue related to still persists. Any updates on this topic?

We’ve identified the issue in the DNS product that and several others use and trying to get it fixed. In the meantime, we’ve disabled DNSSEC for the affected domain(s) until it’s resolved.


The bitmaps, if they’re not broken like with F5 here, are in fact helpful in preventing future queries for different types for the same name - for example, in a happy eyeballs scenario.



I still cannot go on until I change my networks DNS Servers to
I would like to use Cloudflare DNS Servers. So what is the status on

It appears that some instances force-downgrade DNSSEC to insecure on but not all. From my vantage point (CZ) it mostly appears downgraded but sometimes not:

$ kdig +dnssec +nocr @ AAAA
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4489
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1

;; Version: 0; flags: do; UDP size: 1452 B; ext-rcode: NOERROR

;;                 IN      AAAA

;; AUTHORITY SECTION:            86400   IN      SOA 2010023733 86400 7200 604800 86400            86400   IN      RRSIG   SOA 7 2 86400 20190616084157 20190609084157 52787 [omitted]            86400   IN      RRSIG   SOA 7 2 86400 20190615214235 20190608214235 53408 [omitted] 86400     IN      NSEC3   1 0 1 156C7F157BF16543 H5O0RU0059125ARP9F7JQ06HN1FOPP1E NS SOA RRSIG DNSKEY NSEC3PARAM 86400     IN      RRSIG   NSEC3 7 3 86400 20190619082635 20190612082635 53408 [omitted] 86400     IN      RRSIG   NSEC3 7 3 86400 20190619082635 20190612082635 52787 [omitted]

;; Received 862 B
;; Time 2019-06-12 13:25:42 CEST
;; From [email protected](UDP) in 84.6 ms

Consequently, those that aren’t downgraded are prone to returning NODATA for the A query as well, as proven by the DNSSEC records.

I’ve stopped using because I need to do online banking. Quite frankly, all other nameservers appear to work well with their DNS setup, so you might want to reconsider your opinionated view of DNS.

That seems to be an issue with their DNS configuration, not Cloudflare

Based on that I wouldnt be sure whether I called Cloudflare “opinionated”. They seem to follow the standard, the others are the ones not doing so.

Hence I believe your complaint should be better directed to your bank than Cloudflare.

I happen to disagree. All other resolvers (that I have tried) work, Cloudflare doesn’t. So the standard is not where Cloudflare thinks it should be. I’m perfectly fine with Cloudflare pushing their views, that’s their prerogative. Whether they’ll be successful is another question - see Browser Wars for a typical example of “standards” vs. “usability”.

Also, suppose I talk to my bank and they fix their setup (fat chance - but suppose they do). But what about other websites? Do you seriously expect me to check whether it might be Cloudflare’s resolver again every time another website stops working for me?

I need DNS to just work and my resolver to do its utmost to get that IP address for me. The fact is that the IP address is valid and can be used just fine.

Interestingly, Postbank brings a popup “Service not available - check your Internet Connectivity” when I use Cloudflare. So it’s not just a question of not getting that IP address, but also of the bank noticing “suspicious activity” - hence I believe Cloudflare does more than they tell us.

It is, the others simply happen not to implement the standard correctly.

In that case a standard compliant resolver might not be for you.

It is a proposed standard, which means that no implementations must exist and no interoperability testing has been done. This is very, very far away from being a standard.

Thats semantics :wink:

The issue seems to be that your bank is disowning its own records. Thats really an issue with the bank, not Cloudflare.

6 posts were split to a new topic: Problem with and