DNS Records for a VPS Website: A, AAAA, CNAME, and TXT

A domain can serve a website from one company, receive email at another, and use a third company's authoritative DNS. Moving your website to a VPS changes one part of that arrangement. Before editing records, identify which provider actually answers DNS for the domain. An account at your registrar does not necessarily mean the registrar hosts your active DNS zone.

Give each record a specific purpose

An A record associates a hostname with an IPv4 address. An AAAA record provides an IPv6 address. A CNAME points a name at another name, which the resolver then follows. TXT records carry text used by services such as domain ownership verification and email authentication. These functions are separate: adding a verification TXT record does not send browser traffic to your server.

LayerOne does not currently offer IPv6 for VPS interfaces. For a website served directly from a LayerOne VPS, use its assigned IPv4 address. Do not publish an invented AAAA address or copy an old provider's IPv6 record. An external proxy may have its own IPv6 frontend, but that is a separate service with a separate configuration.

Plan the root and www names together

Suppose your website uses example.com and www.example.com. The first can have an A record pointing to the VPS; the second can have a CNAME targeting the first. Your web server must still recognize both names and present valid certificates for whichever names visitors open. DNS aliases do not create HTTP redirects or select the preferred URL shown in a browser.

At a conventional zone apex, a CNAME conflicts with records that must already exist there. Some DNS providers offer flattening or alias features with their own behavior. Confirm the provider's instructions instead of entering a CNAME merely because another control panel used a similar label.

Inspect the records before changing them

Keep a small inventory with hostname, record type, current value, purpose, and owner. Mark the website records you intend to change. Leave MX and email-related TXT records alone unless moving email is explicitly part of the project. Old records are worth investigating, but deleting an unfamiliar entry during a web launch can break a service that has no visible connection to the website.

For an initial check, run dig example.com A and dig www.example.com CNAME. Read the answer, response status, and TTL rather than copying only the displayed address. If answers differ from your control panel, confirm the authoritative nameservers before assuming the new server has a problem.

Test the browser path after DNS

Once the expected address is returned, open both hostnames over HTTPS. Check a real content page, a static asset, and any sign-in flow. A correct A record cannot compensate for the wrong virtual host, an expired certificate, or a firewall blocking the web port. Keep DNS evidence and HTTP evidence separate so each failed check points to the right layer.

The DNS concepts specification explains names, aliases, and authoritative answers. For the server side, start with the LayerOne documentation and our VPS plan selection guide.