IssueTracker

Hi,
coming from amazon EC2 where this feature is already possible. So would like to have this feature aswell to migrate my EC2 instance to GCE.

Hi Sami,
  Might you be able to share your use case.

Thanks,

Paul

If he is not answering, my use case would be that I want to create a mailslave for my primary Mailserver. As of security reasons, the most Servers doesnt accept mails from other hosts (since I use SPF) so that feature would be nice for me to completely switch from AWS.

We would also like this feature for the reason given above and because we use forward/reverse DNS checks on various connections to check they fall within our domain - yes we also run dnssec signed zones!

I own three personal domains, and I would like to allocate each of them a separate static IP address, and have that address reverse resolve to the domain. It would also be handy if I could have a separate IP address for my main domain's mail subdomain.

It's all strictly low bandwidth, I barely scrape a few gigabytes per month, as it is already on EC2.

I would also like to be able to host a couple of IRC bots, which I know is begging for trouble, but they only idle in a handful of low traffic IRC channels, and they've never been attacked in the decade that I've already been running them on the same server.

[Comment deleted]

Paul;

Use case: Backup or primary MX servers and NS providers for a domain name. If remember correctly even Gmail will bounce or at the very least treat as spam any messages sent through a mailserver that doesn't at least have RDNS setup correctly.

If you have SPF setup, which everyone should, it would flat out be rejected.

I'm somewhat disappointed that a "use case" would even need to be explained given the "use case" being presented for cloud offerings targeting these types of distributed highly available cost-effective devices.

Perhaps being in the industry almost 20 years has made me jaded though.

I'm still watching this issue, but it no longer applies to my use case, as I have moved all of my domain sites to App Engine instances, and moved my email to an Apps for Business account, which is now acting as the owning account for all of the Cloud projects.

The only problem I have with this new setup, as I see it, is that it will cost me roughly $10 per month just for the minimal Cloud SQL profile powering my blog. It's somewhat cheaper than the $27 or so monthly I was paying Amazon for a single EC2 instance, but I get way less.

It would cost me considerably more per month to run a Cloud Compute instance, with way less replication, but that VPS would have the ability to host a wide range of services, such as game servers. I'll think about it in the future. And I won't make the mistake of spinning up an image of RHEL, that costs nearly twice as much as the baseline Compute instance.

Quite shocking in fact that this doesn't exist already. Postfix on GCE is basically useless without PTR support. Please implement soon.

I'd also like to have this feature implemented

[Comment deleted]

Paul

Echoing what has already been said:

The webapps running on my server need to email the app users, and any messages sent through a mailserver that doesn't at least have RDNS setup correctly are more likely to be rejected.

I'm somewhat disappointed that a "use case" would even need to be explained given the "use case" being presented for cloud offerings targeting these types of distributed highly available cost-effective devices.

It is not possible send emails from GCE machines anyway because outgoing mail ports are blocked.

For sending emails you can use SendGrid. They have special plan for GCE users: you can send 25000 emails in month for free. I have used it few months and have been very satisfied.

See more here: https://developers.google.com/compute/docs/sending-mail

Still, I would like to have configurable PTR records for static IP:s. There are many cases where right configured reverse records are important. As servers usually interoperates with each other (more every day), it is easier identify servers from log files. It is actually quite hard to find where requests come if you cannot resolve hostname from IP address.

br,
Sami Niemi

Having the PTR of a static address map to the expected domain is a sign of clue for both, the cloud user and cloud provider.

Applications such as Email expose the PTRs in email headers. For other applications such as DNS servers, VPNs, etc. having a matching PTR provides added assurance on the management of the resources.

I hope this gets implemented, as currently this prevents me from considering Google for some workloads I'm hosting elsewhere.

Best regards

-lem

Also would like to echo my support for this feature; please make PTR available for config as part of static IP allocations.

Other use cases;
1) backup bind server

2) Application who's license check is bound to domain name resolution. (Yes, this happens. Application calls home, home checks if originating IP resolve's to license owner's domain name, if not reject, if so supply timed key.)

3) 3rd party resources which use reverse IP lookups for domain/server ownership verification. Similar to the license check above.

4) Applications which use variation of SSL certificates for non-http ports and non-http services but still require reverse IP lookups to function. (Several game servers/voip services and business apps do this. Appengine is not a suitable platform for this.)

Seems like google is ignoring this ...

I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.

Best Regards,
Josh Moyer
Google Cloud Platform Support

I will have to add more weight on this one. The fact that I can not set the PTR for the static IP's is really preventing me from fully migrating to GCE.

And the reason is very similar to #16. We have an application that verifies the PTR against the domain name to make sure the connection is valid. Every hosting company we use allowed for it (including EC2) and put us on a stand still when we started to deploy on GCE.

The same applies to reverse proxies and other services where the source IP should be verified as coming from a specific application or company.

