[dns-operations] knot-dns

Tue Dec 16 00:55:15 UTC 2014

+2

> Roland Dobbins <mailto:rdobbins at arbor.net>
> 2014?12?16???7:48
>
> On 16 Dec 2014, at 6:25, Edward Lewis wrote:
>
>
> +1
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> Edward Lewis <mailto:edward.lewis at icann.org>
> 2014?12?16???7:25
>
> The problem with broad generalizations is that they are always wrong.
>
> (Meant as a joke.)
>
> I skimmed this thread now and then and thought about my experience in
> building and operating systems. Ever since "The Cuckoo's Egg" - as far as
> I know - "genetic code diversity" has been a fad. It got woven into a lot
> of requirements. Having spent a long time inside operators, I've seen
> this become more of an albatross than a "good idea."
>
> If I am operating a system supporting external customers, homogeneity is a
> benefit.
>
> If I am operating a system for my own benefit, heterogeneity is a benefit.
>
> My recommendation for a service provider stick with one code base and
> learn to run it well. My recommendation for a customer of such a provider
> use two or more service providers.
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> Roland Dobbins <mailto:rdobbins at arbor.net>
> 2014?12?16???3:40
>
> On 16 Dec 2014, at 1:42, Mike Hoskins (michoski) wrote:
>
>> You can acknowledge things aren't a panacea, while still deriving 
>> some benefits from them.
>
> My point is that the negatives far outweigh the benefits in most 
> organizations.
>
>> Monitoring/analytics (intelligence) is key, so the operator can 
>> intelligently control flows across their services based on risks and 
>> observed threats.
>
> Yes, I'm a big advocate of this - but it's honored more in the breach 
> than in the observance, all in all.
>
> 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.
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> Mike Hoskins (michoski) <mailto:michoski at cisco.com>
> 2014?12?16???2:42
> I hesitate to get involved in a holy war...but really huge +1 to this.
> You have diversity, in a managed way. It's not a silver bullet -- but
> just like there have been times it made things worse, there have been
> times when it made things better (buffer overflows that worked on one
> architecture but not another is a common example where I've had personal
> experience).
>
> You can acknowledge things aren't a panacea, while still deriving some
> benefits from them. Monitoring/analytics (intelligence) is key, so the
> operator can intelligently control flows across their services based on
> risks and observed threats.
>
> -----Original Message-----
> From: Warren Kumari <warren at kumari.net>
> Date: Monday, December 15, 2014 at 12:22 PM
> To: David Conrad <drc at virtualized.org>
> Cc: "dns-operations at lists.dns-oarc.net" <dns-operations at dns-oarc.net>
> Subject: Re: [dns-operations] knot-dns
>
>
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> Warren Kumari <mailto:warren at kumari.net>
> 2014?12?16???1:22
> On Sun, Dec 14, 2014 at 5:47 PM, David Conrad<drc at virtualized.org>  wrote:
>> Hi,
>>
>> I'm having a bit of trouble believing this isn't April 1.
>>
>> On Dec 14, 2014, at 10:38 AM, Florian Weimer<fw at deneb.enyo.de>  wrote:
>>>> 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.
>> 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?
>>
>>> 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).
>> 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.
>
>
>
> .... 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
>
>
>> Regards,
>> -drc
>>
>>
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-jobs mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
>
>

-- 
Best Regards,
DNSbed Hosting <http://www.dnsbed.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141216/7a2d17e7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141216/7a2d17e7/attachment.jpg>