Okay, thanks for the answer.
What is the situation at oneplus.com?
Okay, thanks for the answer.
What is the situation at oneplus.com?
Can you be more specific? The oneplus.com 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 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.
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 18.104.22.168 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.
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? 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.
Sadly the issue related to postbank.de still persists. Any updates on this topic?
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.
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.
It appears that some instances force-downgrade DNSSEC to insecure on postbank.de but not all. From my vantage point (CZ) it mostly appears downgraded but sometimes not:
$ kdig +dnssec +nocr @22.214.171.124 postbank.de AAAA ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 4489 ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 1452 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; postbank.de. IN AAAA ;; AUTHORITY SECTION: postbank.de. 86400 IN SOA ns1.postbank.de. webmaster.postbank.de. 2010023733 86400 7200 604800 86400 postbank.de. 86400 IN RRSIG SOA 7 2 86400 20190616084157 20190609084157 52787 postbank.de. [omitted] postbank.de. 86400 IN RRSIG SOA 7 2 86400 20190615214235 20190608214235 53408 postbank.de. [omitted] h5o0ru0059125arp9f7jq06hn1fopp1d.postbank.de. 86400 IN NSEC3 1 0 1 156C7F157BF16543 H5O0RU0059125ARP9F7JQ06HN1FOPP1E NS SOA RRSIG DNSKEY NSEC3PARAM h5o0ru0059125arp9f7jq06hn1fopp1d.postbank.de. 86400 IN RRSIG NSEC3 7 3 86400 20190619082635 20190612082635 53408 postbank.de. [omitted] h5o0ru0059125arp9f7jq06hn1fopp1d.postbank.de. 86400 IN RRSIG NSEC3 7 3 86400 20190619082635 20190612082635 52787 postbank.de. [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 126.96.36.199 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.
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 secure.cahoot.com and lbi.santander.uk