Question Multiple Plesk servers to the same Slave DNS servers

[klowet]

Hi

I use the 'Slave DNS Manager' extension to push DNS zones to slave DNS servers.

Problem: a customer on pleskserver1 uses zone example.com and the next day another customer on pleskserver2 creates the same zone example.com with his own records.
Then the customer on pleskserver2 can change the DNS records and hijack the domain, because he can divert the traffic to his own IP's.

How can I prevent this?
How do you handle slave DNS?

Thank you

 

[IgorG]

Try to use this option Restricting Users’ Access to Other Users’ DNS Zones

 

[Dave W]

Hi Igor,

Anyway to set this via CLI?

Dave

 

[IgorG]

Hi Igor,

Anyway to set this via CLI?

Dave

Maybe changing value from false to true in misc table for forbid_create_dns_subzone parameter will be enough?
I have not tried, so not sure

 

[mr-wolf]

I have my slave DNS configured outside of Plesk.
Disabled the Plesk extension and just install standard bind.
On the Plesk Master DNS I did use the DNS Slave extension

 

[klowet]

Try to use this option Restricting Users’ Access to Other Users’ DNS Zones

I'm aware of that option. But that only checks if the DNS zone already exists on that server. Not on other Plesk servers which syncs to the same Slave DNS.

I have my slave DNS configured outside of Plesk.
Disabled the Plesk extension and just install standard bind.
On the Plesk Master DNS I did use the DNS Slave extension

Do you use the same Slave DNS server with multiple Plesk Master servers?
What if a customer on pleskserver1 creates the DNS zone example.com and a customer on pleskserver2 creates the same zone example.com? That will conflict on the Slave DNS server.

That way, a customer with bad intentions can "hijack" a domain by creating the same DNS zone with his own records which will be synced to all Slave DNS servers.

 

[mr-wolf]

My clients can't create DNS records with Plesk. Their web/mailserver is not an authority.

BTW.....
About slave DNS servers.
You only need 1 slave, really.
I've seen DNS fail with other ISP's and they sometimes even have more than 1 slaves.
When I investigated their setup I noticed that all servers resided on the same infrastructure.
That's a REAL nono and some TLD's demand that they are behind a different ASN.

 

[klowet]

Your clients manage their DNS zones outside of Plesk? In an external DNS application? Do they create their subdomain records etc. manual in that external app?
So when a new client is created, he has to add all his DNS records manually?

 

[mr-wolf]

I create their DNS records on a separate Plesk server. That way I have all the DNS records on 1 server. This has advantages and disadvantages.

indeed, each domain has to be configured twice. Migration from 1 server to another is much easier as I don't have to change any registry info.

I have,for instance, autoprovisioning for mail and dkim long before Plesk supported it. My DKIM changes keys each week.

For each disadvantage I have been able to find a solution. This week I tackled the Letsencrypt wildcard problem.

 

[klowet]

Okay I get it. Thats a Master > (multi) Slave solution. With (much) manual work for you and clients can't manager their own DNS records. That indeed has its advantages and disadvantages.

My situation is that I have multiple Plesk webservers (Master DNS) and my customers can manager their own DNS zones.

 

[mr-wolf]

I was curious if Bind would check if the slave server would indeed accept a zone update from an master server that's actually not authoritative.
It seems that's indeed true according to isc.org

You could solve this by having master/slave pairs.
A slave that's not authoritative will not be queried for that zone.

BTW, really not that much more work. On initial setup I need to configure the domain twice, which is really only a few clicks. Whenever something's wrong I don't need to check if the customer has messed his DNS up. If I need to change something on DNS I know beforehand to which server I need to go.
My Master/Slave configuration is much simpler.
I have better control over DNS during a migration as the TTL's do not depend on the zone changes of the TLD (the Authoritative DNS-servers do not change).

 

[klowet]

You could solve this by having master/slave pairs.
A slave that's not authoritative will not be queried for that zone.

True, that's a solution. But when you have 20 Plesk webservers, you'll need 20 Slave DNS servers.
A nicer solution would be 1 or 2 Slave DNS servers for all these 20 Plesk webservers.

Any solution, tips or ideas for this, @IgorG ?

 

[mr-wolf]

It does mean I can tick another "advantage box" for my setup

 

[cloudbridge]

Hello all, I have question about nameservers..

I have 4 VPS servers with different name servers ex.:
----------------------------------------------------------------------------------------
MAIN plesk0vps -> ns1.domain.com | ns2.domain.com 2 different ip's.
plesk1vps -> ns1.vps1.domain.com | ns2.vps1.domain.com 2 different ip's.
plesk2vps -> ns1.vps2.domain.com | ns2.vps2.domain.com 2 different ip's.
plesk3vps -> ns1.vps3.domain.com | ns2.vps3.domain.com 2 different ip's.
----------------------------------------------------------------------------------------
How can i use master NS1 NS2 for all vps servers?

 

[websavers]

