Violation of the personal data protection law with CWP.

I have noticed, that by using CWP, the law of personal data protection is violated.

I have already reported it to the CWP team, but it seems that it is not urgent, as I was told.

When you create a domain, the SOA record is created with the client's email, which is showing private information and can lead to fines for this.

The CWP team told me that this is because I didn't have an email registered at CWP, which is not correct, it was there from the first moment and creating new packages doesn't solve it either.

It is necessary that you modify the template with which the DNS records are created and that the SOA record is used the one we have indicated in CWP and not the client one.

This is very important for us, since the agency of protection of personal data can give us a fine. While they are fixing this, we are going to cancel all the administration services that we have contracted with CWP, since it is not fair that it has not been corrected yet.

Greetings!

Put in context, this is not unusual.
In WHM/cPanel, you assign an email to receive server alerts. This is then used as the default for SOA DNS records too - a right PITA!
Every time I create a new DNS entry, I go back in and immediately change the email address to the server root account. I discovered this flaw about 20 years ago and nothing has change since! The times that I have forgotten has led to spam, I'm sure. :-(
 

The problem is that if I have the email registered, always in all servers is configured from the beginning.

But CWP ignores it completely.

Are you using the default CWP nameservers and using them as a Registrar?
Use your own and bring back control of records to you.
There are a few freeDNS providers too.

We have created a DNS Cluster for the CWP servers.

Sorry if I don't understand some things, I use a translator and sometimes it's hard to understand

Your English is much better than any of my non-native languages!

This is the default behavior of DNS.  However, you can always edit the template for DNS...

Edit

/usr/local/cwpsrv/htdocs/resources/conf/dns/bind/zones/default.tpl

Change the line in the SOA from:
@    86400        IN      SOA     %ns1%. %dns-email%. (

TO
@    86400        IN      SOA     %ns1%. root@yourserver.com. (

Nice one @rcshaff!
TBH, I didn't delve to find a fix - distracted by too many other things. 
Thanks for the solution.
 

Would be better with a variable, however, something like root@%hostname%

Thanks, I found an easy way to do it, which the CWP team could have told me already on the support ticket...

Here's what I did:

1 - Create a new file in: /usr/local/cwpsrv/htdocs/resources/conf/dns/bind/zones/ , with any name, but ending in .tpl = example.tpl.

2 - Copy the content of the file /usr/local/cwpsrv/htdocs/resources/conf/dns/bind/zones/default.tpl.

3 - Simply modify %dns-email% with the value of our generic email.

4 - Inside the CWP panel --> CWP Settings -> Edit Settings , modify the value: Default DNS Zone template . Here I have selected the file I created.

With this "I think" that it works, I will confirm it when I make several tests.

^ Good response, for the benefit of others.
 
I'll try to remember to have a play with this later and see if root@%hostname% (or similar) will work, as much more generic.

@CoriaWeb
Thanks for prompting this. 
I've opted for the following and it does work; postmaster is a generic requirement according to RFCs and %hostname% with not parse into the DNS configuration. As HOSTNAME is a standard linux ENV, then heck knows why not! (I also tried %host%). Using postmaster is better than root, as many servers will not allow email to be directed to root - which is however beneficial in stopping spam. 

Code: [Select]

cat /usr/local/cwpsrv/htdocs/resources/conf/dns/bind/zones/fixed-soa.tpl
; Generated by CWP
; Zone file for %domain%
$TTL 14400
@    86400        IN      SOA     %ns1%. postmaster@%domain%. (

This is not ideal (from my perspective), as it ties it to a user domain rather than the server FQDN but is a decent compromise.
An alternative might be postmaster@%ns1% but that's not great either, IMHO.