Hello,
My current hosting provider doesn't have a resolver in their datacenter and recommends me to use 127.0.0.1 as the primary resolver (configured in /etc/resolv.conf).
However, wouldn't this pose a security risk when using WHMCS to automatically provision accounts?
I have tweaked the settings and disabled remote domains; however, this only applies to addon domains and aliases. It doesn't apply to the main domain when initially creating the account.
For example, user A purchases web hosting using WHMCS and chooses to use his existing domain, onto which he has to change later the nameservers on the registrar. He types in domainxyz.com, checks out and pays. WHMCS creates the account and the DNS zone for domainxyz.com is created.
Now user A could have typed in any domain that he didn't own and the zone would still be created. Then, he could in theory modify the records for malicious intent. Afterwards, for example when user B on the same server tries to send an email to [email protected], it will query the local resolver for domainxyz.com, which is contained and cached locally, so the resolver returns back the wrong MX records for domainxyz.com. The email is then sent to the mailbox that was maliciously created in user A's account.
Is this right? Am I missing something? Because this is seems like a huge security risk.
I thought of using public DNS resolvers, such as 8.8.8.8 and 8.8.4.4, but this isn't ideal as most RBLs impose query limits by IP. Since these IPs are shared amongst many many people, the limit is reached quickly and creates other considerable problems, such as spam email getting in or real email getting flagged as spam.
How do major hosting companies avoid or mitigate this security risk?
My current hosting provider doesn't have a resolver in their datacenter and recommends me to use 127.0.0.1 as the primary resolver (configured in /etc/resolv.conf).
However, wouldn't this pose a security risk when using WHMCS to automatically provision accounts?
I have tweaked the settings and disabled remote domains; however, this only applies to addon domains and aliases. It doesn't apply to the main domain when initially creating the account.
For example, user A purchases web hosting using WHMCS and chooses to use his existing domain, onto which he has to change later the nameservers on the registrar. He types in domainxyz.com, checks out and pays. WHMCS creates the account and the DNS zone for domainxyz.com is created.
Now user A could have typed in any domain that he didn't own and the zone would still be created. Then, he could in theory modify the records for malicious intent. Afterwards, for example when user B on the same server tries to send an email to [email protected], it will query the local resolver for domainxyz.com, which is contained and cached locally, so the resolver returns back the wrong MX records for domainxyz.com. The email is then sent to the mailbox that was maliciously created in user A's account.
Is this right? Am I missing something? Because this is seems like a huge security risk.
I thought of using public DNS resolvers, such as 8.8.8.8 and 8.8.4.4, but this isn't ideal as most RBLs impose query limits by IP. Since these IPs are shared amongst many many people, the limit is reached quickly and creates other considerable problems, such as spam email getting in or real email getting flagged as spam.
How do major hosting companies avoid or mitigate this security risk?
