(Solved) DNS Zones not created on slave servers

[Taz-Matt]

Hi,

I am setting up slave DNS servers using bind 9.8 on CentOS 6. I have followed the procedure here successfully:

http://download1.parallels.com/Ples...extensions-guide/index.htm?fileName=73349.htm

The problem is that even if I see something like the following in named.run on the slave server (which implies the rndc connection worked):

received control channel command 'addzone xxxxxxxx.com { type slave; file "xxxxxxxx.com"; masters { x.x.x.x; }; };'
received control channel command 'refresh xxxxxxxx.com'
received control channel command 'addzone xxxxxxxx.com { type slave; file "xxxxxxxx.com"; masters { x.x.x.x; }; };'

I still cannot query any entries for that zone from the slave DNS server:

$ dig @y.y.y.y xxxxxxxx.com
; <<>> DiG 9.8.3-P1 <<>> @y.y.y.y xxxxxxxx.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29975
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;xxxxxxxx.com. IN A

;; AUTHORITY SECTION:
com. 900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1437356587 1800 900 604800 86400

;; Query time: 141 msec
;; SERVER: y.y.y.y#53(y.y.y.y)
;; WHEN: Sun Jul 19 21:43:15 2015
;; MSG SIZE rcvd: 104

I also do not see any zone files created anywhere on the slave server.

I have been searching for a few hours now on many forums including this one, without finding the solution. What am I missing? Can anyone give a hand?

Thanks!
Matt.

 

[Chris1]

Hi Matt,

What is the owner/group of /var/named? I believe it needs to be named:named.

Kind regards,
Chris

 

[Taz-Matt]

Hi Chris,

I knew it would be a small detail like that. I usually never mess with permissions of services and I wonder why the default permissions on /var/named are root:named (750). Well, thanks to you, I have changed it from root to named and it works. Thanks a lot!

Matt.

 

[Chris1]

No worries at all I ran into the same problem myself. I started using the slave DNS manager a few months back.

One problem I've found is that zones don't get deleted when you delete a domain from Plesk. The extension should get updated to support this.

 

[trialotto]

@Chris1,

Apart from the question why you should need the slave DNS servers (only meaningful if you are an acknowledged registrar of domains), you stated

One problem I've found is that zones don't get deleted when you delete a domain from Plesk. The extension should get updated to support this.

and this functionality should be supported from the Plesk server, running the master nameserver.

However, the functionality only becomes active, if (and only if)

a) at the time of domain creation (in Plesk), the option "Use DNS settings of a remote name server but keep them in Plesk as well" is checked (do not be confused by the term "remote name server", this option allows additional, remote nameservers and the relation between nameservers, i.e. slave versus master, is a completely different story. Also note that this option makes the slave DNS server extension a little bit questionable and/or obsolete),

b) the DNS service is "on" (by default, it is off, you should manually adjust that),

c) all other parameters and settings are 100% perfect (and that is more difficult than one often imagines).

To be honest, it is adviceable (read: a more solid and reliable solution) to manage DNS at the control panel of the registrar and use Plesk standard "recommended settings" for DNS.

Try to test (i.e. mimick) a failure of the external nameservers by simply shutting them down and you will know what I mean by "adviceable to use recommended settings".

Kind regards.....

 

[Taz-Matt]

Hi Chris,

I do not have this problem. Maybe you get this behaviour when you delete a domain that was created before you implemented the slave DNS server.

Matt.

 

[Taz-Matt]

@Chris1

I see what you mean! When I delete a domain, I do not receive any answers for this zone anymore from the slave servers, but the zone file is still there, the server just ignores it since it received a delzone request. But I tried creating the same domain in Plesk and it "reactivated" the zone on the slave servers and updated it. So basically, it does not delete the zone file but it still works like a charm. Redundancy tests were also conclusive so everything is good now, let's bring some customers on Plesk.

Thanks for your help!
Matt.

 

[Chris1]

@Taz-Matt

Yeah exactly. It deletes the configuration out of /var/named/3bf305731dd26307.nzf for that particular domain but doesn't remove actual zone file itself. Whilst it doesn't really cause a problem, it would be cleaner to remove the zone file itself when the slave server receives the delzone command.

 

