Problem with oneplus.com and postbank.de


#1

Hello,

I have problems with
postbank.com
banking.postbank.de/rai/login
and

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


#2

The root cause is that postbank.de 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.


#3

Okay, thanks for the answer.

What is the situation at oneplus.com?


#4

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


#5

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.


#6

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

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


#7

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

$ kdig @ns1.postbank.de www.postbank.de TXT +dnssec | grep NSEC3 | grep -v RRSIG
rlkadlagu4vtnj8o1lef3f48a0q7km28.postbank.de. 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 www.postbank.de:

$ knsec3hash  804B4661061795C4 1 1 www.postbank.de
rlkadlagu4vtnj8o1lef3f48a0q7km28 (salt=804B4661061795C4, hash=1, iterations=1)

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

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

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


#8

Oh, that’s interesting. So the postbank.de 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 leg.br 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.


#9

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


#10

We’ve identified the issue in the DNS product that postbank.de 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.