<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000">+2<br>
<br>
<blockquote style="border: 0px none;" 
cite="mid:F74C31D2-EBD1-4C7C-A4B7-082A5DC71B73@arbor.net" type="cite">
  <div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div 
style="display:table;width:100%;border-top:1px solid 
#EDEEF0;padding-top:5px">       <div 
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
 photoaddress="rdobbins@arbor.net" photoname="Roland Dobbins" 
src="cid:part1.08070602.04040901@dnsbed.com" 
name="compose-unknown-contact.jpg" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:rdobbins@arbor.net" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Roland Dobbins</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">2014年12月16日上午7:48</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
<br>On 16 Dec 2014, at 6:25, Edward Lewis wrote:
<br>
<br>
<br>+1
<br>
<br>-----------------------------------
<br>Roland Dobbins <a class="moz-txt-link-rfc2396E" href="mailto:rdobbins@arbor.net"><rdobbins@arbor.net></a>
<br>_______________________________________________
<br>dns-operations mailing list
<br><a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>
<br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a>
<br>dns-jobs mailing list
<br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a>
<br></div>
  <div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div 
style="display:table;width:100%;border-top:1px solid 
#EDEEF0;padding-top:5px">       <div 
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
 photoaddress="edward.lewis@icann.org" photoname="Edward Lewis" 
src="cid:part1.08070602.04040901@dnsbed.com" 
name="compose-unknown-contact.jpg" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:edward.lewis@icann.org" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Edward Lewis</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">2014年12月16日上午7:25</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody"><div><!----><br>The problem 
with broad generalizations is that they are always wrong.<br><br>(Meant 
as a joke.)<br><br>I skimmed this thread now and then and thought about 
my experience in<br>building and operating systems.  Ever since “The 
Cuckoo’s Egg” - as far as<br>I know - “genetic code diversity” has been a
 fad.  It got woven into a lot<br>of requirements.  Having spent a long 
time inside operators, I’ve seen<br>this become more of an albatross 
than a “good idea."<br><br>If I am operating a system supporting 
external customers, homogeneity is a<br>benefit.<br><br>If I am 
operating a system for my own benefit, heterogeneity is a benefit.<br><br>My
 recommendation for a service provider stick with one code base and<br>learn
 to run it well.  My recommendation for a customer of such a provider<br>use
 two or more service providers.<br><br></div><div>_______________________________________________<br>dns-operations
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>dns-jobs
 mailing list<br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a></div></div>
  <div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div 
style="display:table;width:100%;border-top:1px solid 
#EDEEF0;padding-top:5px">       <div 
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
 photoaddress="rdobbins@arbor.net" photoname="Roland Dobbins" 
src="cid:part1.08070602.04040901@dnsbed.com" 
name="compose-unknown-contact.jpg" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:rdobbins@arbor.net" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Roland Dobbins</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">2014年12月16日上午3:40</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody">
<br>On 16 Dec 2014, at 1:42, Mike Hoskins (michoski) wrote:
<br>
<br><blockquote type="cite">You can acknowledge things aren't a panacea,
 while still deriving some 
benefits from them.
<br></blockquote>
<br>My point is that the negatives far outweigh the benefits in most 
organizations.
<br>
<br><blockquote type="cite">Monitoring/analytics (intelligence) is key, 
so the operator can 
intelligently control flows across their services based on risks and 
observed threats.
<br></blockquote>
<br>Yes, I'm a big advocate of this - but it's honored more in the 
breach 
than in the observance, all in all.
<br>
<br>Concentrating on telemetry and analytics, and in the people to 
utilize 
same, makes a lot more sense than concentrating on software diversity, 
in most organizations.  Worrying about software diversity is something 
to do after you've done just about everything else you can to improve 
your security posture.
<br>
<br>-----------------------------------
<br>Roland Dobbins <a class="moz-txt-link-rfc2396E" href="mailto:rdobbins@arbor.net"><rdobbins@arbor.net></a>
<br>_______________________________________________
<br>dns-operations mailing list
<br><a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>
<br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a>
<br>dns-jobs mailing list
<br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a>
<br></div>
  <div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div 
style="display:table;width:100%;border-top:1px solid 
#EDEEF0;padding-top:5px">       <div 
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
 photoaddress="michoski@cisco.com" photoname="Mike Hoskins (michoski)" 
src="cid:part1.08070602.04040901@dnsbed.com" 
name="compose-unknown-contact.jpg" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:michoski@cisco.com" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Mike Hoskins (michoski)</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">2014年12月16日上午2:42</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody"><div>I hesitate to get involved
 in a holy war...but really huge +1 to this.<br>You have diversity, in a
 managed way.  It's not a silver bullet -- but<br>just like there have 