[trialotto]

@Chris1 and @Taz-Matt,

You (both) buy and/or your customers register a domain at a registrar, with the nameservers by default provided by the registrar.

In essence, the master/slave setup of DNS servers is only useful if you have functionality at the registrar´s control panel to use the option "use other nameservers".

This also requires that you have full access to all domain settings of all your customers, i.e. you should be able to reroute all nameserver entries to your master/slave setup.

Naturally, it often is the case that you do not have access AND EVEN IF you do, you are exchanging the solid and reliable nameservers of the registrar for your master/slave setup.

And, as you have argumented already by stating a flaw of the extension (i.e. zones are not cleaned up properly), this master/slave setup is not reliable.

Consider a failure in the primary nameserver (master), resulting in redirection to the secondary nameserver (slave), with improper and not-up-to-date records: the expected endresult is that specific zones, that are not cleaned up properly, will or can cause a undesired disfunctioning of the DNS zones.

In short, not smart.

In conclusion, it is not "good practice" to use software (in this case, an extension), that is KNOWN to be buggy and, moreover, it is not "good practice" to re-invent the proverbial wheel, by setting up a master/slave configuration on your own servers, if some external nameservers (those of the registrar) are already existing and are reliable and stable.

Finally, as a small note, the whole master/slave setup does not actually have any function, if the nameservers for all your domains and those of your customers are not actually pointing to the master/slave servers.

This latter note has to be made, I have often encountered that Plesk admins are using master/slave configurations, without pointing domains to them. A bit strange, but it happens.

In my humble opinion, focus on your customers and associated customer service, not on configuration and maintenance of master/slave setups.

Kind regards....

 

[Chris1]

Hi trialotto,

I find managing DNS zones via the Plesk interface very important for both parties for ease of use. In my experience, registrar DNS zone management is buggy and the user interfaces are very poor and confusing for customers.

Every domain purchased through us will not be given the "default" nameservers set by the registrar but will be automatically set to our private ns1/ns2's.

Why people would set up master/slave setups without pointing domains to them is beyond me.

I have thought about managing DNS through WHMCS from the registrar but I still find DNS management through Plesk is more user friendly.

If a customer purchases a domain elsewhere, it is a lot easier just to provide them with two nameservers to point to rather than giving them a full DNS zone they have to replicate at their domain registrars DNS.

Also what about if you need to mass migrate hundreds of domains to a new server/IP. Huge pita if you need to coordinate all clients to alter a-records, would be all done for them automatically if their DNS was handled by our ns1/ns2..

Another small yet positive reason is for branding purposes.

We do however have our primary business domains DNS through Amazon Route53.

Kind regards,
Chris

 

[trialotto]

@Chris1,

I can imagine this kind of response, not all registrars/hosting providers have an user-friendly UI and/or proper functioning nameservers.

However, it is, simply stated, a pain-in-the-*** to (properly) setup nameservers, one should change to a proper registrar and maintain your customers DNS yourselves.

I am not familiar with the registrar you are using at this moment, but you seem to state that it is not the most ideal registrar for DNS purposes.

I will send you a mail (i.e. start a personal conversation), to give you a tip for using a registrar that can be ideal for you (and that can deliver domain registration at cost!)

That way, you would be able to save some time on nameserver maintenance and costs of the servers themselves AND save some money on purchasing/registering domains.

By the way, some thoughts with respect to your remarks.

I have thought about managing DNS through WHMCS from the registrar but I still find DNS management through Plesk is more user friendly.

WHMCS is not an option, it is terrible and (very) often confines you to purchase domains at a (relatively) very high price.

Note that the above also applies to purchasing domains via Plesk panel, so make sure those "buttons" are not activated (for customers).

If a customer purchases a domain elsewhere, it is a lot easier just to provide them with two nameservers to point to rather than giving them a full DNS zone they have to replicate at their domain registrars DNS.

This is somewhat strange, since this method would use the customer´s registrar nameservers only to forward traffic to your nameservers, which will "distribute" traffic on their turn.

In a sense, that makes one of the two sets of nameservers obsolete.

