DNS Record Types
A domain's DNS zone is a set of resource records, each responsible for its own job. Every record has a type, a name, a value, and a TTL (how long resolvers may cache it). Here are the main types you'll work with most when setting up a site and mail:
- A — maps the domain to an IPv4 server address
- AAAA — maps the domain to an IPv6 server address
- CNAME — an alias pointing to another name instead of an IP
- MX — specifies the mail server and delivery priority
- TXT — text data: SPF, DKIM, domain ownership verification
- NS — specifies which name servers serve the zone
- SRV — specifies a service, protocol, port, and host, used for example by SIP and XMPP
Pointing the Domain to Hosting
Create an A record at your registrar:
@ A [your hosting IP]
www A [your hosting IP]Or set the ZevsHost nameservers — then the zone is managed by the hosting panel rather than the registrar's panel:
ns1.zevshost.net
ns2.zevshost.netThe difference matters: if delegation points to the hosting NS, all records are edited in the ZevsHost panel. If delegation is still pointed at the registrar's NS, edits need to be made there instead — changes in the hosting panel simply won't have any effect in that case.
Configuring MX for Mail
@ MX 10 mail.yourdomain.com
mail A [hosting IP]The number 10 is the priority: the lower it is, the higher the priority of that server. Adding a backup server with priority 20 means mail will only route there when the primary is unreachable. There's another standard restriction worth knowing: a CNAME record cannot be created at the domain apex (@) — RFC 1034 requires an SOA record to exist at the zone apex, and a CNAME at the same name can't coexist with it. That's why the bare domain always uses A/AAAA, never a CNAME to an external host.
Common DNS Configuration Errors
| Symptom | Cause | Fix |
|---|---|---|
| dig returns SERVFAIL for a CNAME name | Another record (A, TXT, etc.) exists at the same name as the CNAME — RFC 1034 forbids that combination | Remove every other record at that name, keep only the CNAME |
| dig returns NXDOMAIN | A typo in the record name, or the record was created in the wrong zone | Check the exact spelling of the name and the zone selected in the panel |
| Browser shows DNS_PROBE_FINISHED_NXDOMAIN | NS delegation hasn't propagated yet, or the A record is missing | Check dig NS at the registrar and wait out the TTL |
| Mail bounces with Host or domain name not found | The MX record is missing or points to a name that doesn't exist | Create the MX record and a matching A record for the destination host |
Recommended TTL Values
TTL sets how many seconds resolvers are allowed to keep serving a cached answer without asking your name server again. Too high a TTL slows down how fast changes take effect; too low increases load on your DNS servers with no real benefit. The TTL value used is the one that was current at the moment of the query: you can't lower the TTL retroactively for an answer that's already cached, so lowering it is something you plan ahead of time, not in the middle of an incident.
| Record type | TTL in normal operation | When to lower it |
|---|---|---|
| A / AAAA | 3600–14400 seconds | down to 300 seconds 24–48 hours before an IP change |
| MX | 3600–86400 seconds | before switching mail providers |
| TXT (SPF, DKIM, verification) | 3600 seconds | while actively debugging the record |
| NS (zone delegation) | 86400 seconds or higher | almost never — changing NS already takes time at the registry level |
When DNS Changes Don't Take Effect
- The domain is delegated to third-party NS (Cloudflare, another host) — records in the ZevsHost panel are ignored; edit where delegation actually points
- A CNAME was created at a name that already has an MX or TXT record — a record conflict, the zone won't pass validation on save
- The client's resolver cached the old value — the TTL simply hasn't expired yet, see checking DNS propagation
- NS and an A record were changed at the same time — it becomes hard to tell which part hasn't updated yet
A separate case is split-horizon DNS, where the same domain resolves differently inside a local network than it does outside, through different DNS servers. If a site loads from the office but not from outside (or vice versa), check which resolver the problem machine is actually querying first, rather than the zone on the hosting side.
Verifying the Result
# Check the A record
dig yourdomain.com A +short
# Check the MX record
dig yourdomain.com MX +short
# Check via a specific DNS server, bypassing the local cache
dig @8.8.8.8 yourdomain.com A +shortIf the answer is empty and the domain is definitely delegated to ZevsHost, the general principle behind name resolution is covered in the article how DNS works, including the order in which root and authoritative servers are queried.
Frequently asked questions
How long should I wait if a domain doesn't resolve right after changing a DNS record?
Domain records stay cached by resolvers for as long as the TTL value allows, so a change doesn't reach every visitor right away. Some providers refresh their cache sooner, others later, until the old TTL expires. If the answer hasn't changed after a while, check the record through an external resolver instead of trusting a local cache.
Do I need a separate AAAA record if hosting only runs on IPv4?
A separate AAAA record only matters when the server actually answers on an IPv6 address. If hosting runs purely over IPv4, skipping AAAA is fine and won't affect availability for ordinary visitors. Creating an AAAA record with a random or outdated address is worse than leaving it out, since some browsers try IPv6 first and then hit a connection error.
Can I set up multiple MX records for a backup mail server?
Yes, the mail standard explicitly allows multiple MX records with different priority values. The primary server gets the lower priority number, the backup gets a higher one, and the mail system only turns to the backup server when the primary one is unreachable. This setup improves delivery reliability without any extra configuration on the sender's side.
How can I tell whether a domain's DNS zone is managed through the hosting panel or the registrar's panel?
This comes down to the domain's NS records: if they point to the hosting provider's name servers, the zone is managed through the hosting panel, and edits made in the registrar's panel have no effect. If the NS records still belong to the registrar, the opposite is true, and edits need to be made there instead.