First of all, firewall vendors are changing their views on DNS. Lots of default blockage have gone and UPDATE is no more dangerous than QUERY. Checkpoint have removed their default QUERY blocks. Similarly Juniper have also remover their default blocks. If there are blocks on UPDATE they can similarly be removed. Nameservers that support UPDATE don’t need external protection. UPDATE has had fine grain authentication for 15+ years since the invention of TCP, TSIG and SIG(0). See update-policy in BIND for a example. TCP is still hard to spoof and is useful for some updates especially in the reverse tree. Mark -- Mark Andrews > On 10 Mar 2019, at 01:35, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > >> On 3/8/19 2:55 PM, Viktor Dukhovni wrote: >> >> The problem isn't DNS, it is that we lack a broadly applicable >> technology that most organizations can use to expose fine-grained >> access control for configuration data. > > That's an interesting observation and a constructive suggestion. I don't think it addresses the entire problem, but it definitely takes a stab at part of it. I also note that the lack of a recommended model for such access control, and lack of standards for DNS update that are broadly applicable, are part of that problem. (For instance, the fact that many routers intercept port 53 traffic and drop update requests means that you can't expect to fix the problem using port 53.) With the current situation, even if an enterprise adopts a DNS server product that provides such features, they're likely locked in to it, which itself becomes a barrier to widespread adoption. (Vendor lock-in stifles innovation.) > > Beyond those issues, I observe that many small networks don't bother with DNS because it's not understood and/or seen as too much trouble. Yes, LLMNR exists, but it's implemented differently from one platform to another, so you end up needing to use different names from different hosts to accomplish the same thing. I observe that when a network is intermittently-connected, behavior of applications using hostnames changes when connectivity changes, even when IP packets would be able to reach their intended destinations. I observe that lack of a broadly-applicable standard update protocol, along with failure of many registrars to support DNSSEC via their proprietary user interfaces, hinders adoption of both DNSSEC and other technologies that require it. I see DNS used as a means of access control, which is not only ineffective but also increases the tendency to centralize DNS. It isn't the fault of DNS itself that it's used this way, but it is arguably a failure of the architecture to address important user needs. I observe that it has now become common for various parties (not just border routers) to intercept DNS requests and falsify responses. In my opinion this should be regarded as fraud and legally actionable, but to some degree (not always) this is being done to address limitations in the architecture. (Arguing about whether those failures are "DNS's problem" seems unhelpful - and I would argue that our well-established practice of narrowly scoping discussions in order to reduce the appearance of tussles is one contributor to these architectural failures.) > > And so on. > > Keith > >
