DNS records: A, AAAA, CNAME and more

For a site to load by domain name instead of a bare IP address, the domain needs correctly configured DNS records. In this article you'll learn what record types exist (A, AAAA, CNAME, MX, TXT, NS), what TTL means, how a domain resolves to your mHost VPS's IP address, which records you actually need to point a site at it — and how to check the result with dig and nslookup.

What you'll need

• A domain registered with any registrar — mHost doesn't sell domains or host DNS zones, so the registrar is always an external one.
• Access to that domain's DNS management panel: either at the registrar, or at a separate DNS provider (Cloudflare, for example) if you've already moved management there.
• The IP address of the mHost VPS the site should point to — find it in VMmanager 6.
• SSH access to the mHost VPS, or just a terminal on your own computer — you'll need it to check records with dig/nslookup.

How a domain turns into an IP address

When someone opens example.com in a browser, a chain of lookups happens:

1. The browser or OS asks a recursive DNS resolver — usually your ISP's resolver, or a public one like 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google).
2. If there's no cached answer, the resolver asks the root nameservers, which point it to the servers for the .com zone (TLD servers).
3. The TLD server returns the addresses of the domain's own authoritative nameservers — the ones listed in its NS records (usually the registrar's or DNS provider's servers).
4. The authoritative server returns the actual record — for example, an A record with your mHost VPS's IP address.
5. The resolver caches the answer for that record's TTL (see below) and returns the IP address to the browser.
6. The browser connects directly to that IP on port 80 or 443 — from here on, the web server on the VPS itself takes over, not DNS.

DNS record types: what handles what

A — IPv4 address

• What it does. Points a domain or subdomain directly at a server's IPv4 address — the most common record for an ordinary site.
• Format. A domain name and an IPv4 address, for example example.com → 185.246.66.12.
• Note. You can set up several A records for the same name pointing at different IPs — the resolver will hand them out in turn (round robin), a simple way to spread load across several servers.

AAAA — IPv6 address

