Auto-detection and deletion or suspension of non-authoritative DNS zone files
Although I'm very happy to be educated otherwise, I believe that non-authoritative zone files on a WHM server (or in a cluster) have no value, and should not exist.
By being allowed to exist and effectively be "active", the problems they cause are, for example:
1. WHM admins working with them, thinking they're authoritative, when they're not.
2. The auto-detection feature of WHM of the correct mail exchanger (local or remote) can be compromised by incorrect information in a non-authoritative DNS zone file.If they do/must exist, then either they should either auto-inherit the values of the authoritative zone files, or they should be disabled and clearly marked as such, i.e. so that it's very obvious to WHM admins which zone files are non-authoritative.
This issue discussed here: http://forums.cpanel.net/f5/what-purpose-if-any-do-non-authoritative-dns-zone-files-serve-424671.html
Thanks for your consideration.
This is a very complex feature that requires many assumptions. cPanel & WHM would be making decisions based on sure assumptions.
How do we objectively know which zones to delete? Have you considered domain expirations and other temporary that are less permanent?
This is a very complex feature that requires many assumptions. cPanel & WHM would be making decisions based on sure assumptions.
How do we objectively know which zones to delete? Have you considered domain expirations and other temporary that are less permanent?
This is a very complex feature that requires many assumptions. cPanel & WHM would be making decisions based on sure assumptions.
How do we objectively know which zones to delete? Have you considered domain expirations and other temporary that are less permanent?
This is a very complex feature that requires many assumptions. cPanel & WHM would be making decisions based on sure assumptions.
How do we objectively know which zones to delete? Have you considered domain expirations and other temporary that are less permanent?
Perhaps "delete" is too strong a word... perhaps "flagged for admin review" might be a better one?
Perhaps "delete" is too strong a word... perhaps "flagged for admin review" might be a better one?
Thanks for your comments. Yes, I agree, "delete" is too strong a word :-)
Over the past 14 years of using cPanel/WHM I've seen multiple occasions where non-authoritative DNS zone files have caused confusion/mistakes for server admins (arguably more so the less experienced ones) and indeed for WHM itself.
So if all that WHM did was to more strongly and automatically highlight/flag non-authoritative DNS zone files, then this would be a significant improvement IMHO.
Thanks for your comments. Yes, I agree, "delete" is too strong a word :-)
Over the past 14 years of using cPanel/WHM I've seen multiple occasions where non-authoritative DNS zone files have caused confusion/mistakes for server admins (arguably more so the less experienced ones) and indeed for WHM itself.
So if all that WHM did was to more strongly and automatically highlight/flag non-authoritative DNS zone files, then this would be a significant improvement IMHO.
Yes - this is a necessary function (I mean the flagging for admin review - not auto-deleting).
I recently became involved in cleaning about 2000 domain zones because a since-released WHM/cPanel admin decided to create his own auth server names and changed all of the domains to use those 'name servers'. Note that the cPanel box itself was not an auth server, so he set up a complex series of scripts to move zone files all over to actual name servers and his 'master' name servers. Needless to say, the result is a real fuster cluck. It took more than a month to untangle the mess trying to minimize impact on customers' services (several dozen are very very large customers) and return some semblance of sanity.
We're still fixing zone records.
Yes - this is a necessary function (I mean the flagging for admin review - not auto-deleting).
I recently became involved in cleaning about 2000 domain zones because a since-released WHM/cPanel admin decided to create his own auth server names and changed all of the domains to use those 'name servers'. Note that the cPanel box itself was not an auth server, so he set up a complex series of scripts to move zone files all over to actual name servers and his 'master' name servers. Needless to say, the result is a real fuster cluck. It took more than a month to untangle the mess trying to minimize impact on customers' services (several dozen are very very large customers) and return some semblance of sanity.
We're still fixing zone records.
While I wasn't sure when I first read this, I rearly like the idea of having a flag to say the dns record is not authoritave. I believe this should only be informative and shoud be done in such a was as to not slow down page load (like using ajax for example to run the check asynchronously.
While I wasn't sure when I first read this, I rearly like the idea of having a flag to say the dns record is not authoritave. I believe this should only be informative and shoud be done in such a was as to not slow down page load (like using ajax for example to run the check asynchronously.
I've just had another example of a person in my company editing a DNS zone file on one of our servers, assuming that the zone file was authoritative for the domain, and wondering why the changes they were making weren't having any effect.
IMHO it should be a trivial feature for WHM to introduce. Each time someone chooses a zone file to edit, WHM does a lookup to an external service to query which are the authoritative nameservers for the domain name in question. If the answer comes back that the authoritative nameservers are NOT the nameservers on the zone being edited, then to report this with a big red warning sign to alert the user of this fact, i.e. that making changes here will NOT likely have any effect (except maybe locally to that server).
I'm sure this would reduce a lot of frustration for people who forget to check this!
Thanks,
Ross.
I've just had another example of a person in my company editing a DNS zone file on one of our servers, assuming that the zone file was authoritative for the domain, and wondering why the changes they were making weren't having any effect.
IMHO it should be a trivial feature for WHM to introduce. Each time someone chooses a zone file to edit, WHM does a lookup to an external service to query which are the authoritative nameservers for the domain name in question. If the answer comes back that the authoritative nameservers are NOT the nameservers on the zone being edited, then to report this with a big red warning sign to alert the user of this fact, i.e. that making changes here will NOT likely have any effect (except maybe locally to that server).
I'm sure this would reduce a lot of frustration for people who forget to check this!
Thanks,
Ross.
I believe this is absolutely necessary. Here is a thread highlighting more clearly the kind of issues that can arise.
https://forums.cpanel.net/threads/repair-mailbox-permissions-remotedomains-localdomains-issue.605663/
Every host out there must have some amount of customers who use external DNS services. This issue would arise for every one of them, would it not?
So it isn't just that an unsuspecting admin may edit the zone thinking it is authoritative, but in actual practice there may be issues with no intervention on the part of the hosting cPanel server / admin. Examples are in the linked thread.
I believe this is absolutely necessary. Here is a thread highlighting more clearly the kind of issues that can arise.
https://forums.cpanel.net/threads/repair-mailbox-permissions-remotedomains-localdomains-issue.605663/
Every host out there must have some amount of customers who use external DNS services. This issue would arise for every one of them, would it not?
So it isn't just that an unsuspecting admin may edit the zone thinking it is authoritative, but in actual practice there may be issues with no intervention on the part of the hosting cPanel server / admin. Examples are in the linked thread.
Replies have been locked on this page!