WHM's DNS Functions section is where you edit the DNS records for the domains you host. Most of the time you never open it: zones are created automatically when accounts are created and removed when they are terminated. You come here for exceptions: a client connecting an external mail service, a subdomain pointing somewhere else, a verification record someone needs added today.
The one thing to understand before touching anything: DNS changes are cached across the internet, so a mistake is not instantly reversible. Correcting a bad record takes as long to spread as the bad record did.
The records you will actually edit
A points a name at an IPv4 address. The domain itself and www are A records pointing at your server.
CNAME points a name at another name. Used for subdomains that should follow whatever another host does. A CNAME cannot coexist with other records for the same name, which is why a CNAME on the bare domain causes problems and is best avoided.
MX directs email for the domain. This is the record you will change most, because clients move mail to external providers constantly. MX records have a priority number where lower wins.
TXT holds arbitrary text. In practice: SPF and DKIM records that stop your clients' mail being treated as spam, and verification strings that services ask you to add.
NS names the authoritative nameservers. Set when the zone is created; changing it by hand takes the domain away from your server.
Editing a zone
Open DNS Functions then Edit DNS Zone, choose the domain, and you get the full record list.
Before changing anything, copy the current zone somewhere. A text file on your own machine is enough. If a change breaks mail or the site, having the original in front of you turns a bad afternoon into a two-minute correction.
Make one change, save, and verify before making another. Two changes at once means you cannot tell which one caused a problem.
Time to live, and why it decides everything
Every record carries a TTL: how long other servers may cache it before asking again. A typical value is 14400 seconds, four hours.
That number is how long a change takes to reach everyone, and equally how long a mistake persists. Lowering it does not help at the moment of the change, because the old long value is already cached everywhere.
So for a planned change: lower the TTL to 300 a day in advance, make the change the next day, confirm it, then raise the TTL back. Updates then propagate in five minutes instead of four hours, and if you get it wrong the correction is equally fast.
This costs nothing and it is the single most useful DNS habit there is.
Pointing mail at an external provider
The most common request you will get. A client moves to a hosted mail service and needs their MX records changed.
Delete the existing MX records and add the ones the provider gives you, with the priorities exactly as specified. Then add their SPF record as a TXT record, and their DKIM record if they provide one.
One extra step catches people: the server still thinks it handles mail for that domain, so mail sent from a site on the same server gets delivered locally instead of going out to the external provider. Setting the domain's mail routing to remote in WHM's email settings fixes it, and skipping it produces the confusing case where external mail works but the contact form's messages vanish.
Verify afterwards:
dig MX clientdomain.com
Adding a verification record
Services ask for a TXT record with a specific string. Add it exactly as given, these strings are checked character for character.
Two things go wrong. The name field usually wants the bare domain or a specific subdomain, and putting the string in the wrong name means verification never succeeds. And long strings sometimes need quoting; if WHM rejects a value, wrapping it in quotes is usually the answer.
Adding a subdomain that points elsewhere
To send shop.clientdomain.com to an external platform, add either an A record with the address they give you, or a CNAME pointing at the hostname they specify.
Use whichever they ask for. A CNAME follows their infrastructure if they change addresses, which is why platforms prefer it; an A record is fixed and breaks if they renumber.
Never edit these casually
NS records. Changing them takes the domain away from your server. Only correct here if they are wrong.
The SOA record. The serial number in it tells other servers whether the zone changed. WHM increments it for you; editing it by hand can make changes fail to propagate.
The A record for the domain itself, unless you are deliberately moving the site. This is the record that decides whether the website loads at all.
Verify with a lookup, not a browser
After any change, check with a DNS query rather than by loading the site:
dig clientdomain.com dig MX clientdomain.com dig TXT clientdomain.com
Your browser caches aggressively, your operating system caches, and your network's resolver caches. A site that loads fine for you proves nothing about what everyone else is getting.
Query an external resolver to see what the wider internet has:
dig @8.8.8.8 clientdomain.com
When a zone is missing entirely
If a domain has no zone, the account was created without one or it was removed. Add it through DNS Functions then Add a DNS Zone, then check the records match what the account needs: a freshly created zone points at defaults, not necessarily at the right place.
Note that terminating an account removes its zone. If a client is leaving but keeping the domain, move DNS before terminating, or the domain stops resolving anywhere the moment you press confirm. Terminating client accounts walks through the checklist.
Related
For setting up your own nameservers rather than editing zones, setting up private nameservers in WHM deals with the registrar half that people skip.
For the section layout, the WHM dashboard overview shows which screens belong to you and which need root.