@klowet Thank you for your legwork on this so far!

We were hoping to implement one or two secondary DNS servers for multiple primary DNS servers and before implementing realized this could be a problem and so found this thread.

The security implications of doing this are pretty bad. I would think that there should be two layers of protection against this:

1. The "Slave DNS Manager" shouldn't push any records to the secondary DNS servers if the primary server does not match one of the name servers set for the domain
2. The secondary servers should refuse to accept records from primary servers that do not match one of the name servers set for the domain

This way if either one fails at least there's another failsafe to protect the security of the domain's DNS. But from what I can tell neither protection exists.

I'm searching through Bind configuration docs to see if there's any such thing. One would think at bare minimum (2) above should be possible, but I haven't found anything yet. @mr-wolf describes this same thing above with:

I was curious if Bind would check if the slave server would indeed accept a zone update from an master server that's actually not authoritative.
It seems that's indeed true according to isc.org

Oddly Plesk seems to say here that using the Slave DNS Manager is a potential workaround to using Centralized DNS with Plesk MultiServer. But given these security implications, I can't see how that's true...

Also good to note: the Slave DNS Manager is on GitHub, so it could be possible to implement (1) above ourselves.

I've created a feature request on uservoice for a workaround to this problem, but it hasn't been approved yet. The request is to add UI elements to explicitly enable domains to be included in the transfer to the slave. That way if any two or more Primary (Plesk) servers are configured to send conflicting records to the Secondary DNS server, it'll only be because an admin explicitly configured it to do so.

 

[klowet]

The "Slave DNS Manager" shouldn't push any records to the secondary DNS servers if the primary server does not match one of the name servers set for the domain

There should be only 1 primary DNS server for each zone.

Slave DNS Manager should do this:

1. Check if the server that pushes a new/change/delete record for a zone, is the primary DNS server for that domain.
   1. Yes? Then the server sending the push is legit.
   2. No? Then there is something wrong and the sync can not happen.

With that method, these situations are covered:

1. On 1 Plesk server: only 1 unique DNS zone can exist.
2. On multiple Plesk servers (which can't see each other domains) with the same secondary name servers: only the primary DNS server of that DNS zone (which is set in the SOA record) can change the zone.

Also good to note: the Slave DNS Manager is on GitHub, so it could be possible to implement (1) above ourselves.

My programming skills are not that good.
But in my opinion, this is such a banal security issue that Plesk itself should resolve.

Regards

 

[ppiitt]

Correct me if I am wrong, which I probably am. But a slave server can be a slave to one or many master servers. If all your plesk servers are master servers, then have the same 2 externally hosted, different asn of course, type bind slave servers. They will serve clients and read all the zones for as many masters as you'd like. However, you will never lookup through your master plesk dns, but always through the slaves.... Would this work? This would make for a quite simple and scalable solution.

Plesk-01
domains 4

Plesk-02
domains 12

Plesk-03
domains 4

ns1.xyz.com
slave with 20 domains

ns2.xyz.com
slave with 20 domains

Updates go through clients own plesk server and get propagated to the slaves?

 

[klowet]

But a slave server can be a slave to one or many master servers. If all your plesk servers are master servers, then have the same 2 externally hosted, different asn of course, type bind slave servers.

You can indeed have a slave DNS for multiple master DNS servers. Problem: when domain.com is configured on Plesk server A and another customer configures domain.com also on Plesk server B ... then both Plesk servers A and B are the master of that domain. The last DNS record update will propagate to the slave DNS server.

There you have the current security issue. When customer on Plesk server B has bad intentions, he can take over the domain on DNS level.
When a visitor queries for a DNS record for example.com on the slave DNS server, he will get the "wrong" feedback.

 

[ppiitt]

You can indeed have a slave DNS for multiple master DNS servers. Problem: when domain.com is configured on Plesk server A and another customer configures domain.com also on Plesk server B ... then both Plesk servers A and B are the master of that domain. The last DNS record update will propagate to the slave DNS server.

There you have the current security issue. When customer on Plesk server B has bad intentions, he can take over the domain on DNS level.
When a visitor queries for a DNS record for example.com on the slave DNS server, he will get the "wrong" feedback.

This makes sense. However, this is can be fixed by reviewing domain additions? In an ecosystem that is not 40k domains of course... Otherwise the management overhead would be staggering.

Do you think this is the only security issue?

 

[klowet]

This makes sense. However, this is can be fixed by reviewing domain additions? In an ecosystem that is not 40k domains of course... Otherwise the management overhead would be staggering.

Do you think this is the only security issue?

Sure, if you manage all domains of all clients on all Plesk web servers manually.
Or run one (or more) slave DNS servers for each Plesk server. But that means that if you run 20 Plesk servers, you'll need (at least) 20 slave DNS servers.

A better solution should be a Plesk upgrade of the Slave DNS Manager extension which takes the primary DNS server in account. As suggested above.

Do you think this is the only security issue?

As far I'm aware, yes.