More flexible DNS control

Webcart

Verified User
Joined
Jan 14, 2004
Messages
387
Hello,

A vast majority of our customers prefer to keep DNS hosting within their domain registrars (NetSol, eNom etc) and just change A/MX records to point to our server(s).

Since DA automatically creates DNS records for each domain, the local DNS resolver might get out of sync with the actual data at the authorative nameservers.

We would love to see a new user account option that allows marking domain as 'external' and skiping DNS records creation (similar to "local mail server" option).

From the DirectAdmin user perspective, it could be done by extending "DNS Control" option to support ON/OFF/external values and then making sure that no DNS records are created for the external DNS control.

Thank you.
 
DA needs to keep a DNS zone file; that's how it decides if a file is held on the server or not.

Personally I don't like the idea of creating zone files with differing views, and I don't see that as resolving the issue; if the local nameserver is used for resolution (it shouldn't be but plenty are set up for that) then it had better have the correct records.

How about creating slave zone, then? But that wouldn't always work, as a properly configured master shouldn't allow just anyone to get a zone transfer; it might result in a lot of errors in the logs of both servers.

Of course you can delete the zone file manually; I'm not sure what that would do if you/someone accidentally tried to create another account with the same domain name.

There may not be an easy answer to this.

Jeff
 
DA needs to keep a DNS zone file; that's how it decides if a file is held on the server or not.
I am not sure why you think that "DA needs to keep a DNS zone file".
If you don't want to use your DA server as authoritative nameserver for a domain, there is no need to create a zone file for this domain.

Personally I don't like the idea of creating zone files with differing views, and I don't see that as resolving the issue;

It's not about creating different "views", it's about maintaining zone files only for domains which use DA server for DNS hosting.

In addition to ensuring accurate DNS info at the local nameserver, it will also provide important DNS info for 3rd party support systems accessing account profiles via API.
 
So has this ever been solved?

Deleting the zone would be a solution, but it's no-go because such solution has problems if you try creating subdomains or try doing any other DNS-related task on the domain in question (errors, etc.).

I've googled around and I only see lots of questions about this, but no real answers.

Btw same situation here - most clients want to keep DNS control on their own servers and i really dislike having inacurate/incorrect zone files that are marked as authoritative on my server.
 
Yeah now I see that this feat is constantly requested since like... 2006. So most probably this won't get solved for another 4 to 5 years...
 
Hello,

I am not sure why you think that "DA needs to keep a DNS zone file".
The answer is how DA decides if a domain exists on the box or not to prevent Users from adding it twice. DA uses the named.conf as the index to decide this.

It's a logical place to use as the index because it covers both local zone and any manually added zones for external places... as well as zones created by the dns clustering tools. In all cases, you don't want your clients creating a domain where it's zone overwrites a zone that's already there (hosted locally or externally).

So the issue isn't with creating the option to disable DNS.. that's fairly easy (plus a lot of SKIN modifications.. tedious, but not hard).
The issue is to keep a correct/valid index that satisfies all of the above.

I may have a simple solution where... the named.conf is still checked, but if the zone is not there, it then does a 2nd check in /etc/virtual/domainowners. If the domain doesn't exist in the named.conf but does exist in the domainowners file, then we'd still say the domain exists. I'm trying to think of a case where that wouldn't be a valid statement, but nothing is coming to mind. If that's true, it would cover all cases for the indexing, and allow you do not have a domain in the named.conf.

Comments welcome.

John
 
Hello,

The answer is how DA decides if a domain exists on the box or not to prevent Users from adding it twice. DA uses the named.conf as the index to decide this.

It's a logical place to use as the index because it covers both local zone and any manually added zones for external places... as well as zones created by the dns clustering tools. In all cases, you don't want your clients creating a domain where it's zone overwrites a zone that's already there (hosted locally or externally).
It might be a logical place to check for zone existance (to avoid zone overwrites), but it shouldn't be used as an index. Think about it this way: if you worry about manually added zones, why don't you worry about manually deleted zones? Right now, there is essentially no DA support for such domains.

Besides, from a hosting management perspective, I would rather manage it all on a hosting package level (that is, rather than manually adding zones, I would create an account with a special hosting package which provides DNS hosting only). It's easier to manage, backup and keep a note of this way... It's also easier to link to a 3rd party support or billing software.

I think the only way someone would want to add zones manually is the lack of "DNS hosting only" package (no mails, no website, no FTP and etc), with "no mails" being the most problematic part here. But this is a topic for another feature request :)

So the issue isn't with creating the option to disable DNS.. that's fairly easy (plus a lot of SKIN modifications.. tedious, but not hard).
The issue is to keep a correct/valid index that satisfies all of the above.

I may have a simple solution where... the named.conf is still checked, but if the zone is not there, it then does a 2nd check in /etc/virtual/domainowners. If the domain doesn't exist in the named.conf but does exist in the domainowners file, then we'd still say the domain exists. I'm trying to think of a case where that wouldn't be a valid statement, but nothing is coming to mind. If that's true, it would cover all cases for the indexing, and allow you do not have a domain in the named.conf.

Comments welcome.

John

Do you add domain pointers to /etc/virtual/domainowners? If yes, it should work well indeed.

Thank you.
 
The answer is how DA decides if a domain exists on the box or not to prevent Users from adding it twice. DA uses the named.conf as the index to decide this.

I've googled a lot and already found this answer why such a at a first glance trivially solvable problem is not yet solved.


I may have a simple solution where... the named.conf is still checked, but if the zone is not there, it then does a 2nd check in /etc/virtual/domainowners. If the domain doesn't exist in the named.conf but does exist in the domainowners file, then we'd still say the domain exists.

Seems fine to me, though I'm not very competent on multi-server DA configurations so I'm not sure how would this work in such setups.

I really think this should get solved in such a manner that it would be possible to have only valid zonefiles and a DNS query to localhost would always return correct values, even though localhost is not used for DNS resolution.

I think most admins like to keep things clean and tidy in their configs and "extra" zonefiles on a non-authoritative server (which of course are false or have to be synced manually) just for DA to know which domains it is currently hosting to my opinion is a bad idea. And also as someone has mentioned before - it's against the RFC.

And it's also worth to mention, that lots of clients like to keep their DNS service at the domain providers service, and even I myself like to keep most critical zones on other name servers.

Another problem is that most default installations include 127.0.0.1 to /etc/resolv.conf so it's not good either. At least there should be a DA level check-warning to this.

All in all I think it's a bad idea to make a non-authoritative DNS server think it's actually authoritative for one or another zone.
 
Back
Top