been times it made things worse, there have been<br>times when it made 
things better (buffer overflows that worked on one<br>architecture but 
not another is a common example where I've had personal<br>experience).<br><br>You
 can acknowledge things aren't a panacea, while still deriving some<br>benefits
 from them.  Monitoring/analytics (intelligence) is key, so the<br>operator
 can intelligently control flows across their services based on<br>risks
 and observed threats.<br><br>-----Original Message-----<br>From: Warren
 Kumari <a class="moz-txt-link-rfc2396E" href="mailto:warren@kumari.net"><warren@kumari.net></a><br>Date: Monday, December 15, 2014 at 
12:22 PM<br>To: David Conrad <a class="moz-txt-link-rfc2396E" href="mailto:drc@virtualized.org"><drc@virtualized.org></a><br>Cc: 
<a class="moz-txt-link-rfc2396E" href="mailto:dns-operations@lists.dns-oarc.net">"dns-operations@lists.dns-oarc.net"</a> <a class="moz-txt-link-rfc2396E" href="mailto:dns-operations@dns-oarc.net"><dns-operations@dns-oarc.net></a><br>Subject:
 Re: [dns-operations] knot-dns<br><br></div><div><!----><br><br>_______________________________________________<br>dns-operations
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>dns-jobs
 mailing list<br><a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br></div></div>
  <div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div 
style="display:table;width:100%;border-top:1px solid 
#EDEEF0;padding-top:5px">       <div 
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
 photoaddress="warren@kumari.net" photoname="Warren Kumari" 
src="cid:part1.08070602.04040901@dnsbed.com" 
name="compose-unknown-contact.jpg" height="25px" width="25px"></div>   <div
 
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
        <a moz-do-not-send="true" href="mailto:warren@kumari.net" 
style="color:#737F92 
!important;padding-right:6px;font-weight:bold;text-decoration:none 
!important;">Warren Kumari</a></div>   <div 
style="display:table-cell;white-space:nowrap;vertical-align:middle;">   
  <font color="#9FA2A5"><span style="padding-left:6px">2014年12月16日上午1:22</span></font></div></div></div>
  <div style="color:#888888;margin-left:24px;margin-right:24px;" 
__pbrmquotes="true" class="__pbConvBody"><pre wrap="">On Sun, Dec 14, 2014 at 5:47 PM, David Conrad <a class="moz-txt-link-rfc2396E" href="mailto:drc@virtualized.org"><drc@virtualized.org></a> wrote:
</pre><blockquote type="cite"><pre wrap="">Hi,

I'm having a bit of trouble believing this isn't April 1.

On Dec 14, 2014, at 10:38 AM, Florian Weimer <a class="moz-txt-link-rfc2396E" href="mailto:fw@deneb.enyo.de"><fw@deneb.enyo.de></a> wrote:
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">While it sounds good on phosphor, the concept of code diversity is so
abstract, compared to the significant operational challenges and
associated security challenges of operating separate systems
performing the same functions (sort of), but differently, that any
potential benefit is generally outweighed by the negative impact to
security posture of said challenges.
</pre></blockquote></blockquote><pre wrap="">Sorry, this is simply wrong.

A monoculture invites catastrophic failure. We've seen this over and over again.

Sure, there are a wide variety of other possible failure points, but it would be simply insane to (say) have everyone run the exact same code base would mean that everyone is subject to the same Packet-of-Death.

Are you seriously arguing that it is better to have your entire infrastructure subject to a PoD because it's a bit more challenging to run different software bases?

</pre><blockquote type="cite"><pre wrap="">In particular, running different implementations behind a load
balancer on the same public IP address can break EDNS detection by
resolvers, and crafted queries sent to a resolver can make data
unavailable to that resolver (until a timeout occurs).
</pre></blockquote><pre wrap="">Huh?

If you're running multiple implementations behind a load balancer and one is not following the protocol specifications such that it breaks EDNS detection, the answer is to fix the broken resolver or run a different resolver that responds correctly, not run an identical code base.
</pre></blockquote><pre wrap=""><!---->


.... or run a different load-balancing algorithm. There are multiple
ways to do this, but having the load-balancer hash only on src ip and
dst ip means that you should have the same client hitting the same
backends.


Then again, it all depends on why you are running a load-balancer - a
number of which become very sad with lots of short UDP sessions, and
fall over way before a raw server. If you are "load-balancing" to
optimize uptime, a nice options is:

ns1.example.com
ns2.example.com
ns3.example.com
ns4.exmaple.com

Each of ns[1-4].example.com is a different IP and is "load-balanced"
behind a router.  Each of the instances contains multiple machines,
and each machine announces that fact that it is alive and answering
queries by announcing itself into OSPF (with e.g ospfd and a tiny
health-check script).

ns1 run BIND and NSD. The BIND boxes announce themselves into OSPF
with a cost of 10, the NSD boxes announce themselves with a cost of
100.
ns2 run NSD and knot. The NSD boxes have a cost of 10, the knot a cost of 100
ns3 run yadifa and BIND. The yadifa have a cost of 10, the BIND 100.
ns4 run NSD and BIND. The NSD cost 10, the BIND 100.

OSPF doesn't do equal cost, and so the "primary" name server software
at each location gets all the traffic, unless it fails, at which time
the backup takes over. There can be multiple of the same type machine
at each location, routers are more than happy to ECMP down 16 paths
with no issue.

There is a small Python script that takes zone serving information and
outputs the correct stanzas for each nameserver type, and
[puppet|chef|ansible|salt|rsync|nfs|ssh] to propagate to all the
boxes.
Built basically this at multiple places. You need a few extra boxes,
but they are a: cheap and b: used for other stuff when not primary.

"A host is a host from coast to coast
But no one will talk to a host that's close
Unless of course the host that's close is busy, hung, or dead."
    - sung to the Mr Ed tune.


W


</pre><blockquote type="cite"><pre wrap="">Regards,
-drc


_______________________________________________
dns-operations mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a>
<a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a>
dns-jobs mailing list
<a class="moz-txt-link-freetext" href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a>
</pre></blockquote><pre wrap=""><!---->


</pre></div>
</blockquote>
<br>
<div class="moz-signature">-- <br>Best Regards,<br>


<a href="http://www.dnsbed.com/">DNSbed Hosting</a><br>


<br>

</div>
</body></html>