Hi,
HBL; Pakistan’s largest bank’s banking login URL either times out or goes to a non-SSL version when using 1.1.1.1 DNS.
It works OK when using ISP’s DNS or Google DNS.
Please find out the problem.
This is what it shows us when using Cloudflare DNS
This is what it should be showing and what it shows when ISP or other DNS services are used
Looks to be some kind of DNS poisoning going on.
Please fix this, if this is a problem on your end.
www.hblibank.com.pk appears to be a CNAME for cw4pg.x.incapdns.net, for which I got three different addresses
I cant tell which of these addresses is correct, but to me it seems the issue is not with hblibank.com.pk in this case but rather with the configuration of incapdns.net.
One interesting bit, however, is Cloudflare does not seem to recognise the address as CNAME but as a straight A record 
@cscharff, @mnordhoff?
Looks to me HBL bank is using incapsula to protect their website, but CloudFlare is unable to make out that it needs to take users to the correct https://www.hblibank.com.pk/Login - not some non-SSL site.
It was timing out a few weeks ago (when using CF DNS). This is the reason, I’m not switching over to 1.1.1.1 - and sticking to Google DNS.
Don’t know who needs to fix this - Incapsula or CloudFlare.
There are two issues at play as far as I can tell
1. The DNS configuration of incapdns.net doesnt seem to be properly configured
2. Cloudflare for some reason considers the CNAME an A record
Well it resolves fine using Google DNS, OpenDNS and ISP’s own DNS.
This then zeroes it down to a problem with the configuration or lack of a feature detecting such configurations at CloudFlare DNS.
The domain’s nameservers are being genuinely bizarre:
$ dig +norecurse @ns1v.datapipe.net. www.hblibank.com.pk
; <<>> DiG 9.13.5-1+ubuntu16.04.1+deb.sury.org+2-Ubuntu <<>> +dnssec +norecurse @ns1v.datapipe.net. www.hblibank.com.pk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41139
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 0
;; QUESTION SECTION:
;www.hblibank.com.pk. IN A
;; ANSWER SECTION:
www.hblibank.com.pk. 14400 IN CNAME cw4pg.x.incapdns.net.
www.hblibank.com.pk. 14400 IN A 149.126.201.194
;; AUTHORITY SECTION:
hblibank.com.pk. 14400 IN NS ns1v.datapipe.net.
hblibank.com.pk. 14400 IN NS ns2v.datapipe.net.
hblibank.com.pk. 14400 IN NS ns3v.datapipe.net.
hblibank.com.pk. 14400 IN NS ns5v.datapipe.net.
hblibank.com.pk. 14400 IN NS ns7v.datapipe.net.
hblibank.com.pk. 14400 IN NS ns8v.datapipe.net.
;; Query time: 21 msec
;; SERVER: 64.27.64.70#53(64.27.64.70)
;; WHEN: Fri Jan 18 12:44:47 UTC 2019
;; MSG SIZE rcvd: 210
You can’t do that. You can have a CNAME record, or A records, not both.
It seems Knot Resolver returns both records, while most other resolvers tend to filter out the A record.
DNSViz gets confused:
http://dnsviz.net/d/www.hblibank.com.pk/XEHJng/dnssec/
Under the theory of “Garbage In, Garbage Out”, I don’t really blame anyone for handling it in any particular way, and I don’t know what the standards say, but maybe 1.1.1.1 should be aligned with those other resolvers.
This is the problem. It seems only CloudFlare has a problem of not being able to handle it. Others in the business (Google, OpenDNS etc.) can all manage it correctly. And, this makes it even more bizarre.
HBL is the largest bank in Pakistan with millions of customers and over $50 Billion in assets. Anyone using Cloudflare DNS and HBL would now be scratching their heads, and probably moving back to ISP’s DNS or Google DNS.
The largest bank in Pakistan ought to use DNS servers that work right.
And 1.1.1.1 isn’t the only resolver that handles it this way.
As a normal user all I know is that it’s only after using CF DNS; that I’m unable to access the site.
I guess, Google DNS it is for me then.
Ohh, for eff’s sake, I still cant properly read a dig output. I completely missed the bit where it returned two records - I think I thought that output was the resolved CNAME 
Thanks for the clarification, @mnordhoff
That might be true, but that does not change the fact that “Pakistan’s largest bank with millions of customers” cant get their DNS settings right. The issue here is with that bank and not Cloudflare.
CloudFlare DNS can at least look into why other DNS resolvers work, but CF doesn’t.
HBL’s DNS are setup the wrong way, but the problem is not global. CF just wiping its slate clean won’t help those who want to use your DNS service. Passing on the ball around doesn’t win games.
But, then the atmosphere of this thread is condescending, and it would be like beating a dead horse.
The issue with that bank has come up in several previous posts and it’s DNS Query Name Minimisation
See
I have emailed [email protected] - may be they’ll look into it. That was the only email address I could find that would probably hit their tech department without being tossed around the office.
This looks like it’s going to be a perpetual issue with the way CF DNS operates, and that this may never be resolved. But, Justin Justin Bieber says to never say never, so yeah?!
Also tweeted Matthew eastdakota to ask him to have a look to see if anything constructive can be done here.
See the links posted by myself and @Judge. This is an issue with the bank and as every day passes, will become inaccessible as other services move towards new standards and securing DNS. Google just announced it will be doing so soon and suspect OpenDNS won’t be far behind either.
I don’t find it condescending. I find it to be an act of frustration in dealing with someone else’s mistakes. Someone configures something incorrectly, but it works. As others clean up their act, this misconfiguration comes to light and they (not you, but the organization with the misconfiguration) get all bent out of shape because it no longer works.
Same thing happened with 1.1.1.1, which was misappropriated by many hardware vendors. Now people get mad at Cloudflare because they can’t reach 1.1.1.1.