A Record Conflict

My domain is: producks.xyz

My web server is (include version): Amazon Linux 2

The operating system my web server runs on is (include version): Centos(7)

My hosting provider, if applicable, is: Namecheap

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): certbot 1.3.0

Hi there,

I have filled out the above but I am not actually stuck with creating my certificate - I have managed to do all that correctly. I generated my certificate using certbot and I am using nginx.

The issue I am facing is that in order to verify my domain, I needed to add an A record in my DNS in order to prove I owned it. This A record pointed @ and the www sub domain to my EC2 Public IP, which all worked fine in terms of validation.

The problem is, my front end server (which is hosted on Vercel/Zeit Now) is now saying there is a DNS conflict - which makes sense, because there is now an A record pointing the domain root (@) andwww to my backend server IP.

My thought to fix this is carry out the steps I did with certbot previously, but to a subdomain, like api.domain.com. However is there a way I can have this set up so that the backends URL is domain.com and not a subdomain?

Hi @alexr89

which verification? Checking your domain both versions have the same ip - https://check-your-website.server-daten.de/?q=producks.xyz

Host Type IP-Address is auth. ∑ Queries ∑ Timeout
producks.xyz A 34.243.82.44 Dublin/Leinster/Ireland (IE) - Amazon Technologies Inc. Hostname: ec2-34-243-82-44.eu-west-1.compute.amazonaws.com yes 1 0
AAAA yes
www.producks.xyz A 34.243.82.44 Dublin/Leinster/Ireland (IE) - Amazon Technologies Inc. Hostname: ec2-34-243-82-44.eu-west-1.compute.amazonaws.com yes 1 0
AAAA yes

May be a configuration problem of that system. May be it’s impossible to use that front end with the domain pointing to another ip address.

Hi @JuergenAuer - thanks for the swift reply.

I was using HTTP-01 challenge type for verification - I set two A records (@ and www) which both were pointing at my backend server IP.

This worked, but as I explained when I visit my domain, that @ record directs me to my backend server IP. This obviously isn’t right, I need clients to be directed to my frontend server on Zeit/Vercel (hence why Zeit/Vercel said there was an A record conflict I think).

I seem to have fixed this by revoking my old certificate using certbox, updating my nginx config to now have the server as api.producks.xyz (rather than producks.xyz), and generating a new certificate using certbox for api.producks.xyz - this means that the A record is no longer pointing at my root domain, so I can visit producks.xyz fine again.

I was just wondering why this was/if it has to be this way?

Edit: im now running into CORS issues because my server domain is api.producks.xyz and my frontend is producks.xyz, which means the origins are different. I seem to be back to where I was before, wondering how I am supposed to add an A record with my backend servers IP without that causing traffic to be directed to my backend server - it seems to be impossible.

If you have two different servers with different functions and different ip addresses, you should have two different domain names.

api is a good solution. Your first setup was wrong.

That’s an expected problem, but that’s something you can fix.

Hi @JuergenAuer,

Thanks for getting back to me so quickly, really appreciate it.

So am I correct in saying that I have to use a sub domain if I want to verify my domain via an A record because I am using different servers for my frontend and backend?

I dont see how I can verify the root domain (@) via an A record, because in order to do this I must put my backend servers IP as the value of that record - which as I mentioned means all traffic will be directed to my backend server.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.