Both can be automated. The RFCs to support this are +20 years old. If people are to lazy to add the small amount of code to web servers to do this they only have themselves to blame. DNS servers have supported DNS UPDATE for decades and have rich policies to specify what can and can’t be updated. -- Mark Andrews > On 14 Sep 2023, at 03:47, Peter Thomassen <peter@xxxxxxxx> wrote: > > Phillip, > >> On 9/13/23 06:36, Phillip Hallam-Baker wrote: >> There is already a scheme to do what you want, problem is that it isn't quite documented in one place, you need SRV records, DNS service discovery RFC6763 AND the Well Known services hack. This is my attempt to bring that earlier work together: >> https://www.ietf.org/archive/id/draft-hallambaker-web-service-discovery-09.html <https://www.ietf.org/archive/id/draft-hallambaker-web-service-discovery-09.html> > [...] >> * All DNS entries are generated automatically and maintained by the service orchestration. > [...] >> Automating the DNS zone management is the key to making DNS based security policy practical. > > Quick summary: There's a proposal for secure service discovery, and it requires maintaining DNS entries automatically. > >> A system like DANE or Cert Pinning is fine in theory, in practice it falls apart if the administrator doesn't keep the DNS zone up to date and completely correct. Which isn't going to happen without automation. > Your proposal requires automation, too (see above). Why is it that DANE falls apart for lack of automation, while your proposal doesn't? > > Thanks, > Peter > > -- > https://desec.io/ >
