(How much) Does it matter when local and remote DNS disagree?
Hi All,
I think I'm correct in saying that WHM always creates a local DNS zone file (which may become part of a WHM DNS Cluster, if enabled) for new domains that are added to a WHM server, e.g. as a primary domain, parked domain, or subdomain.
It does this regardless of whether the local nameserver is authoritative for the domain.
related note: when 'Creating a New Account', there's the option to "Use the nameservers specified at the Domain's Registrar. (Ignore locally specified nameservers)"
How much, if at all, does it matter if/when records in the local and remote nameservers are out of sync?
For example, my local (non-authoritative) DNS zone file for a domain has a completely different 'A' record from the 'A' record specified at the remote (authoritative) nameservers, i.e. the nameservers which are specified at the registrar for that domain. This could be the same for any other records, e.g. MX, CNAME, etc.
To my mind, this might be a problem on occasions. For example, if a local WHM hosting server is first asking the local nameserver for information about a domain, instead of the authoritative remote nameserver, doesn't this have the potential to cause misdirected functionality (for want of a better phrase)?
Thx,
Ross
-
You are correct that WHM (Web Host Manager) typically creates local DNS zone files for domains added to a WHM server, regardless of whether the local nameserver is authoritative for the domain. These local DNS zone files store DNS records that are used for the local resolution of domain names on the server itself. However, when it comes to actual DNS resolution for the broader internet, the authoritative nameservers specified at the domain's registrar are the ones responsible for providing the correct DNS information to the world. When you add a domain to WHM, it's possible to specify whether to use the nameservers specified at the domain's registrar or to use locally specified nameservers for the domain. This option determines whether the domain's DNS records will be managed locally on the WHM server or externally at the registrar's DNS infrastructure. If the records in the local and remote (authoritative) nameservers are out of sync, it can indeed lead to potential problems and inconsistencies. If the A records are out of sync, accessing the website using the domain name might lead to inconsistent behavior, with users sometimes being directed to the correct server and other times to the incorrect server. If subdomains are involved, misconfigured DNS records can lead to subdomains not working as intended. In essence, DNS records need to be consistent across authoritative nameservers to ensure proper functionality. 0 -
That's a very #ChatGPT answer! ;) Which therefore begs the question... how best to ensure that, when a remote DNS zone file is authoritative, the local zone file is sync'd with the remove DNS zone file? 0 -
Hello Ross, If the cPanel server is not authoritative, it really does not matter "except" for the MX record. cPanel by default, thinks that it handles mail for the domain. It bases this decision based off of the MX record. If the cPanel server is not authoritative you either have to manually set if mail is local or remote (email routing) or set the MX record correctly if it's set to Automatically Detect. If you don't have that set correctly then mail from the web site (if that's hosting on the cPanel server) may not end getting delivered. Other than that, nothing in the DNS zone matters, as it's not referenced/authorities. 0 -
It doesn't matter at all - if the DNS isn't hosted locally on the cPanel machine, the local record won't be used, so it just sits there. Example - I can make a DNS zone for google.com on my personal server, but it's never going to be used for anything because Google doesn't point to my machine. 0 -
@cPRex - are you politely disagreeing with @ffeingol about their MX record advice? 0 -
If the DNS isn't local, you still may need to adjust things in cPanel >> Email Routing, so not disagreeing with that part at all. 0
Please sign in to leave a comment.
Comments
6 comments