<!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>