• What it does. The same thing as an A record, just for an IPv6 address.
• Format. A domain name and an IPv6 address, for example example.com → 2001:db8::1.
• Note for mHost VPS. mHost VPS are IPv4-only — they don't have IPv6 addresses, so an AAAA record isn't needed (and doesn't apply) for a site on an mHost VPS. When a name has only an A record, browsers and OSes just connect over IPv4 — that's normal.

CNAME — alias

• What it does. Says "this name is just another name for a different domain": the resolver keeps resolving that other, final name, all the way down to its A or AAAA record.
• Format. A name and another domain name, for example www.example.com → example.com.
• Restriction at the domain root. A CNAME can't be placed at the root of a domain (example.com without www) — under RFC 1034, a node with a CNAME can't have any other records, and the root always requires the mandatory SOA and NS records. That's why the root is configured with A/AAAA, and CNAME is normally used for www or other subdomains.
• Restriction for MX and NS. These records can't point to a name that is itself a CNAME (RFC 1034, RFC 974, RFC 2181) — only to a name with a direct A/AAAA record.

MX — mail servers

• What it does. Specifies which servers accept mail for the domain. Without a correct MX record, mail to you@example.com won't be delivered.
• Format. A priority and a mail server hostname, for example priority 10 and server mail.example.com. The lower the priority number, the higher the priority; you can list several records for redundancy.
• Note. The MX value has to be a name with a regular A/AAAA record — not a CNAME (see above), and not a bare IP address.
• If the domain isn't used for email. You don't need MX records; setting up mail itself is outside this article — this is only about what a website needs.

TXT — arbitrary text

• What it does. Stores arbitrary text meant for other services to read, not people — most often for domain-ownership verification (Google, Cloudflare, and similar services) and for email-authentication rules (SPF, DKIM, DMARC).
• Format. The value is quoted, for example "google-site-verification=abc123def456"; most panels add the quotes automatically if you enter text without them.
• Note. A single name can have several TXT records at once — that's normal, they don't conflict with each other.

NS — nameservers

• What it does. Specifies which servers are authoritative for the domain — the ones the resolver ultimately asks for an answer (step 3 in the section above).
• Format. A domain and a server name, for example example.com → ns1.registrar.example.
• Where you actually set this. In most cases you don't edit NS records inside the DNS zone itself — you set the "nameservers" at your domain registrar's panel, and that setting determines which DNS provider serves the domain at all.

TTL: how long resolvers remember a record

• What it is. TTL (Time To Live) is how many seconds a resolver is allowed to keep an answer cached before asking the authoritative server again. It's set per record.
• Typical values. 300 seconds (5 minutes) — a short TTL, changes take effect almost immediately; 3600 seconds (1 hour) — the common default at many DNS providers; 14400–86400 seconds (4–24 hours) — for stable records that rarely change.
• Before moving to a new server. A day or two ahead of time, lower the TTL of the relevant records to 300 — that way, once you switch the IP address, resolvers worldwide pick up the change quickly instead of holding the old value for the full previous TTL. Once the move is done and everything's stable, you can set the TTL back to normal.
• Why a change isn't visible to everyone right away. The old answer may still be cached at resolvers around the world for the full TTL that was set before your change. That's what's meant by "DNS propagation" — it isn't really a change spreading outward, just old caches gradually expiring.

Which records you actually need to point a site at your server

• Required. An A record at the domain root (example.com) → the mHost VPS's IPv4 address. Without it, the browser can't find the server at all.
• No AAAA record needed. mHost VPS are IPv4-only and don't have an IPv6 address, so there's no AAAA record to create for them.
• For `www.example.com`. Either another A record at the same IP, or a CNAME www → example.com. A CNAME is easier to maintain: if the IP address ever changes, you only need to update the A record at the root.
• NS records. Usually already set up by the registrar by default — no need to touch them unless you're moving the DNS zone to a separate provider.
• MX and TXT. Only needed if this domain also handles mail, or you need to prove domain ownership. Not required for a plain website.

Where to find the VPS's IP address, and where to add the record

1. Open the relevant server's card in VMmanager 6 and check its IP address on the "IP addresses" tab — the same way you would to connect over SSH (see the "VNC console and first connection (SSH/RDP)" article).
2. Open your domain's DNS management panel — either the registrar's panel where you bought the domain, or a separate DNS provider if you've already moved the nameservers there.
3. Add an A record: name @ (or a blank field — that's often how panels denote the domain root) → the IP address from step 1. Repeat for www if needed, following the rule from the section above.

📷 screenshot: the "IP addresses" tab on a server's card in VMmanager 6

A detailed, step-by-step walkthrough specifically for connecting a domain to an mHost VPS is in the "Connecting a domain to your VPS" article. If you're planning to keep the DNS zone and DDoS protection on Cloudflare, see "Domain and VPS through Cloudflare".

Checking with dig and nslookup

Both commands come from the same package.

Ubuntu/Debian:

sudo apt update
sudo apt install -y dnsutils

AlmaLinux/Rocky:

sudo dnf install -y bind-utils

dig

dig is the main DNS troubleshooting tool — it shows not just the result but the technical details of the answer too.

dig example.com
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS

The answer you want is in the ANSWER SECTION: it lists the name, the TTL (in seconds, counting down from the moment of the response), the record type, and the value.

To get just the value, without the extra detail:

dig +short example.com

To ask a specific DNS server directly — say, Cloudflare's public resolver, bypassing your provider's resolver or any local cache:

dig @1.1.1.1 example.com

nslookup

nslookup is available almost everywhere, including Windows — handy when dig isn't.

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com

To ask a specific server directly, give it as the second argument:

nslookup example.com 1.1.1.1

What's next

Once the domain's A record points at the mHost VPS, you can issue a free HTTPS certificate — see the "Free SSL with Let's Encrypt (certbot)" article — or go straight to deploying the site itself, for example with "Nginx: install and your first site". A step-by-step walkthrough for connecting your domain specifically to an mHost VPS is in the "Connecting a domain to your VPS" article.