Furthermore, it would often result in DNS related issues, since

- customers that are not able to manage DNS, are (often) also not able to create proper redirections (in this case: rerouting to your nameservers)
- failure in the registrars nameservers will result in traffic not reaching your nameservers, with the customer displeased with you (not the registrar)

and these are only some (but not all) practical matters.

Also what about if you need to mass migrate hundreds of domains to a new server/IP. Huge pita if you need to coordinate all clients to alter a-records, would be all done for them automatically if their DNS was handled by our ns1/ns2..

Plesk is not really suited for that, whilst all "normal" registrars are able to do that, by templates or by script.

Furthermore, this does not often happen and even when it happens your setup is not optimal: if you have to migrate hundreds of domains, good practice implies that a lot domains should be spread across multiple small servers or VPS, in order to reduce the number and extent of problems, if one server fails. Also, a failover server should be present, implying that migration can be tackled, without any downtime AND enough time to adjust DNS settings.

The above is not complete, but it is a start of a summary of all things you should consider when hosting for customers.

Another small yet positive reason is for branding purposes.

Nice thinking, but this does not require a Plesk-based master/slave setup. Instead, one should consider a Plesk master or slave, combined with the registrars´ nameservers.

We do however have our primary business domains DNS through Amazon Route53.

Both Amazon and Azure (Microsoft Cloud) offer very, very reliable DNS services, that can be managed with various methods (API etc.).

Azure has an option to whitelabel, if I can recall it correctly.

However, I would like to emphasize that every DNS service in the cloud has its costs and disadvantages.

In general, a purchase and registering of domains at a reliable registrar should be preferred, with a break-even point of 5.000 plus domains for migrating to own nameservers and/or nameservers (i.e. DNS services) in the cloud.

One particular advantage of Azure DNS service has to be mentioned though: you can use a specific IP, virtual or fixed, that will reroute traffic to your servers.

The Azure IP is "persistent", in the sense that migration of (hosted) domains to a new server and/or server IP will not require much effort.

The Azure DNS service is also "persistent" when desiring to use server clusters, for load-balancing and/or failover.

But then again, the cost will exceed the advantage, if you do not have a minimum amount of (hosted and registered) domains.

Kind regards....

PS I will mail you now.....check your conversations.

 

[Taz-Matt]

@trialotto

I am sorry to tell you I have not read your comments entirely because I feel they are irrelevant. I am sorry if you have had bad experience with this setup but there does not seem to be any flaw in the RNDC protocol and BIND software that I know of up to now. These are pretty well defined protocol and software and I feel only a bad implementation can result in a bad behaviour otherwise it would probably cause more complaints than anything else to Odin/Parallels and they would've probably removed this extension from their website by now.

In short, your comments are not relevant to my original post, they are not helping in any way and are very negative, which does not serve any purpose.

That being said, I am very happy with my current setup, I thank you @Chris1 and do not bother replying anymore @trialotto as I have said what I needed and will not read any further comments. I hope this thread helps someone else in the future, thus, it would have served its purpose.

Thanks!
Matt.

 

[trialotto]

@Taz-Matt,

It would be much appreciated if you do not conclude about text that you didn´t read, as you indicated yourself.

There is a flaw in the DNS extension, as you have concluded yourself, after Chris1 did pointed that out.

And, bad implementation is choosing a faulty DNS extension, certainly if you are aware of the flaws and, moreover, are probably aware of the better alternatives.

In general, my responses are not aimed at answering your questions, but are intended to give a general insight in "good practice", with the general insight accompanied by various and very relevant factors, that allow (all) forum members to make their own decisions.

The current thread does help every forum member, in the sense that it forms a (repeated) reminder to a (already and widespread known) issue with the DNS extension.

The current thread is also a reminder that it is not "good practice" to install software without knowledge about the underlying (basic) principles and/or the shortcomings in the software and/or the bugs in the software and/or the existence of (better) alternatives and even about the fact that some of the Plesk extensions are old, not properly developed/maintained and even unnecessary (such as the "ticket system extension").

Naturally, you can do whatever you want with my well-meant advice, the freedom of choice is completely yours.

Kind regards....