CNAME in Google Cloud DNS
Asked Answered
S

2

6

I have been trying to add the www.mydomain.net alias to mydomain.net. I already have a MX record and NS and SOA records auto-added by Google.

I am getting cnameResourceRecordSetConflict error:

Error code "cnameResourceRecordSetConflict" : The resource record set 'entity.change.additions[0]' is invalid because the DNS name 'mydomain.net.' may have either one CNAME resource record set or resource record sets of other types, but not both.

I understand the advice the error gives me, but how can I have other records then? I need MX and CNAME both on my domain.

Stupor answered 7/2, 2016 at 20:54 Comment(2)
I too have this need yet google cloud DNS docs are out of date and fail to match their admin web console pages ... doc is at cloud.google.com/compute/docs/tutorials/setting-up-dns ... Please let us know how you solved this issueCoel
To accomplish both www.mydomain.net and domain.net pointing to the same record, I added another A record with the DNS name of www.mydomain.net. Seems fairly obvious now that I look back on it :)Stupor
P
9

The problem you're having is an issue with the rules of DNS, which forbid a CNAME record where another record exists.

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

You are trying to create a CNAME for the @ record. The @ record is the origin, so example.com for instance. There are already at least two records at the origin, the SOA (start of authority - basically information about the domain) record, and an NS (name server)

For this reason you can't create a CNAME record for the Origin.

For this reason you can only create an A record for the origin (in order to fulfill a standard A record query - of course you can still create MX etc). However there are some DNS providers that have a special type of record an ANAME if you need a CNAME record at the origin you would need to switch to one of those.

Pinkney answered 7/2, 2016 at 21:55 Comment(4)
So in Cloud DNS I cannot use a CNAME with a top-level domain?Stupor
@Stupor because you should not do thatSmyth
@Smyth When I want to use cloud run with a managed domain, then I have to use it no? I dont see any way around here besides migrating back to my former DNS provider who allowed me to do that.Thallic
@Thallic well the RFC is for something and then each provider decides how to follow (or not) it. The regular way to go is creating an A record for the www domainSmyth
K
2

I've currently had the same issue while configuring my GCP Cloud DNS domain.

The error is very generic and not super clear. However, I found an issue on GitHub at kubernetes-sigs/external-dns with the title "Google-CloudDNS: Unable to write CNAME record when txt registry is enabled." which made it a bit clear what other record could be causing the issue.

Google's DNS error message documentation mention that SOA and NS would be conflicting with CNAME:

cnameResourceRecordSetConflict

The resource record set entity.change.additions[XX] is invalid because the DNS name example.com might have either one CNAME resource record set or resource record sets of other types, but not both.

This error occurs when you create two types of resource record sets, such as both an A record and a CNAME record for the same DNS name. A common cause of this error is trying to create a CNAME record at the zone apex. This is not possible because it would conflict with the required SOA and NS records of the same name.

Recommended action: Pick one or the other.

However, it doesn't feel right as both SOA, and NS records are added automatically when creating a Cloud DNS service.

Looking back to my Cloud DNS, I found two TXT records I added for validation of property with Google, and once I removed the TXT records, I was able to add the CNAME record.

I hope it helps future developers.

Katey answered 13/7, 2021 at 12:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.