Re: multi-master with mysql backend
On 2/14/11 4:11 AM, Fajar A. Nugraha wrote: On Mon, Feb 14, 2011 at 6:24 AM, Doug Bartondo...@dougbarton.us wrote: On 2/13/2011 8:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. It isn't a matter of not liking it. Given that you have steadfastly refused to answer any of the questions from people who are trying to help you, my feeling is that you have decided that you want to use mysql no matter what, and you're not really interested in discussing A) What you're actually trying to accomplish, and B) What might be the best tool for doing that job. All things considered, it might be the best tool for that specific need is not bind at all, but something like mydns. Yes maybe I should look also for a mydns solution. thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I will consider very much your hints. Thank you for your point of view and I would like to try What you suggested. Riccardo On 14/feb/2011, at 00:24, Doug Barton do...@dougbarton.us wrote: On 2/13/2011 8:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. It isn't a matter of not liking it. Given that you have steadfastly refused to answer any of the questions from people who are trying to help you, my feeling is that you have decided that you want to use mysql no matter what, and you're not really interested in discussing A) What you're actually trying to accomplish, and B) What might be the best tool for doing that job. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. I'm very familiar with providing mission critical DNS. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers If you nsupdate both servers at the same time, you won't. and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. You're talking about rsync as if it's a huge problem, so my guess is that you're familiar with mysql, but not familiar with rsync. This reinforces my belief that you've settled on mysql as the solution no matter what. But let's take an actual look at your scenario for a second. Which do you _think_ would be faster, rsyncing your data (very little of which is likely to have changed during the outage) or the db synchronizing, which requires it to connect to the other master, play all the transaction logs that it missed, and verify that it's once again in a consistent state? Having thought about it, what results do you get after you actually test it? Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html , which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is something that all DNS server do provide, so your real requirement must be something else, such as being able to update multiple servers at the same time. But Doug Barton has identified that using nsupdate to update both (all) servers also provides a solution to meet this requirement. So, your the mysql solution looks safer to me, may be your viewpoint which is not universally agreed upon. You also have stated just have mysql properly configured. This statement is not unique to MySQL but to BIND also. BIND also needs to be properly configured, no different than with MySQL - nothing unique here. Now, my single belief for any DNS operation is to follow the KISS principle, keep it simple, stupid. A less complex system will be more reliable than a more complex system, because of having less potential points of failure. This reliability is the single most important requirement for a DNS operation. A DNS operation that requires running both BIND and MySQL will be inherently less reliable than one running just BIND. The complexity of a MySQL BIND server makes for a less reliable system than one just using BIND. The performance of a MySQL based BIND server is much less than a standard BIND server. Managing DNS information using dynamic DNS provides a simple solution to updating the zone information. So, what is the actual advantage of using a MySQL backend to BIND? I'm not convinced that there is any advantage and I am sure that there are many downsides to using this. Using MySQL for a backend to BIND is a fairly commonly proposed solution but it's actual implementation is not followed up on. I looked at using MySQL, but the performance limitations were an absolute deal killer. I set up a simple BIND/MySQL system and benchmarked it and duplicated the performance trends from the BIND-DLZ developers. Maybe this has been improved, but these results have not be published so we don't know about it. If you do implement your MySQL solution, please, please, please, keep us informed about how it works for you. We would like to know more and are always willing to look at new technologies but aren't too accepting of hand waving. Bill Larson Riccardo On 2/12/11 11:33 PM, Doug Barton wrote: On 02/11/2011 01:51 PM, fddi wrote: I understand you, but the advantage of having mysql backend is that if one of the two servers dies, the other keeps running with up to date informations, and can also be updated wit new informations. When the other server comes up again it will automatically sync itself using mysql replica mechanism. if I use file
RE: multi-master with mysql backend
I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell From: bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] Sent: Monday, February 14, 2011 10:39 AM To: fddi Cc: bind-users@lists.isc.org Subject: Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is something that all DNS server do provide, so your real requirement must be something else, such as being able to update multiple servers at the same time. But Doug Barton has identified that using nsupdate to update both (all) servers also provides a solution to meet this requirement. So, your the mysql solution looks safer to me, may be your viewpoint which is not universally agreed upon. You also have stated just have mysql properly configured. This statement is not unique to MySQL but to BIND also. BIND also needs to be properly configured, no different than with MySQL - nothing unique here. Now, my single belief for any DNS operation is to follow the KISS principle, keep it simple, stupid. A less complex system will be more reliable than a more complex system, because of having less potential points of failure. This reliability is the single most important requirement for a DNS operation. A DNS operation that requires running both BIND and MySQL will be inherently less reliable than one running just BIND. The complexity of a MySQL BIND server makes for a less reliable system than one just using BIND. The performance of a MySQL based BIND server is much less than a standard BIND server. Managing DNS information using dynamic DNS provides a simple solution to updating the zone information. So, what is the actual advantage of using a MySQL backend to BIND? I'm not convinced that there is any advantage and I am sure that there are many downsides to using this. Using MySQL for a backend to BIND is a fairly commonly proposed solution but it's actual implementation is not followed up on. I looked at using MySQL, but the performance limitations were an absolute deal killer. I
Re: multi-master with mysql backend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is precisely how I'd do it but actually haven't bothered to do the work of setting up config files in advance. I should, because while it is an easy task, if I need to do it, I'm probably not in the mood to figure it out. Having multiple masters sounds interesting, but considering how close the slave configuration is to a master configuration (when you take into account the zone data which is really the important part), it just doesn't seem necessary. On 02/14/2011 10:52 AM, Mike Mitchell wrote: I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell *From:* bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] *Sent:* Monday, February 14, 2011 10:39 AM *To:* fddi *Cc:* bind-users@lists.isc.org *Subject:* Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is something that all DNS server do provide, so your real requirement must be something else, such as being able to update multiple servers at the same time. But Doug Barton has identified that using nsupdate to update both (all) servers also provides a solution to meet this requirement. So, your the mysql solution looks safer to me, may be your viewpoint which is not universally agreed upon. You also have stated just have mysql properly configured. This statement is not unique to MySQL but to BIND also. BIND also needs to be properly configured, no different than with MySQL - nothing unique here. Now, my single belief for any DNS operation is to follow the KISS principle, keep it simple, stupid. A less complex system will be more reliable than a more complex system, because of having less potential points of failure. This reliability is the single most important requirement for a DNS operation. A DNS operation that requires running both BIND and MySQL will be inherently less reliable than one running just BIND. The complexity of a MySQL BIND server
Re: multi-master with mysql backend
Dnia 2011-02-14 15:52 Mike Mitchell napisał(a): I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Nice idea. I'd go even further - why keep two configs? Have a file with your list of zones, and two scripts that generate either master or slave config. Now you are keeping one common config on both severs, which changes only when you add/remove a zone, and two scripts which are almost identical, except for one line (master address). This should be easier to maintain. Now, just in case, you could put on startup scripts the one that generates slave config, so if it reboots you don't have two master servers. And you could cook up a more complicated script, that tries to ping the other server and runs master config generation, freeze, soa change, thaw, reload and send you an email - and you have fully automated HA. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
FWIW, I feel compelled to chime in -- for those who haven't already begun to filter out this thread. We have many thousands of records (internally) in hundreds of zones, mostly dynamic. We have 8 DNS servers providing authoritative and recursive service to thousands of internal clients. All DNS servers are slaves to a single, semi-hidden master. The master's service addresses is statically host routed to the servers currently providing the master DNS service, with the service addresses being assigned to loopback interface on the server. If the active master dies, then I run a simple script on another working DNS server to promote it to master, and I change a static host route in the layer-3 switches to direct zone transfer and DDNS traffic to the new server. I can restore the master DNS functionality on any other DNS server within seconds. The weakness of this system is that I don't trust an automatic failover, so zone transfers and new DDNS requests have to wait until someone on my team is notified of the problem, and they log in, and implement the flip. We do have a mysql-based management system, but only for the non-dynamic zones, and the zone files are pushed out to the active master using scp and rndc. I would never install the database on an actual DNS server -- for many, many reasons. Sorry if I come across as harsh, but the thought of installing a database system on every DNS server that might need to become master seems extremely insane. Ah. There, I feel much better now having said that. -- Gordon A. Lang / 313-819-7978 - Original Message - From: Mike Mitchell To: fddi Cc: bind-users@lists.isc.org Sent: Monday, February 14, 2011 10:52 AM Subject: RE: multi-master with mysql backend I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell From: bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] Sent: Monday, February 14, 2011 10:39 AM To: fddi Cc: bind-users@lists.isc.org Subject: Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability
Re: multi-master with mysql backend
In case anyone is actually paying attention, I just re-read my own post, and I'd like to clarify my plural reference to the service addresses... I have one service address for DDNS and separate service address for zone transfers. So, technically we have to change two static host-routes, not just one. But the simplicity is still intact. And also, I'd like to point out that my simple promote script has a sister script called demote, and these scripts bring up or bring down the service addresses on loopbacks as well as restart the named process. And, by the way, we have NEVER needed to change masters since mid-2005 when it was first deployed. I am anxiously waiting for an actual failure to justify all my work.!!! -- Gordon A. Lang - Original Message - From: Gordon A. Lang gl...@goalex.com To: bind-users@lists.isc.org Cc: Mike Mitchell mike.mitch...@sas.com Sent: Monday, February 14, 2011 1:18 PM Subject: Re: multi-master with mysql backend FWIW, I feel compelled to chime in -- for those who haven't already begun to filter out this thread. We have many thousands of records (internally) in hundreds of zones, mostly dynamic. We have 8 DNS servers providing authoritative and recursive service to thousands of internal clients. All DNS servers are slaves to a single, semi-hidden master. The master's service addresses is statically host routed to the servers currently providing the master DNS service, with the service addresses being assigned to loopback interface on the server. If the active master dies, then I run a simple script on another working DNS server to promote it to master, and I change a static host route in the layer-3 switches to direct zone transfer and DDNS traffic to the new server. I can restore the master DNS functionality on any other DNS server within seconds. The weakness of this system is that I don't trust an automatic failover, so zone transfers and new DDNS requests have to wait until someone on my team is notified of the problem, and they log in, and implement the flip. We do have a mysql-based management system, but only for the non-dynamic zones, and the zone files are pushed out to the active master using scp and rndc. I would never install the database on an actual DNS server -- for many, many reasons. Sorry if I come across as harsh, but the thought of installing a database system on every DNS server that might need to become master seems extremely insane. Ah. There, I feel much better now having said that. -- Gordon A. Lang / 313-819-7978 - Original Message - From: Mike Mitchell To: fddi Cc: bind-users@lists.isc.org Sent: Monday, February 14, 2011 10:52 AM Subject: RE: multi-master with mysql backend I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell From: bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] Sent: Monday, February 14, 2011 10:39 AM To: fddi Cc: bind-users@lists.isc.org Subject: Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I
Re: multi-master with mysql backend
On Feb 14, 2011, at 12:54 PM, Torinthiel wrote:
Dnia 2011-02-14 15:52 Mike Mitchell napisał(a):
I'd keep two copies of the BIND config, one that has all the zones as
master, and one that has all the zones as slave. When the
master dies,
run a little script on a slave that freezes the zones, edits the SOA
to make
that server the MNAME and increment the serial, then thaws the zone.
Swap
out the config with the master config, and now you have a new
master.
Before the broken master comes back online, swap out its config
with the
slave config.
No need for rsync or mysql, BIND replication does all the work for
you.
Just be sure the updates go to the server listed in the MNAME field
of the
SOA.
Nice idea. I'd go even further - why keep two configs? Have a file
with your
list of zones, and two scripts that generate either master or slave
config.
I'm probably going to regret this, but I'm basically doing what you
suggest for some (~15-20) personal domains. Every now and then someone
asks me to run a mailing list for them, please just host a website,
etc. I got tired of updating named.conf on a bunch of servers, cp ~/
configs/base_bind.db /etc/namedb/example.com, add stuff to apache, go
poke postfix on N mailhosts, kick mailman, etc so I finally invested
the time and effort into setting up puppet -- it was *well* worth it...
Now I have a Python dictionary that looks like:
{
ac4wk.com:{bind: local, postfix_virtual: True,
base_web: True, redirect: False },
af7.org: {bind: local, postfix_virtual: True,
base_web: True, redirect: False },
.
}
and a little script that creates a set of Puppet arrays. Puppet then
reads these and does magic.
bind:local specifies to use a template that lists my machines as
MX and www and similar
postfix_virtual add the domain to the virtual lines in postfix to the
mailservers know to accept mail for it
base_web creates directories, add the site to the apache config and
copies some base html files.
redirect: Can be set to a different domains and will then setup a
domain to serve a 302 redirect to some other domain..
My master has
# And setup bind.
$bind_type = master
include bind
and slaves have:
# And setup bind.
$bind_type = slave
$bindmaster = 198.186.192.250
include bind
bind::db_files {[22.194.204.in-addr.arpa, 58.177.216.in-
addr.arpa]:}
in the node manifest.
named.conf is automatically generated from a template, containing some
base config and:
// Section managed by Puppet.
% if bind_type == master then %
% zones.each do |zone| -%
// %= zone % -- Zone stanza generated by puppet.
zone %= zone % {
type master;
file /etc/namedb/%= zone %;
auto-dnssec maintain;
update-policy {
grant local-ddns subdomain * ANY;
grant tsig_1.kumari.net. zonesub ANY;
};
allow-transfer { xfer; };
};
% end -%
% else %
% zones.each do |zone| -%
// %= zone % -- Zone stanza generated by puppet.
zone %= zone % {
type slave;
file /etc/namedb/slave/%= zone %;
allow-transfer { xfer; };
masters { %= bindmaster %; };
};
% end -%
% end %
This means that adding a new domain now just involves adding a line to
the python dictionary and running a script to convert the python to
the puppet arrays -- takes all of 20 seconds.
Making a slave become a master (which I've done a few times as a test)
involves simply changing the line in the manifest.
I realize that this is getting off topic, but puppet has made my life
way easier (this part was a insignificant part of it) and I wanted to
share :-P
W
Now you are keeping one common config on both severs, which changes
only
when you add/remove a zone, and two scripts which are almost
identical,
except for one line (master address). This should be easier to
maintain.
Now, just in case, you could put on startup scripts the one that
generates
slave config, so if it reboots you don't have two master servers.
And you could cook up a more complicated script, that tries to ping
the
other server and runs master config generation, freeze, soa change,
thaw,
reload and send you an email - and you have fully automated HA.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Some people are like Slinkies..Not really good for anything but
they still bring a smile to your face when you push them down the
stairs.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. Riccardo On 2/12/11 11:33 PM, Doug Barton wrote: On 02/11/2011 01:51 PM, fddi wrote: I understand you, but the advantage of having mysql backend is that if one of the two servers dies, the other keeps running with up to date informations, and can also be updated wit new informations. When the other server comes up again it will automatically sync itself using mysql replica mechanism. if I use file backend I have to manually sync it, and how to keep tracks of modifications ? for this I choose mysql backend Two questions, how often do you anticipate one of the masters failing, and how much data are you talking about? Generally the number of times a server fails is going to be pretty small, if it's not, you've got bigger problems. If you're not talking about a huge amount of data here (and from what you've described in previous posts, you're not) then you are fairly dramatically over-architecting your solution here. Personally I think David had a great idea in regards to using nsupdate to update both masters at the same time. If you really think that one of them is going to fail often enough to justify an automated solution than scripting something that utilizes rsync shouldn't be too hard. hth, Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On 2/13/2011 8:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. It isn't a matter of not liking it. Given that you have steadfastly refused to answer any of the questions from people who are trying to help you, my feeling is that you have decided that you want to use mysql no matter what, and you're not really interested in discussing A) What you're actually trying to accomplish, and B) What might be the best tool for doing that job. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. I'm very familiar with providing mission critical DNS. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers If you nsupdate both servers at the same time, you won't. and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. You're talking about rsync as if it's a huge problem, so my guess is that you're familiar with mysql, but not familiar with rsync. This reinforces my belief that you've settled on mysql as the solution no matter what. But let's take an actual look at your scenario for a second. Which do you _think_ would be faster, rsyncing your data (very little of which is likely to have changed during the outage) or the db synchronizing, which requires it to connect to the other master, play all the transaction logs that it missed, and verify that it's once again in a consistent state? Having thought about it, what results do you get after you actually test it? Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On Mon, Feb 14, 2011 at 6:24 AM, Doug Barton do...@dougbarton.us wrote: On 2/13/2011 8:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. It isn't a matter of not liking it. Given that you have steadfastly refused to answer any of the questions from people who are trying to help you, my feeling is that you have decided that you want to use mysql no matter what, and you're not really interested in discussing A) What you're actually trying to accomplish, and B) What might be the best tool for doing that job. All things considered, it might be the best tool for that specific need is not bind at all, but something like mydns. -- Fajar ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On 02/11/2011 01:51 PM, fddi wrote: I understand you, but the advantage of having mysql backend is that if one of the two servers dies, the other keeps running with up to date informations, and can also be updated wit new informations. When the other server comes up again it will automatically sync itself using mysql replica mechanism. if I use file backend I have to manually sync it, and how to keep tracks of modifications ? for this I choose mysql backend Two questions, how often do you anticipate one of the masters failing, and how much data are you talking about? Generally the number of times a server fails is going to be pretty small, if it's not, you've got bigger problems. If you're not talking about a huge amount of data here (and from what you've described in previous posts, you're not) then you are fairly dramatically over-architecting your solution here. Personally I think David had a great idea in regards to using nsupdate to update both masters at the same time. If you really think that one of them is going to fail often enough to justify an automated solution than scripting something that utilizes rsync shouldn't be too hard. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On 2/9/2011 7:12 PM, fddi wrote: I could succesfully setup bind with mysql backend and it works using bind-mysql driver. everything works except that nsupdate will no longer work. is this normal ?? requests sent for adding a RR using nsupdate are ignored by named when using mysqldb backend while they are honoured and served when using normal file backend. is this a normal behaviour ? how to use nsupdate even if with a different backend which is not the default file backend ? If you are using nsupdate to make changes to your hosted zones, couldn't you simply change the process to send the update to both servers separately. Make each server a master with a standard file for the backend data. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I understand you, but the advantage of having mysql backend is that if one of the two servers dies, the other keeps running with up to date informations, and can also be updated wit new informations. When the other server comes up again it will automatically sync itself using mysql replica mechanism. if I use file backend I have to manually sync it, and how to keep tracks of modifications ? for this I choose mysql backend Riccardo On 2/11/11 10:29 PM, David Sparro wrote: On 2/9/2011 7:12 PM, fddi wrote: I could succesfully setup bind with mysql backend and it works using bind-mysql driver. everything works except that nsupdate will no longer work. is this normal ?? requests sent for adding a RR using nsupdate are ignored by named when using mysqldb backend while they are honoured and served when using normal file backend. is this a normal behaviour ? how to use nsupdate even if with a different backend which is not the default file backend ? If you are using nsupdate to make changes to your hosted zones, couldn't you simply change the process to send the update to both servers separately. Make each server a master with a standard file for the backend data. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I need really something very simple: I have 2 domain name servers, I need them to be multi-master Please explain -- *why* do you need multimaster? I need to be able to update the nameserver even if one of the two masters is down, I need this for High Avaliability purposes for services geographycally distriuted If I do not have a multimaster architecture and primary nameserver goes down, I Cannot update the secondary if I need to. How about rsync? I too need a second master in an alternate location, only in the event of a catastrophe (loss of a data center). There are active slaves with dynamic zones in both locations. Any of the slaves can use either master, but by default, they use the one listed first in named.conf which is the master in the main location. If the first master disappears, the slaves will use the other master. Simplicity is important to me as well and that's why I chose rsync to periodically get the zone data (and configs) to the master in the secondary location. I looked into MySQL (which I use for other purposes), but the solution was no longer simple. Steve. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I have considered dlz, but it does mocu more than simply mysql backend and seems too way complicate for my porpouse. At hte end I am considering using this mysql-bind: http://mysql-bind.sourceforge.net/ do you think ti si a good alternative only for mysql backend propouses ? thank you Riccardo On 2/8/11 12:07 AM, p...@mail.nsbeta.info wrote: fddi writes: Hello, I would like to configure a multi-master configuration wirh 2 hosts and I have been thinking to mysql as a backend. Is there any official or semi-official support in bind for using mysql as backend ? Any kind of documentation on this ? Try google with bind dlz. enabling mysql with bind gets bad performance from my experience. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
thank you for hte thread you pointed me. Actaully I do not have performance issue, but I just need DNS multi-master. I could succesfully apply mysql-bind patches. I have only one zone with few hosts. thank you very much Riccardo On 2/8/11 3:30 PM, Terry. wrote: 2011/2/8 fddif...@gmx.it: I have considered dlz, but it does mocu more than simply mysql backend and seems too way complicate for my porpouse. At hte end I am considering using this mysql-bind: http://mysql-bind.sourceforge.net/ You may read this one of the mailing list archive: https://lists.isc.org/pipermail/bind-users/2008-April/069884.html Terry. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
fddi wrote: thank you for hte thread you pointed me. Actaully I do not have performance issue, but I just need DNS multi-master. I could succesfully apply mysql-bind patches. I have only one zone with few hosts. thank you very much Riccardo On 2/8/11 3:30 PM, Terry. wrote: 2011/2/8 fddif...@gmx.it: I have considered dlz, but it does mocu more than simply mysql backend and seems too way complicate for my porpouse. At hte end I am considering using this mysql-bind: http://mysql-bind.sourceforge.net/ You may read this one of the mailing list archive: https://lists.isc.org/pipermail/bind-users/2008-April/069884.html Terry. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users A nice way to deal with what Riccardo's needs is to use ISC BIND configured statically (keeps all advantages of a pure BIND system) but from a MySQL database that has web apps for end users to manage their own zone data. BIND was not meant for end users with little to no DNS expertise to manage their RRs. Some middleware is required. This is not a new concept but developed from pure dynamic websites to ones that printed static copies of their pages -now proxies are also used as well as memcache for SQL query caching. See wikipedia for dns management software. Cheers! Gary ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I need really something very simple: I have 2 domain name servers, I need them to be multi-master so I will put a mysql instance on each one, the two mysql servers in sync whith each other. when one of the servers goes down, the other continue to work. There are very few entry in hte database let;s say 10 entries of important internet services which must be always avaliable... that's it nothing complicate. now I coudl succesfully build my own bind RPM for CentOS with mysql backend support. I simply used mysql-bind driver patches http://mysql-bind.sourceforge.net/ now I am trying them out thank you for all the suggestions you gave me Riccardo On 2/8/11 4:28 PM, Gary Wallis wrote: fddi wrote: thank you for hte thread you pointed me. Actaully I do not have performance issue, but I just need DNS multi-master. I could succesfully apply mysql-bind patches. I have only one zone with few hosts. thank you very much Riccardo On 2/8/11 3:30 PM, Terry. wrote: 2011/2/8 fddif...@gmx.it: I have considered dlz, but it does mocu more than simply mysql backend and seems too way complicate for my porpouse. At hte end I am considering using this mysql-bind: http://mysql-bind.sourceforge.net/ You may read this one of the mailing list archive: https://lists.isc.org/pipermail/bind-users/2008-April/069884.html Terry. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users A nice way to deal with what Riccardo's needs is to use ISC BIND configured statically (keeps all advantages of a pure BIND system) but from a MySQL database that has web apps for end users to manage their own zone data. BIND was not meant for end users with little to no DNS expertise to manage their RRs. Some middleware is required. This is not a new concept but developed from pure dynamic websites to ones that printed static copies of their pages -now proxies are also used as well as memcache for SQL query caching. See wikipedia for dns management software. Cheers! Gary ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
actually I Was too way optimistic. nothing works after patching named woth mysql-bind source code: /usr/sbin/named -f -u named -t /var/named/chroot Segmentation fault Feb 8 16:53:02 ns kernel: named[2239] general protection rip:2af3633cfa10 rsp:40bb5148 error:0 On 2/8/11 4:28 PM, Gary Wallis wrote: fddi wrote: thank you for hte thread you pointed me. Actaully I do not have performance issue, but I just need DNS multi-master. I could succesfully apply mysql-bind patches. I have only one zone with few hosts. thank you very much Riccardo On 2/8/11 3:30 PM, Terry. wrote: 2011/2/8 fddif...@gmx.it: I have considered dlz, but it does mocu more than simply mysql backend and seems too way complicate for my porpouse. At hte end I am considering using this mysql-bind: http://mysql-bind.sourceforge.net/ You may read this one of the mailing list archive: https://lists.isc.org/pipermail/bind-users/2008-April/069884.html Terry. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users A nice way to deal with what Riccardo's needs is to use ISC BIND configured statically (keeps all advantages of a pure BIND system) but from a MySQL database that has web apps for end users to manage their own zone data. BIND was not meant for end users with little to no DNS expertise to manage their RRs. Some middleware is required. This is not a new concept but developed from pure dynamic websites to ones that printed static copies of their pages -now proxies are also used as well as memcache for SQL query caching. See wikipedia for dns management software. Cheers! Gary ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
2011/2/9 Torinthiel torinth...@data.pl: Or, if you need to be able to modify records from both servers than maybe multi-master with rsync'ing to the other server will work? Mysql Active-Active replication could do that easily. AFAIK, mysql backend BIND doesn't have the feature notify, so database replication is the primary way of sync zones. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On Feb 8, 2011, at 10:47 AM, fddi wrote: I need really something very simple: I have 2 domain name servers, I need them to be multi-master Please explain -- *why* do you need multimaster? so I will put a mysql instance on each one, the two mysql servers in sync whith each other. when one of the servers goes down, the other continue to work. If you have traditional master-slave and the master goes down, the slave will continue to serve the last information it had (at least, until the expire timer goes boing). So, make Server_A be the master, Server_B the slave and set expire to be a couple of weeks. Assuming Server_A goes kablooie, you have 2 weeks to promote Server_B from slave to master... There are very few entry in hte database let;s say 10 entries of important internet services which must be always avaliable... that's it nothing complicate. Yup. now I coudl succesfully build my own bind RPM for CentOS with mysql backend support. I simply used mysql-bind driver patches Ah, but now, suddenly, it *is* complicated... Seriously, unless you have some pathological use case traditional master/ slave is way way more stable... W http://mysql-bind.sourceforge.net/ now I am trying them out thank you for all the suggestions you gave me Riccardo On 2/8/11 4:28 PM, Gary Wallis wrote: fddi wrote: thank you for hte thread you pointed me. Actaully I do not have performance issue, but I just need DNS multi-master. I could succesfully apply mysql-bind patches. I have only one zone with few hosts. thank you very much Riccardo On 2/8/11 3:30 PM, Terry. wrote: 2011/2/8 fddif...@gmx.it: I have considered dlz, but it does mocu more than simply mysql backend and seems too way complicate for my porpouse. At hte end I am considering using this mysql-bind: http://mysql-bind.sourceforge.net/ You may read this one of the mailing list archive: https://lists.isc.org/pipermail/bind-users/2008-April/069884.html Terry. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users A nice way to deal with what Riccardo's needs is to use ISC BIND configured statically (keeps all advantages of a pure BIND system) but from a MySQL database that has web apps for end users to manage their own zone data. BIND was not meant for end users with little to no DNS expertise to manage their RRs. Some middleware is required. This is not a new concept but developed from pure dynamic websites to ones that printed static copies of their pages -now proxies are also used as well as memcache for SQL query caching. See wikipedia for dns management software. Cheers! Gary ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
