Setting up new accounts with existing non-local DNS auth servers

[jndawson]

We are setting up a new cPanel server to accommodate a large increase in web hosting customers. We are also incorporating the DNS capability into our existing server farm (5 DNS servers with a dozen different registered DNS hostnames). Many of the new accounts already have auth DNS on name servers we don't control for their existing domains, and are perfectly happy with that; in some cases the domains are on auth name servers (non-cPanel) that we manage under different auth records so we can make those changes.

When we set up a new account on the cPanel box and indicate that there is an existing name server to use, a zone record and an entry in named.conf is created anyway. This obviously conflicts with the existing non-local zone record. The problem is compounded when the customer wants to add a subdomain and can't figure out why it doesn't work.

Without manually editing the named.conf file (which we're doing now), how can we set up accounts that have existing zone records someplace else without creating local zone records and named.conf entries?

 

[cPanelMichael]

When we set up a new account on the cPanel box and indicate that there is an existing name server to use, a zone record and an entry in named.conf is created anyway. This obviously conflicts with the existing non-local zone record. The problem is compounded when the customer wants to add a subdomain and can't figure out why it doesn't work.

Hello

Could you elaborate on this? How does this conflict with the existing zone entries if the DNS is handled remotely?

Thank you.

 

[jndawson]

Michael,

I'm sure I don't need to discuss the issues with authoritative vs non-authoritative name servers.

What I'm talking about specifically is a new customer with a pre-existing domain (with auth records somewhere else) that we set up on our cpanel server for webhosting purposes. Our cpanel box is an auth nameserver for almost 2000 zones, but not the new customer's domain. A zone record and named.conf entry is created on our cpanel box, whether we want it or not. Because we pay attention, the zone is set up with the domain's existing name servers.

We manually edit the named.conf file to remove the entry because we're not auth for the domain. Sometime later, the customer decides to add a sub-domain, which writes to the zone record, which we're not announcing (oh, oops, an entry appeared in the named.conf record, even though we don't want it in there). The customer's new subdomain isn't seen by anybody. The customer is now upset.

Multiply by a few hundred customers that we will be moving over from another company in a couple of weeks.

So, my original question: Without manually editing the named.conf file (which we're doing now), how can we set up accounts that have existing zone records someplace else without creating local zone records and named.conf entries?

thanks,

 

[cPanelMichael]

If I understand correctly, the key issue here is that your users might add subdomains and not realize that they need to manually add the "A" records at the DNS host of the domain name. Is that accurate? If so, there are no native features to prevent or warn users of doing this, but it sounds like a good idea for a feature request:

Submit A Feature Request

Thank you.

 

[jndawson]

If I understand correctly, the key issue here is that your users might add subdomains and not realize that they need to manually add the "A" records at the DNS host of the domain name. Is that accurate?

Michael,

Yes, that's one of the issues for the customer. The issue for us is we don't want to announce a non-auth zone but, the default creates the zone record and adds an entry to named.conf. Our workaround is to set up different packages for customers with dns/zone/subdomain, etc. capability and another without.

It would be nice if the cPanel interface to BIND was a bit more robust. I'll come up with a list and open a feature request.

thanks,