Same here - I also need to have working reverse DNS for static IP assignments.

I'm also more than a little surprised that the first response was 'what is the use case'. That's just a silly reaction to an obviously important request.

I would also like to be able to set PTR records.

Thats a shame, without proper PTR it's impossible to use GCE as DNS or mail servers.I'm currently going to disable 6 servers just for this reason.

Already have any solutions? We are also waiting for the solution to give continuity in our migration.

Well it's been a year and two days. It's not a priority for Google. I still have one server outside of GCE because of this. Be nice if Google can acknowledge that someone has this on their radar.

[Comment deleted]

I'll add my voice to this request.  It would be a good addition and would make both Google Cloud and it's user base better netizens.  I consider PTR records to be a basic minimum networking feature despite the fact that a lot of network admins ignore them for all of the reasons mentioned by other users.

Agreed. PTR is essential for me too.

I'm not sure about this, but is it not documented here (PTR) ?:

https://cloud.google.com/dns/what-is-cloud-dns

Well I'll be damned. It is... And sure enough, a PTR dropdown exists in the new web manager in the developer console.

I'm not sure this is what we want.

If you want to delegate your reverse zones to Google DNS, then this will work for you.

However the reverse zones that apply for the mapping of the VMs IP addresses to names are probably off-limits and need to be managed by Google.

It just created an in-addr.arpa zone in Cloud DNS for one of my GCE addresses. Waiting for propagation to see if it works. I agree though, this should be independent of Cloud DNS (assuming that this would even work). For me it would be fine since I am using Google for DNS. I'll keep you all updated.

Well this did not work (not that I was really expecting it to). This makes since unless they had some override from Cloud DNS and again if it did, not helpful for those who don't use Google DNS. Sucks, I was hoping to have this solved tonight. Guess we will continue to play the waiting game.

Ideally, this setting should be where GCE networking is managed.

Totally agree, this sucks. What could be so hard in allowing people to add a PTR?

Come on Google, you can do better than this!

After the eNom DNS chaos yesterday, I'd like to have all lights green on the Pingdom DNS check report, rDNS failing on the load balancer IP address is the only warning left.

So we can't add Reserve PTR for our static ip addresses? Please confirm.

as of my last test, no. We can not.

[Comment deleted]

I need this functionality too -- to be able to manage the PTR records associated with the external/public IP addresses of my GCE VMs.

This is a show-stopper for me.  That is, if we cannot adjust the PTR entry for a google cloud compute node's static IP address, I won't be able to use Google's cloud services for my VMs.  (I've been testing various providers' offerings)

I realize the last comment was only 4 days ago, but I'm curious if there has been any additional consideration given to this, by Google?

I want reverse dns too.

Trying GCE for the first time today. Pleasantly surprised so far, except for this issue.

Setting up a PTR record is one of the most basic things a sysadmin does when setting up a new server.  I was surprised to see this feature missing.

Josh or Paul, can you give us all some idea of whether this feature has been acknowledged as necessary for some customers, whether it is being worked on, and what the timeline is for users to expect to be able to use it?

Thanks.
   - Tim.

bump

bump

[Comment deleted]

While this is not a show stopper for me as I'm using SengGrid as my mail relay per Google's recommendation, I sure would like to follow best practices and have a reverse DNS lookup resolve to my (sub)domain rather than a Google Cloud name.

I've tried using Google's Cloud DNS service to setup the reverse lookup, however Cloud DNS. However the Cloud DNS name servers are not authoritative for the IP address I care about so this won't work.

Has anyone figured out a solution?

Cheers, Jason

This is important for security purposes. Please allow this to go through as a high priority.

I am 30 mins into Google Cloud, a complete newbie. What was my project to test the service? To set up a secondary/backup MX server. I cannot do this without a PTR record back to my own domain matching the DNS A record I've set up for this Google Cloud server.

[Comment deleted]

@beardsell.com

You can't use compute engine instances as mail relays, all the ports are blocked. Best to use Mailgrid or something like that

https://cloud.google.com/compute/docs/tutorials/sending-mail/

Mailgun or Sendgrid.  Mailgun is easier and faster to set up.  Sendgrid takes days to go through their provisioning approval process.. only to get denied and have to go back and forth with them on your intention to finally get an approval.  SendGrid is also more expensive.  Go with Mailgun I say!

for WHM/cPanel installs on GCE, google "GCE exim mailgun" settings/configuration.

I hate to bump issues but this would be helpful to me too.

bump!

Would also like to echo support for adding rDNS entires for static IPs under a GCE account.  I don't think the risk of keeping stale rDNS referenced in future allocations of a static address is an insurmountable concern. As part of the static IP reclaim workflow, GCP can always replace rDNS entries with those from the bc.googleusercontent.com subdomain when any individual static IP is released from an account.  From the console UI, the rDNS should be configurable from the same menu where static IPs are requested.  Even a post-hoc edit from the cloud console would be fine, it need not be configurable from the UI during a spot allocation as part of the VM creation, for example.

