Banking Link Going to Fake Website (PK)


#4

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


#5

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.


#6

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.


#7

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.


#8

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.


#9

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.


#10

Can you report the error to the bank?


#11

Already did.


#12

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 :blush:

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.


#13

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.


#14

The issue with that bank has come up in several previous posts and it’s DNS Query Name Minimisation

See

RFC 7816
https://datatracker.ietf.org/doc/rfc7816/


#15

Also: https://ednscomp.isc.org/ednscomp/0af4438459


#16

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?!


#17

Also tweeted Matthew eastdakota to ask him to have a look to see if anything constructive can be done here.


#18

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.


#19

One more resource - sorry to bug! https://dnsflagday.net


#20

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.


#21

The DNS violation isn’t with Incapsula – it’s with the records the bank put in their zone, and with Datapipe’s (Rackspace’s) DNS servers for not rejecting it. Incapsula might know who’s responsible for the bank’s DNS, but they aren’t.


#22

Cloudflare’s resolvers do work, they do not react as you’d expect but that is not because of Cloudflare but because of the bank’s incorrect setup.

I am not sure what you mean by that.

Nobody is wiping his slate, we are talking about protocol definitions and their software components adhering to them. This is neither about passing the ball, but simply about pointing out facts. The DNS configuration is incorrect and the bank needs to fix that.

What exactly did you find condescending?


closed #23

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.