The DNS has had that for ~2 decades now. KEY records provide that. You need a
administrator to add a KEY record. They authorise future changes by signing
them with the private part of the key record using SIG(0). This exists in products
TODAY. The same can also be done with TSIG but requires different key management.
zone example.com {
type master;
file “master.db”;
update-policy {
grant * self . [type list];
grant admin-key zone .;
};
};
If you want to allow prefix labels you use selfsub instead of self.
zone example.com {
type master;
file “master.db”;
update-policy {
grant * selfsub . [type list];
grant admin-key zone .;
};
};
If the update comes in validly signed with foobar.example.com then in the
first example anything at foobar.example.com can be changed subject to the
type list. In the second anything at or below foobar.example.com can be
changed.
RFC 3007 - Secure Domain Name System (DNS) Dynamic Update + a way to specify
policy.
Mark
> On 12 Mar 2019, at 10:10 am, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
>
> See subject:
>
> Self-service tooling requires fine-grained authz -- it's NOT about
> the application protocol.
>
> 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".
>
> After all, similar things could be said of LDAP.
>
> This is bound to happen over and over until this sinks it:
>
> - it's not easy to manage if there's no self-service tooling
>
> - self-service tooling requires fine-grained authorization
>
> - self-service tooling requires delegation of authorization[*]
>
> - no self-service tooling -> helpdesks
>
>
> Nico
>
> [*] Delegation of authorization == the ability to grant the ability to
> grant to others.
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
