Adding 'fake' domains / security issue

A customer uses the following setup:

3 external dns servers setup to slave domains from a single unmanaged directadmin server.
In his /etc/resolv.conf he specifies the 3 his own external dns servers.

He uses his server to sell hostingaccounts to his own customers. His customers have hosting packages where they can add a number of domeins.

When a customer adds a domein, the zone will propagate to his dns servers.

Now user A has a website 'websiteA.com' doing curl call's to 'websiteB.com' which is hosted somewhere else.

Then there is user B who adds 'websiteB.com' to his account. The zone is created and propagates to the dns slaves. This only makes this websiteB.com resolvable by using his DNS slaves. This is no problem for external user because the fake 'websiteB.com' can not change name servers. But... as his own server does reference his own dns slaves, all calls to websiteB.com originating from his own server will end up at the fake website.

This could be solved by having the real websiteB.com only using SSL but websiteB.com is not managed by this customer. Another solution, though a little less secure is NOT using his own dns slaves in his /etc/resolv.conf. But this again is only part of the solution because it slows things down a lot when registering or transferring websites (you'll have to wait for a nameserver change before you can test the site using your own dns) and a dns call to the local nameserver for websiteB.com might cache the dns response anyway.

Any ideas on how to prevent these issues?

Hello,

Tried https://www.directadmin.com/features.php?id=752 ?


p.s. Why do you consider NOT using his own dns slaves in his /etc/resolv.conf less secure?

zEitEr said:

Hello,

Tried https://www.directadmin.com/features.php?id=752 ?


p.s. Why do you consider NOT using his own dns slaves in his /etc/resolv.conf less secure?

Click to expand...

No, didn't try that because there are a zillion domains a user isn't 'allowed' to use and it would cost a lifetime managing this.
If he wouldn't use his OWN slave server for resolving, the resolve would have to via an external path, eventually ending up on 'trusted' nameservers. (e.g. the .com zone that has registered the real nameservers for the websiteB.com) and not via the untrusted own nameservers.

Actually you should understand there are no many things you can do, and actually if a domain does not use HTTPS and DNSSEC you have no other options but quit using the nameservers as dns resolvers for calls from localnet.

Probably other forum members can add anything else...

Yeah, that's why I posted it here. I've been thinking about this and see no other way to prevent this. We don't control other domains, nor do WE (as the hostingcompany) control the way users build their software/website. But in regard to the general data protection regulation in Europe we need to provide a secure environment.
Another option might be to prevent outgoing access to non ssl http, mail, ftp, whatever ports... not sure yet what to expect when doing something like that serverwide tho...

Edit: I think the only solution this customer has, is to separate (best practices by the way) his dns cache and resolver. Only after checking differences with our own setup and his I remembered again why this separation is so important