Problem with and



I have problems with

I only get to the website sometimes.
Not to the banking portal at all.
I only have Oneplus half charged.
I don’t have all problems if I use or Quad9.
It would be great if you could fix the problem.


The root cause is that nameservers return slightly invalid proof of non-existence, which breaks resolvers implementing RFC8198. We’re trying to work with the operator to fix this, as the only workaround is disabling DNSSEC which unfortunately brings its own problems.


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.


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.