4 ms·

> While IPv6 and DNSSEC are more complex than some alternatives I'm not sure what you are getting at. IPv6 is pretty similar to IPv4 - and in some ways simpler

• wahern 8y ago
  I intended them as general examples of people pushing against certain kinds of change in favor of simpler short-term options that favor or preserve centralization and complexity. I agree IPv6 does make many things simpler, but moving to IPv6 can be difficult and introduces some additional complexity (e.g. link-local addresses, shift away from DHCP, etc). The argument against IPv6 is that NAT is simpler if only because NAT is already the status quo, and we already have "solutions" to deal with the limits of small address spaces. How many people use Cilium with IPv6 transport instead of UDP over IPv4 over VXLAN?[1] Local DNSSEC doesn't solve ISP confidentiality but it does prevent NXDOMAIN substitutions, which is one of the biggest immediate benefits for browser-based, default-enabled DoH/DoT. And one argument for doing DoH/DoT to centralized servers rather than locally is that it partly obviates the need for DNSSEC--it's "simpler" because it doesn't depend on orchestrating larger infrastructure changes. (I guess the logic is that without DNSSEC centralization is inevitable anyhow, and if people are convinced that ubiquitous DNSSEC will never come than doing DoH/DoT in the browser vs at the system resolver is a distinction without a difference. A poor argument but implicit nonetheless.) [1] At work I suggested Cilium with IPv6 and IPsec for policy and LAN confidentiality of K8S clusters but everybody thought I was nuts and favored Cilium's UDP+IPv4+VXLAN mode and transparent Istio proxies for automagic mutual TLS. Why? Because it's what they know and understand and they can reasonably expect everybody else will make the same judgment. It's ultimately a much more complex, error prone, less performant, and less flexible approach but it's the path of least resistance. And in the long-term the complexity will mean proprietary managed solutions will prove that much more enticing, an irony apparently invisible to people who believe K8S will keep them independent of AWS, Azure, etc,
  • dagenix 8y ago
    I don't have much to say regarding your work issue with IPv6 and a K8S cluster. However, I do have some comments regarding DNSSEC: As I understand it, there you have basically 3 options for local DNS w/ DNSSEC - 1) you can run a local recursive resolver, such as BIND; 2) You can use a non-validating stub resolver which requires that you trust the the recursive resolver you use _and_ the channel to the resolver; or 3) You can use a validating stub resolver. The problem with option 3, is that I don't believe it's possible to do DNSSEC validation for a record without fetching a bunch of parent records - so you end up running something that looks a lot like a recursive resolver with a cache, so, its really not clear to me why someone would do this over option 1. Anyway, that basically leaves you with two options: a recursive DNS server or you have to trust the recursive server that you do use and the channel to the server. While its fine to run your own recursive server if you want to, there are legit reasons someone (such as myself) wouldn't want to - its another service to manage and it may not perform as well as a shared cache in a recursive server someone else is maintaining. What that leaves me with, is that I want to use a non-validating stub resolver and I suspect that is true for most people as well. Unfortunately, as DNS traffic is not encrypted, when I use a non-validating stub resolver, it's easy for anyone that can eaves drop on my traffic can log where I'm going. Anyone that can modify traffic, can send me whatever responses they want. It doesn't matter if the domain I request is protected by DNSSEC if someone in the middle sends me back a bogus response that my resolver has no way to verify. DoH actually works alongside DNSSEC in some situations - by encrypting the channel between my stub resolver and a validating recursive resolver, it means that DNSSEC validation can't be easily stripped out by someone that controls whatever local network I'm connected to. Even with a local validating recursive resolver, you have little protection against NXDOMAIN substitutions and the like unless the domain you are talking to has DNSSEC enabled. However, DNSSEC is being slowly deployed and, in my opinion, it's very unclear if it will ever get to 100%. Unless it does, something like DoH still has value in protecting users from interference on the local network for non-DNSSEC domains. My points: I don't think that a Local DNSSEC resolver running on everyone's computer is realistic; DoH actually benefits DNSSEC by securing the channel between a stub resolver and a validating recursive resolver. Sources: https://tools.ietf.org/html/rfc4033#page-12 https://tools.ietf.org/html/rfc4033#page-12 https://lwn.net/Articles/665055/ https://lwn.net/Articles/665055/