Good morning!
My use case
- Host static marketing website at
www.<my-vercel-domain>.com
. - Host React app at
<subdomain1>.<my-vercel-domain>.com
. - Point
api.<my-vercel-domain>.com
to an AWS EC2 Elastic Load Balancer. - (In turn, the ELB routes incoming internet traffic to a Django app deployed on ECS/Fargate in a VPC private subnet.)
Context
- To enable an HTTPS listener for the ELB, I created an SSL Certificate from AWS Certificate Manager for
api.<my-vercel-domain>.com
. - To validate this certificate, per DNS validation - AWS Certificate Manager (at the bottom: “If you are not using Route 53 as your DNS provider…”), I added a CNAME record in Vercel DNS.
- The NAME value was
_<UUID>.api.<my-vercel-domain>.com
. - The VALUE value was that specified by ACM, ending in
acm-validations.aws.
.
- The NAME value was
- (I had also added a CAA record, which is still present.
- NAME =
api
- VALUE =
0 issue "amazon.com"
.)
- NAME =
- Certificate validation was successful.
Issue
- I am now trying to add a CNAME record to Vercel DNS to point
api.<my-vercel-domain>.com
to the ELB.- Attempted NAME value is
api
. - Attempted VALUE value is the ELB’s DNS name.
- Attempted NAME value is
- I receive this error:
Existing record (“rec_c625ccf17bfb13236fca932d”) conflict with attempted “api” CNAME “
<elb-dns>
.” creation. CNAME record cannot be created if any other record exists with the same name.
- To attempt to resolve, I deleted the SSL validation CNAME record, since this was also a CNAME record with NAME =
api
. My hypothesis is that the existence of this record caused the “conflict” error message. (My understanding is that this old CNAME is no longer needed since the certificate validation is completed.) - I used dnschecker.org to verify that the deletion of the old CNAME record has propagated.
- However, when I reattempt the new CNAME record, I receive the same error message.
- The Vercel DNS UI does not allow inspection of the internal DNS UUID specified in the error message, as far as I know. So I don’t have a way to figure out which record is responsible for this conflict.
- Is it possible this is a cache or “ghost” record issue?
Thank you!