2

We're using Google App Engine for a service of our app.

We've set up the service on a custom sub-domain (eg service.myapp.com), while doing so, Google prompted us to Update your DNS records to enable security

What's confusing me about this is:

  1. We've already set up the CNAME to point to the app on the subdomain
  2. The record's that google is suggesting would seem to modify our main domain (myapp.com) rather than the subdomain (service.myapp.com)

Here's what google suggested:

Type    Data                    Alias
A       216.239.32.21   
A       216.239.34.21   
A       216.239.36.21   
A       216.239.38.21   
AAAA    2001:4860:4802:32::15   
AAAA    2001:4860:4802:34::15   
AAAA    2001:4860:4802:36::15   
AAAA    2001:4860:4802:38::15   
CNAME   ghs.googlehosted.com    service

The last one seems to make sense, but all the rest I would think would break our app by pointing the main domain to google (where it is NOT hosted), no?

Update

I did try adding the A and AAAA records for host, but it was disallowed because the CNAME is already set up (We're using Amazon Route 53):

RRSet of type A with DNS name communications.raisely.io. is not permitted because a conflicting RRSet of type CNAME with the same DNS name already exists in zone myapp.com.

The host is working with SSL and without the A or AAAA records (just the CNAME), so it seems like these aren't necessary.

ChrisJ
  • 295
  • 1
  • 10

3 Answers3

1

216.239.32.21 is a google owned IP. My guess is they are just trying to help people that know little about operations.

People might setup www.domain.com and forget about domain.com Since its bad practice (old school dns talk) to have a CNAME for your root entry that's why its a A record to an IP

I wouldn't worry about it.

The AAAA are for IPv6

Mike
  • 22,310
  • 7
  • 56
  • 79
0

To answer the question in the title, I think "enable security" is in the context of the options on the previous screen "ENABLE MANAGED SECURITY" i.e. free auto-provisioning of TLS certificates when you add a custom domain. Step three of adding the domain (modifying your DNS provider) is just the last thing you have to do before you have finished and can connect to the domain over HTTPS. As the cert is bound to the domain, you can't just use the IP address to connect. I guess this is what they mean?

Regarding the A records seeming to be for the primary domain, this is just poorly presented in the Google control panel. They say:

"Add the following DNS records with your domain registrar for myapp.com:"

but they mean you need to add A records for the subdomain - I think it's just "too obvious to mention" that you are adding that subdomain. They are missing a column in the table, there should be a "name" field for the A records, like "alias" for the CNAME. This is usually just the sub-domain ie. "service".

I also get an error that the CNAME and A records conflict - using Wordpress DNS. It seems again this is poorly presented, and should say add either of these approaches? I have found you can either add the 8 A records (four for IPv4 and four for IPv6) OR use the CNAME. I felt the CNAME took a bit longer to work, a few minutes perhaps.

The other confusing thing I found, as you mentioned in a comment, is you only have to verify the TLD when adding a sub-domain but it's not clear in the first dropdown of domains which says "Select the domain that you want to use" which isn't true. Also I seemed to have some non-TLDs/subdomains in that list somehow which makes it seem like you should verify a subdomain... but when I tried to "verify a new domain" using the subdomain I was adding it never turned up in the list.

I've written lots of notes to future me when doing this, but there always seems to be a new problem next time. Like now, the validation is done via "Search Console" and it adds a new "property" and starts emailing you about SEO. Strange that some things change, but the various problems you raised in 2018 are still left as confusing 5 years on.

scipilot
  • 201
  • 2
  • 7
0

When adding a custom domain you can set it to the subdomain (service.myapp.com) instead of the naked domain(myapp.com), which means that:

  • The verification would be done against the subdomain service.myapp.com.
  • A and AAAA will be placed under service.myapp.com too.
  • CNAME www.service.myapp.com will be added.

This way there shouldn't be any conflict with the current provider for myapp.com.

A.Queue
  • 166
  • 5