hi,

this have to be a HIGH priority issue. We need to be able to setup reverse dns on GCE

GCE does a lot of things right - several key components of our SaaS product were moved to GCE about 6 months ago and we have seen improved productivity, performance, and reliability all while reducing costs. That being said, I find it odd that certain features such as this go completely ignored. This thread has been here since 2013 - why is this not being addressed? We should be able to have rDNS records match our domains even if it means a contractual commitment of some sort to an IP address. Allowing proper rDNS and also adding IPv6 would leave me with little to complain about. AWS and even providers like Digital Ocean offer both... and the lack of attention this issue has received over 2 years later leads me to believe rDNS will simply never happen at this point. IPv6 support obviously will... and it's insane it isn't already available... but that's not the topic here. The handful of customers they lose due to a lack of proper rDNS means a lot less than the extra effort required to implement it. It's ridiculous... but I guess I understand why they're not doing it. I just wish they would provide some honest updates on this stuff.

Same here, I want this too.

I joined and moved few of my client to Google cloud, with high hopes. getting more and more limitation like this.

Unidata LDM (http://www.unidata.ucar.edu/software/ldm/) restricts upstream and downstream communication by IP and hostname. The hostname verification in this software uses the IP's rDNS and by determining if the hostname has a matching A record.

Without the ability to set an rDNS record, I cannot migrate my GCE instances to a new region without already having an IP reserved in that region and notifying my (~20) upstream providers to add the IP to their ACL beforehand. rDNS would allow me to change an A record and almost instantly receive access to my upstream provider's data, as a hostname entry in their ACL would be validated by the rDNS entry of the IP and the A record in my DNS.

Please consider adding this for the sake of supporting applications which truly take advantage of the cloud.

I was super excited to use GCE... then I learned that I cannot create PTR records. WOW... Time to move on :(

I can't believe this is still not done. This is possible on AWS and many other second-tier providers. Google must not be serious about its cloud offering competitiveness.

I want to host a mail server on GCE, We need to be able to setup reverse dns on GCE.
Kindly advise, How can I do rDNS?

For comment #61;
IIRC you can't host smtp/pop/imap in GCE...
https://cloud.google.com/compute/docs/tutorials/sending-mail/

In response to Comment #62.

You CAN host a SMTP/POP/IMAP on a GCE instance; I am doing it.

What you CANNOT do is send mail out via port 25 and instead have to pass it to a relay service like Sendgrid, which is what I do after configuring my server to connect to Sendgrid's servers for relay.

Our project was whitelisted to be able to send mail from our GCE instances. But without PTR records, not sure whats going to become of our server.

hmm, no ptr put a halt on migrating anything for me
8+(

any happy end to this topic ?
I've just created a cpanel server and found that it seems there's no way to declare the reverse DNS (ARPA record).

Any fresh new ?
Without that there will be a lot of emails rejected.

Thanks

PTR-records is not work? WTF?! It's very bad!

Ill update my comment by saying that we have successfully been running a mail server on Google without a PTR record for the past 3 months. Its possible that Google IP addresses are well known across the globe so a PTR may not be required. But "your mileage may vary".

i spoke to soon. Our mail server public IP has been flagged by a blacklist agency. I opened a ticket with Google support so hopefully they can help, fingers crossed.

Wondering if there is a way to forward mail traffic to a "non-google" IP address that has a PTR record so all mail appears to come from that IP.

Part of the issue here is that Google goes out of their way to deter sending mail directly from their servers. I believe that an added layer to this is not offering the option for PTR. As most use-cases for PTR records involve sending mail, they kill 2 birds with one stone by continuing to not offer it: makes things slightly less complicated for them to operate/support while also making it a poor option for sending email. We relay email to a 3rd party service now just to simplify things... but for other reasons we have been forced to move most of our services off Google Cloud Platform due to their limitations. It's a great starter service... but they focus too much on niche APIs and beta services that come and go. There is a reason they continue to lose ground to the big 2 and I'm starting to think they are not focused on growing marketshare nearly as much as they are getting free beta testers for their actual products / potential products. PTR is day one stuff - you cannot keep core DNS components outside of reach and be taken seriously once things get beyond a certain level.

If you aren't here primarily for Google's APIs, you might want to consider an alternative. Pricing is quite competitive everywhere and I often found myself with my hands tied behind my back with Google Compute Engine. It's fine for what it is... but after watching it for years I've learned not to expect them to ever listen to their customers - they have their agenda and they stick to it. For Google, Google Compute Engine is just a small side project that they leverage for research and development on their actual business.

There's no need for Google to further deter from sending mails, because it isn't possible from a VM in the first place. That's a moot point. Using your postfix installation with SendGrid as outgoing relay works fine.

The use case for PTR is properly *receiving* emails (postfix, dovecot), among other cases already mentioned. Being able to keep your corporate email history on a private server is a strong plus, compared to some SaaS solution where confidentiality and security might be questionable. Also, the generic googleusercontent domain is somewhat revealing and confusing, because it's unrelated to one's business and makes it look like a quick & dirty hack in the cloud.

Google, please. Consider PTR records for your static IP addresses. It's really about time now!

[Comment deleted]

Hey Google! You really need to consider reverse DNS and PTR records for fixed IP servers, as it is important for e-mail servers!

Unsubscribe

Best regards,

*Brock Courneya*
Founder & Chief Executive Officer

T: 1.800.971.1731 x 6327 | F: 1.800.720.2291

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. XNS Technology
Group Inc. is not responsible for errors or omissions in this message and
denies any responsibility for any damage arising from the use of e-mail.
Any opinion and other statement contained in this message and any
attachment are solely those of the author and do not necessarily represent
those of the company.

On Sun, Nov 27, 2016 at 2:23 PM, <google-compute-engine@googlecode.com>
wrote:

The most obvious reason for PTR is a line like this appearing in all emails dispatched via SendGrid:

Received: from mail.mydomain.com (4.3.2.1.bc.googleusercontent.com [1.2.3.4])

This most likely adds to the spam score, because the domains don't match. Worst even, it may suggest a dynamic DSL address or dialup. Google customers can't currently do anything about it, so despite going the suggested SendGrid way, a certain percentage of transactional emails never reach their receivers.

Google, please. This is serious. It's about time.

sure there is something Google users can do.... migrate to AWS. We are currently underway in testing a mail server hosting with AWS in a temporary hybrid cloud with Google and AWS. If things go well, we may move everything over, just because of this PTR issue. Amazon allows for whitelisting of static IP address to be used as mail servers and allows PTR records.

I am not continuing with a Google solution for the time being and this issue has played a significant part in the decision.

Surprisingly, Kerberos has not been mentioned yet so I'll mention it.

Kerberos requires reverse DNS to operate out of the box otherwise you can get any number of errors, all of which are hard to diagnose (as Kerberos is in general, given it's methodology for trying not to give would-be-attackers any information). This can be worked around using the 'rdns = false' parameter in configs, however, it may be considered to weaken security (for certain types of attacks) by doing so. Simply having reverse DNS work as expected means less "special case" provising for Kerberos servcies (Heimdal/MIT KDC and Microsoft's AD).

PTR records may now be created using new alpha functionality. To sign up to test, please submit the form here: https://goo.gl/efG1sK

Finally! Opted in already!

This is so funny. I was just thinking about checking on this today and saw the email. Opted in for both my active projects.

Just submitted the form, hope to hear something soon.

Anyone hear anything back?

bump !

Has anyone heard anything about the PTR issue an the alpha?  I just requested access and all it said was "your response has been recorded" or something like that. I'm deploying a service that needs PTR records and before I started it never occurred to me that they are not available.

I've heard back and am using the PTR records. It appears they can be applied to both ephemeral and static IPs because the PTR itself is assigned to an instance after you have verified ownership of the domain through Google Webmasters.

You'll just have to run the `gcloud` commands provided once you're added to the alpha.

The ISNIC (.is registry) requires PTR records for nameservers, so please support PTR records for static IPs

https://www.isnic.is/en/host/req
https://www.isnic.is/en/host/test

I would like this as well. The fact that my domain is with GoDaddy, but my email is with GSuite. For some reason SpamCannibal has put us on their blacklist because we lack a PTR record.

How long to get reply (positive or negative) after apply?

Configuring your PTR record is now in beta. If you would like to try it out, please see the following:
https://cloud.google.com/compute/docs/instances/create-ptr-record

The beta seems to only apply to instances. What about load balancers? I'd like to create a PTR for an IP that is served by a load balancer.

The beta only supports instances right now. I have LB support on our roadmap, but I don't have a timeframe I can share right now.

Wow. Only 4 years to acknowledge and implement. What a shame...

Not only that but it's still not available for the load balancers so really doesn't do a bunch of us anyways.

Hi, is there any update on this regarding adding PTR records for static Load Balancer IPs?

It has been 4 years, 6 months and 29 days since it was noted in this case that AWS has this feature.  If this will not be implemented would you please just let us know why so we can understand the struggles with this issue as being in the dark on this is hard and does not win any favors.

FYI, this is effectively already implemented for IPv4 and IPv6.

*However* for IPv6 it's only for the first IPv6 address assigned to a VM, and not for the entirety of the rest of the /104.

Perhaps there should be just a way to delegate reverse DNS, for example to an automatic cloud dns zone setup for the entire subnet assigned to a VM's network?