On Sun, Dec 14, 2014 at 5:47 PM, David Conrad <d...@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 <f...@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@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
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
dns-operations mailing list
dns-operations@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
