Re: [dns-operations] knot-dns

+2 Roland Dobbins 2014?12?16???7:48 On 16 Dec 2014, at 6:25, Edward Lewis wrote: +1 --- Roland Dobbins ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-

Re: [dns-operations] knot-dns

On 16 Dec 2014, at 6:25, Edward Lewis wrote: 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 +1 --- Roland Dobbins ___

Re: [dns-operations] knot-dns

Hi drc! On Dec 14, 2014, at 6:51 PM, David Conrad wrote: > If you built out your customer resolver cloud with a set of Nominum servers > and Unbound servers behind load balancers, would the resolver bug being > discussed have taken out your infrastructure? > > Do you believe managing the conf

Re: [dns-operations] knot-dns

On 12/15/14, 14:40, someone wrote: >My point is that the negatives far outweigh the benefits in most >organizations. 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 operat

Re: [dns-operations] OARC's DNS Reply Size Test Server is not EDNS compliant

On 12/14/2014 11:45 AM, Keith Mitchell wrote: > On 12/13/2014 04:30 PM, Mark Andrews wrote: >> >> OARC's DNS Reply Size Test Server is not EDNS compliant. It does >> not return a OPT record to EDNS requests. This causes named from >> BIND 9.10.0 and later to classify the servers as not EDNS >>

Re: [dns-operations] knot-dns

On 12/15/2014 02:40 PM, Roland Dobbins wrote: > > 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. It

Re: [dns-operations] knot-dns

On 16 Dec 2014, at 0:56, David Conrad wrote: You appear to be suggesting that the Internet is so broken that taking steps to minimize single points of failure in your own infrastructure is pointless. Not at all. That is a gross mischaracterization and overgeneralization of what I've said.

Re: [dns-operations] knot-dns

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

Re: [dns-operations] knot-dns

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

Re: [dns-operations] knot-dns

On Mon, Dec 15, 2014 at 06:05:26AM +0700, Roland Dobbins wrote: > said vendor's perspective, I'm here to tell you that all this preaching > about avoiding monoculture is a sideshow compared to the real issues faced > every day in the trenches. > > If we could ever get to the point where a monocult

Re: [dns-operations] knot-dns

Roland, I am suggesting that when building out infrastructure, it is prudent to try to minimize single points of failure. One such single point of failure is reliance on a software monoculture. You appear to be suggesting that the Internet is so broken that taking steps to minimize single po

Re: [dns-operations] knot-dns

Florian, On Dec 14, 2014, at 10:55 PM, Florian Weimer wrote: > When you aim for diversity, you get the union of all bugs, not the > intersection. In the sense that some portion of your infrastructure may be affected by all bugs, sure. The point is that _all_ your infrastructure won't be aff

Re: [dns-operations] knot-dns

On Sun, Dec 14, 2014 at 5:47 PM, David Conrad 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 wrote: >>> While it sounds good on phosphor, the concept of code diversity is so >>> abstract, compared to the significant oper

Re: [dns-operations] knot-dns

Hi all, On 15/12/14 12:03, Tony Finch wrote: >> 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 o

Re: [dns-operations] knot-dns

> On 15 Dec 2014, at 02:45, David Conrad > wrote: > > >> And 'a bit more challenging' is a significant understatement, especially at >> scale. > > Too bad no one has come up with something like Puppet, Chef, Ansible, etc., > to help manage infrastructure configur

Re: [dns-operations] knot-dns

Florian Weimer wrote: > > 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). I would be inter