You are welcome. I think, modulo minor differences in terminology, we are saying pretty much the same thing. pragmatically, DNS infrastructure dependencies can not be maintained and work on data resiliency is where the useful work lies.
/Wm On Thu, Feb 14, 2019 at 5:51 PM Paul Vixie <p...@redbarn.org> wrote: > > > william manning wrote on 2019-02-14 17:35: > > so, you would like the DNS to be resilient enough to "see" what was > > topologically reachable and build a connected graph of those assets? > > no. that's not possible, and not desireable in any case. > > > I think that has been done, both academically and in a more limited way, > > commercially, but its not called DNS so as not to upset the DNS mafia. > > Or do you want something more restrictive than that? > > i want the metadata i need to reach and trust assets on my side of any > connectivity loss event, to be kept in warm storage, and made subject to > trusted invalidation on an opportunistic basis, at the discretion of the > authority operators who own the data i have warm copies of. > > in practice this means DS/NS and DNSKEY/RRSIG and AAAA/A from my static > trust anchor(s) down to any data i used recently or frequently (or by > some other priority scheme), and i want it to look a bit like the single > transaction mode of IXFR plus the single transaction mode of NOTIFY. > > no topology information as to actual connectivity will be modeled or > estimated or needed. what matters is whether i can still reach all > internet resources on my side of a break in connectivity (whether local > or regional or distant), without needing any information that's > otherwise only available on the far side of the connectivity break. > > thanks for asking; i am happy to clarify. DNS infrastructure should not > be centralized, even if its content remains centrally coordinated by > ICANN. (block chain people keep telling me that ICANN will be obsolete, > but i'm not taking a position on that, only on data resiliency.) > > -- > P Vixie > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
