<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.17093" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face="Courier New">In case anyone is actually paying attention, I 
just re-read</FONT></DIV>
<DIV><FONT face="Courier New">my own post, and I'd like to clarify my plural 
reference to</FONT></DIV>
<DIV><FONT face="Courier New">the </FONT><FONT face="Courier New">service 
addresses...</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">I have one service address for DDNS and separate 
service</FONT></DIV>
<DIV><FONT face="Courier New">address for zone transfers.  </FONT><FONT 
face="Courier New">So, technically we have to</FONT></DIV>
<DIV><FONT face="Courier New">change two static host-routes, not just one.  
But the</FONT></DIV>
<DIV><FONT face="Courier New">simplicity is still intact.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">And also, I'd like to point out that my simple 
"promote"</FONT></DIV>
<DIV><FONT face="Courier New">script has a sister script called "demote," and 
these</FONT></DIV>
<DIV><FONT face="Courier New">scripts bring up or bring down the service 
addresses on</FONT></DIV>
<DIV><FONT face="Courier New">loopbacks as well as restart the "named" 
process.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT> </DIV>
<DIV><FONT face="Courier New">And, by the way, we have NEVER needed to change 
masters</FONT></DIV>
<DIV><FONT face="Courier New">since mid-2005 when it was first deployed.  I 
am anxiously</FONT></DIV>
<DIV><FONT face="Courier New">waiting for an actual failure to justify all my 
work.!!!</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><BR><FONT 
face="Courier New">--<BR>Gordon A. Lang</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>----- Original Message ----- </FONT>
<DIV><FONT face=Arial size=2>From: "Gordon A. Lang" <</FONT><A 
href="mailto:glang@goalex.com"><FONT face=Arial 
size=2>glang@goalex.com</FONT></A><FONT face=Arial size=2>></FONT></DIV>
<DIV><FONT face=Arial size=2>To: <</FONT><A 
href="mailto:bind-users@lists.isc.org"><FONT face=Arial 
size=2>bind-users@lists.isc.org</FONT></A><FONT face=Arial 
size=2>></FONT></DIV>
<DIV><FONT face=Arial size=2>Cc: "Mike Mitchell" <</FONT><A 
href="mailto:Mike.Mitchell@sas.com"><FONT face=Arial 
size=2>Mike.Mitchell@sas.com</FONT></A><FONT face=Arial size=2>></FONT></DIV>
<DIV><FONT face=Arial size=2>Sent: Monday, February 14, 2011 1:18 
PM</FONT></DIV>
<DIV><FONT face=Arial size=2>Subject: Re: multi-master with mysql 
backend</FONT></DIV></DIV>
<DIV><FONT face=Arial><BR><FONT size=2></FONT></FONT></DIV><FONT face=Arial 
size=2>> FWIW, I feel compelled to chime in -- for those who haven't already 
begun<BR>> to filter out this thread.....<BR>> <BR>> We have many 
thousands of records (internally) in hundreds of zones,<BR>> mostly 
dynamic.<BR>> <BR>> We have 8 DNS servers providing authoritative and 
recursive service to<BR>> thousands of internal clients.<BR>> <BR>> All 
DNS servers are slaves to a single, semi-hidden master.<BR>> <BR>> The 
master's "service addresses" is statically host routed to the servers<BR>> 
currently providing the master DNS service, with the service addresses<BR>> 
being assigned to loopback interface on the server.<BR>> <BR>> If the 
active master dies, then I run a simple script on another working<BR>> DNS 
server to promote it to master, and I change a static host route in<BR>> the 
layer-3 switches to direct zone transfer and DDNS traffic to the new<BR>> 
server.  I can restore the master DNS functionality on any other 
DNS<BR>> server within seconds.<BR>> <BR>> The weakness of this system 
is that I don't trust an automatic failover,<BR>> so zone transfers and new 
DDNS requests have to wait until someone on my<BR>> team is notified of the 
problem, and they log in, and implement the flip.<BR>> <BR>> We do have a 
mysql-based management system, but only for the non-dynamic<BR>> zones, and 
the zone files are pushed out to the active master using scp<BR>> and 
rndc.  I would never install the database on an actual DNS server 
--<BR>> for many, many reasons.<BR>> <BR>> Sorry if I come across as 
harsh, but the thought of installing a database<BR>> system on every DNS 
server that might need to become master seems<BR>> extremely insane.<BR>> 
<BR>> Ah.  There, I feel much better now having said that.<BR>> 
<BR>> --<BR>> Gordon A. Lang  /  313-819-7978<BR>> ----- 
Original Message ----- <BR>> From: Mike Mitchell<BR>> To: fddi<BR>> Cc: 
</FONT><A href="mailto:bind-users@lists.isc.org"><FONT face=Arial 
size=2>bind-users@lists.isc.org</FONT></A><BR><FONT face=Arial size=2>> Sent: 
Monday, February 14, 2011 10:52 AM<BR>> Subject: RE: multi-master with mysql 
backend<BR>> <BR>> <BR>> I'd keep two copies of the BIND config, one 
that has all the zones as <BR>> "master", and one that has all the zones as 
"slave".  When the master dies, <BR>> run a little script on a slave 
that freezes the zones, edits the SOA to make <BR>> that server the MNAME and 
increment the serial, then thaws the zone. Swap <BR>> out the config with the 
"master" config, and now you have a new master.<BR>> <BR>> Before the 
broken master comes back online, swap out its config with the <BR>> "slave" 
config.<BR>> <BR>> No need for rsync or mysql, BIND replication does all 
the work for you. <BR>> Just be sure the updates go to the server listed in 
the MNAME field of the <BR>> SOA.<BR>> <BR>> Mike Mitchell<BR>> 
<BR>> <BR>> <BR>> <BR>> <BR>> From: </FONT><A 
href="mailto:bind-users-bounces+mike.mitchell=sas.com@lists.isc.org"><FONT 
face=Arial 
size=2>bind-users-bounces+mike.mitchell=sas.com@lists.isc.org</FONT></A><FONT 
face=Arial size=2> <BR>> 
[bind-users-bounces+mike.mitchell=sas.com@lists.isc.org] on behalf of Bill 
<BR>> Larson [wllarso.dns@gmail.com]<BR>> Sent: Monday, February 14, 2011 
10:39 AM<BR>> To: fddi<BR>> Cc: </FONT><A 
href="mailto:bind-users@lists.isc.org"><FONT face=Arial 
size=2>bind-users@lists.isc.org</FONT></A><BR><FONT face=Arial size=2>> 
Subject: Re: multi-master with mysql backend<BR>> <BR>> <BR>> On Feb 
13, 2011, at 9:06 AM, fddi wrote:<BR>> <BR>> <BR>> I do not know why 
you really don't liket this mysql solution.<BR>> OK I am talking of a DNS for 
HA purposes for grid computing services for <BR>> exampe, so DNS<BR>> 
resolution must be always working at any cost.<BR>> The David solution can be 
OK, but I want to be sure not to have issues with <BR>> serial numbers on the 
two servers<BR>> and the mysql solution looks safer to me. You do not have to 
rsync anything, <BR>> just have mysql properly configured.<BR>> <BR>> 
<BR>> <BR>> This list is read by many people with extreme experience with 
DNS and DNS <BR>> operations.  Using the information that you have 
provided, many solutions <BR>> have been provided to meet the requirements 
that you have stated.  I would <BR>> suggest that you at least consider 
this other solutions and not be as <BR>> adamant about using your proposed 
MySQL solution.<BR>> <BR>> <BR>> You state that you have a "HA" 
requirement.  Please understand that this is <BR>> not an uncommon 
requirement for a DNS operation.  In fact, almost all DNS <BR>> 
operations have this same requirement.  Just imagine if the root servers 
did <BR>> not have a require for "high availability".  The same goes for 
the "com", <BR>> "net", "org" servers ("it" also).  This is not an 
unusual requirement and a <BR>> standard BIND DNS server provides this very 
well.<BR>> <BR>> <BR>> Now, I would also suggest that a MySQL DNS 
server may not be the best <BR>> solution for a critical DNS operation.  
Please take a look at the benchmark <BR>> work done comparing BIND using 
various backend systems, including MySQL. <BR>> This can be found at 
</FONT><A href="http://bind-dlz.sourceforge.net/perf_tests.html"><FONT 
face=Arial 
size=2>http://bind-dlz.sourceforge.net/perf_tests.html</FONT></A><FONT 
face=Arial size=2>, which <BR>> is part of the work that the people that 
developed DLZ for BIND.  The <BR>> standard BIND server could provide 
16,000 queries per second.  The same BIND <BR>> server using a MySQL 
backend could handle less than 700 qps.<BR>> <BR>> <BR>> BIND DLZ using 
MySQL is NOT what I would consider to be a high performance <BR>> solution 
for a DNS operation.  Now, granted, these results were not using a <BR>> 
"current" version of BIND, nor was this being run on any "high power" <BR>> 
hardware.  Performance of BIND DLZ using a MySQL backend may have easily 
<BR>> been improved, but so has the performance of the base system too.  
A 20 to 1 <BR>> performance advantage for a straight BIND solution will be 
hard to overcome.<BR>> <BR>> <BR>> So, performance isn't something that 
a MySQL backend provides to a DNS <BR>> operation and high availability is 
something that all DNS server do provide, <BR>> so your real requirement must 
be something else, such as being able to <BR>> update multiple servers at the 
same time.  But Doug Barton has identified <BR>> that using "nsupdate" 
to update both (all) servers also provides a solution <BR>> to meet this 
requirement.<BR>> <BR>> <BR>> So, your "the mysql solution looks safer 
to me", may be your viewpoint which <BR>> is not universally agreed 
upon.  You also have stated "just have mysql <BR>> properly 
configured".  This statement is not unique to MySQL but to BIND <BR>> 
also.  BIND also needs to be properly configured, no different than with 
<BR>> MySQL - nothing unique here.<BR>> <BR>> <BR>> Now, my single 
belief for any DNS operation is to follow the KISS principle, <BR>> "keep it 
simple, stupid".  A less complex system will be more reliable than <BR>> 
a more complex system, because of having less potential points of failure. 
<BR>> This reliability is the single most important requirement for a DNS 
<BR>> operation.  A DNS operation that requires running both BIND and 
MySQL will <BR>> be inherently less reliable than one running just 
BIND.<BR>> <BR>> <BR>> The complexity of a MySQL BIND server makes for 
a less reliable system than <BR>> one just using BIND.  The performance 
of a MySQL based BIND server is much <BR>> less than a standard BIND 
server.  Managing DNS information using dynamic <BR>> DNS provides a 
simple solution to updating the zone information.  So, what <BR>> is the 
actual advantage of using a MySQL backend to BIND?  I'm not convinced 
<BR>> that there is any advantage and I am sure that there are many downsides 
to <BR>> using this.<BR>> <BR>> <BR>> Using MySQL for a backend to 
BIND is a fairly commonly proposed solution but <BR>> it's actual 
implementation is not followed up on.  I looked at using MySQL, <BR>> 
but the performance limitations were an absolute deal killer.  I set up a 
<BR>> simple BIND/MySQL system and benchmarked it and duplicated the 
performance <BR>> trends from the BIND-DLZ developers.  Maybe this has 
been improved, but <BR>> these results have not be published so we don't know 
about it.<BR>> <BR>> <BR>> If you do implement your MySQL solution, 
please, please, please, keep us <BR>> informed about how it works for 
you.  We would like to know more and are <BR>> always willing to look at 
new technologies but aren't too accepting of hand <BR>> waving.<BR>> 
<BR>> <BR>> Bill Larson<BR>> <BR>> <BR>> Riccardo<BR>> 
<BR>> On 2/12/11 11:33 PM, Doug Barton wrote:<BR>> <BR>> On 02/11/2011 
01:51 PM, fddi wrote:<BR>> <BR>> I understand you, but the advantage of 
having mysql backend is that<BR>> <BR>> if one of the two servers dies, 
the other keeps running with up to<BR>> <BR>> date informations, and can 
also be updated wit new informations. When<BR>> <BR>> the  other 
server comes up again it will automatically sync itself<BR>> <BR>> using 
mysql replica mechanism. if I use file backend I have to<BR>> <BR>> 
manually sync it, and how to keep tracks of modifications ?<BR>> <BR>> 
<BR>> <BR>> for this I choose mysql backend<BR>> <BR>> <BR>> 
<BR>> Two questions, how often do you anticipate one of the masters failing, 
and <BR>> how much data are you talking about? Generally the number of times 
a server <BR>> fails is going to be pretty small, if it's not, you've got 
bigger problems.<BR>> <BR>> <BR>> <BR>> If you're not talking about 
a huge amount of data here (and from what you've <BR>> described in previous 
posts, you're not) then you are fairly dramatically <BR>> over-architecting 
your solution here. Personally I think David had a great <BR>> idea in 
regards to using nsupdate to update both masters at the same time. <BR>> If 
you really think that one of them is going to fail often enough to <BR>> 
justify an automated solution than scripting something that utilizes rsync 
<BR>> shouldn't be too hard.<BR>> <BR>> <BR>> <BR>> <BR>> 
<BR>> hth,<BR>> <BR>> <BR>> <BR>> Doug<BR>> <BR>> <BR>> 
<BR>> <BR>> _______________________________________________<BR>> 
bind-users mailing list<BR>> </FONT><A 
href="mailto:bind-users@lists.isc.org"><FONT face=Arial 
size=2>bind-users@lists.isc.org</FONT></A><BR><FONT face=Arial size=2>> 
</FONT><A href="https://lists.isc.org/mailman/listinfo/bind-users"><FONT 
face=Arial 
size=2>https://lists.isc.org/mailman/listinfo/bind-users</FONT></A><BR><FONT 
face=Arial size=2>> <BR>> <BR>> <BR>> <BR>> <BR>> <BR>> 
_______________________________________________<BR>> bind-users mailing 
list<BR>> </FONT><A href="mailto:bind-users@lists.isc.org"><FONT face=Arial 
size=2>bind-users@lists.isc.org</FONT></A><BR><FONT face=Arial size=2>> 
</FONT><A href="https://lists.isc.org/mailman/listinfo/bind-users"><FONT 
face=Arial 
size=2>https://lists.isc.org/mailman/listinfo/bind-users</FONT></A><FONT 
face=Arial size=2> <BR>> <BR>> 
_______________________________________________<BR>> bind-users mailing 
list<BR>> </FONT><A href="mailto:bind-users@lists.isc.org"><FONT face=Arial 
size=2>bind-users@lists.isc.org</FONT></A><BR><FONT face=Arial size=2>> 
</FONT><A href="https://lists.isc.org/mailman/listinfo/bind-users"><FONT 
face=Arial 
size=2>https://lists.isc.org/mailman/listinfo/bind-users</FONT></A><BR><FONT 
face=Arial size=2>></FONT></BODY></HTML>