Reverse lookup for Google Cloud Load balancer IP returning unexpected hostname

DevOps Google Cloud
#1

I have a question about Google Cloud Load balancer.
Assumptions.
Assume the IP of the load balancer is “1.2.3.4”, and
DNS hostname is “example.com”.
We have had an external vendor perform an ASV scan on the load balancer that we currently have in service for PCIDSS compliance.
The report from the external vendor stated that it failed and the reason for the failure was that the certificate provided by the service could not be verified.
We have given our domain to the load balancer and our SSL certificate is a Google Managed certificate.
Also, the report said that the certificate for this target could not be verified and when I looked at the hostname, I saw a hostname that I did not recognize, “4.3.2.1.bc.googleusercontent.com”.
In fact, when I did a reverse nslookup on the load balancer IP (1.2.3.4), I found that it did indeed return the following

4.3.2.1.in-addr.arpa name = 4.3.2.1.bc.googleusercontent.com.```
Is it possible to do a reverse lookup and have it return "[example.com](http://example.com)"?
If you know, please let me know :bow:

Translated with [www.DeepL.com/Translator](http://www.DeepL.com/Translator) (free version)
#2

I think it depends on the lb type. if you’re assigning a static IP to a TCP LB, you might be able to configure reverse DNS for it.

IIRC, L7 http LBs may be running on shared infrastructure; either way, I don’t think you can configure reverse DNS for it

#3

I don’t think the certificate validation issue is likely due to a reverse lookup failing, though

#4

Might be a better question for or another channel.

If you put the domain name into an SSL checker like https://www.ssllabs.com/ssltest/, do you get any errors / issues?

#5

I could be wrong, but to me, a more likely situation is some kind of trust chain issue where the vendor somehow doesn’t trust the Google managed certificate.

#6

In which case you might consider either telling them to check again, or you could purchase (and use) a commercial certificate instead if you want.

certain things (often sending email, maybe in some corner cases running a DNS server) hinge on having valid reverse DNS setup, though that’s increasingly less true anyway these days, but I’ve never heard of TLS verification failing on a certificate because of a reverse record not matching.

#7

> L7 http LBs may be running on shared infrastructure; either way, I don’t think you can configure reverse DNS for it
I see … :thinking_face:

> If you put the domain name into an SSL checker like https://www.ssllabs.com/ssltest/, do you get any errors / issues?
The SSL verification was judged to be A, and not a single vulnerability was found

> I could be wrong, but to me, a more likely situation is some kind of trust chain issue where the vendor somehow doesn’t trust the Google managed certificate.
>
> in which case you might consider either telling them to check again, or you could purchase (and use) a commercial certificate instead if you want.
>
> certain things (often sending email, maybe in some corner cases running a DNS server) hinge on having valid reverse DNS setup, though that’s increasingly less true anyway these days, but I’ve never heard of TLS verification failing on a certificate because of a reverse record not matching.
I see.
I will ask the ASV scan vendor again!

Thanks so much for the advice.!! :bow:
I will share more if I find out anything else!!!

#8

I agree with, the reverse lookup shouldn’t need to match the forward, since you can have multiple web servers on a single LB. Which one should it return?

#9

> I agree with, the reverse lookup shouldn’t need to match the forward, since you can have multiple web servers on a single LB. Which one should it return?
I see :thinking_face:

The vendor says no because the certificate for “4.3.2.1.bc.googleusercontent.com” cannot be verified. I do not want a reverse lookup to return “4.3.2.1.bc.googleusercontent.com”.

#10

Well, you can try talking to google, as they own the IP, but as I said, you could have www.example.com and api.example.com both served from the same IP, as the forward can point multiple names to a single IP, but the reverse can only point to one name.

#11

You need to read your report more closely and find out what: “The report from the external vendor stated that it failed and the reason for the failure was that the certificate provided by the service could not be verified” means. That doesn’t mention DNS, so you may be chasing the wrong thing.

#12

I see :thinking_face:

Thankyou!!! :bow:

#13

Is it possible to change the PTR record for Google Cloud Load Balancer?

#14

“Well, you can try talking to google, as they own the IP” - but i doubt it will happen.

#15

Google tecnical support is high cost… :sweat: