W dniu 07.07.2019 o 01:46, Joe Abley pisze: > On Jul 6, 2019, at 19:28, Witold Krecicki <w...@isc.org> wrote: > >> Exactly - while the things you mentioned are configuration options that >> are 'human generated', the ZSK rollover should be, in the ideal case, >> something that happens automatically, without any human intervention. > > It wouldn't necessarily be harmful to be able to update those other > things automatically, too. Things like master servers and NOTIFY > targets perhaps change less frequently or predictably than a ZSK, but > in times of emergency all could benefit from a well-designed, > automated and secure mechanism to handle changes. > > TSIG secrets are rarely rolled in practice, in my experience, and > being able to improve upon that also seems useful. > > I still wonder whether what you're proposing really only solves one of > a wider set of problems, and whether doing it in the DNS really makes > sense. Perhaps a standardised, out-of-band provisioning protocol would > be better. > > We might have a need to exchange some other kind of metadata between > authoritative servers for a zone in the future, eg relating to secure > transports or privacy. The idea of being able to provide a general > solution to solve future such problems seems attractive. > But why put it out-of-band when it can be in-band? This draft is just an 'umbrella' - you can put whatever you want there, and you can be sure it won't be leaked. There can be a special RR type for master servers - in COVERT range, there can be a special RR type for TSIG keys - in COVERT range. It can be used for any type of metadata. Note: I'm considering adding a 'private' covert range, for implementation-specific things (just like we have a general 'private' RR types range).
-- Witold _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
