On 3/11/19 7:10 PM, Nico Williams wrote:
See subject:
Self-service tooling requires fine-grained authz -- it's NOT about
the application protocol.
Unless, of course, the application protocol constrains the granularity
of authentication. But I don't think that's the case for DNS update.
If someone says "let's put this config data in DNS" and someone responds
"DNS is too difficult to manage", the answer isn't necessarily "let's
invent a new protocol".
Agree in principle. But while authentication granularity isn't really a
problem with DNS update (as far as I know), there are other problems
with DNS update that might best be fixed by protocol tweaks.
Separately from that, there are other reasons why it might be
appropriate to consider migrating to a "DNS next generation"
protocol. Arguably this is already happening whether we want it or not.
There are several problems, some of which are interrelated. I am not
insistent that any of them be fixed by protocol changes, though I
suspect that some changes and/or new protocol work would be desirable.
I also suspect that some new tooling is desirable. I also suspect that
some policy changes might be appropriate. And perhaps some operational
recommendations.
There's a danger of trying to boil the ocean. There's also a danger of
thinking that some new tool will solve the problem, and scoping the
effort narrowly in terms of creating that new tool, when the new tool
that emerges years later only has the effect of moving the problem and
adding additional complexity to what's already Pandora's box.
At the moment I'm just trying to wrap my head around the problem, or to
put it another way, to discover what scope for the problem could result
in less overall complexity rather than more.
Keith
p.s. agree with your summary of self-service tooling requirements.
