On Friday, 19 June 2020 01:50:13 UTC Davey Song wrote: > Dear Paul, > > On Wed, 17 Jun 2020 at 00:03, Paul Vixie <p...@redbarn.org> wrote: > > as you know, synchronizing the root zone (RFC 7706) solves almost > > none of the problem of occasional connectivity, since so many other > > NS, DS, glue, key, and signature data are needed in-cache to continue > > retrieving other answers during times of disconnectivity. we (you) > > should do this. > > I guess you mean providing an alternative resolution path for occasional > disconnectivity on the path between the authority server and the resolver, > #2 is one approach, right?
i don't think so. what i'm interested in is the situation where a host desiring to discover and reach some service, and that service, and the DNS content needed to discover that service, are all on the same side of a discontinuity. discoverability and reachability should be continuous. this would naturally fall into two units of protocol development. first, the DNS metadata (NS, DS, DNSKEY, A/AAAA glue for NS) discovered during times when the whole DNS infrastructure (roots, TLD servers, SLD servers if any, and so on) are reachable, should be retained in a form very similar to IXFR/NOTIFY. think of this as a "hidden secondary" at the RRset level rather than at the zone level. this method relies on normal operations to help discover normally needed DNS metadata, and then keep it in cache. i should be able to reach the servers in my house even when the fiber has been cut, and i should not have to use LLMNR or similar protocols to make that possible. similarly, an island nation should be able to reach its entire electronic economy even if a shark has eaten the last undersea cable. this should not require that copies of all relevant DNS infrastructure be served inside that economy -- for example some new zealand web services are in .COM or .NET or elsewhere, and while it's possible to have a hidden secondary for NZ and CO.NZ, it's not possible to have hidden secondaries for all possible zones. the system must be able to opportunistically discover the "necessary" DNS infrastructure, and keep this data in-cache at an RRset granularity, and to make sure that this "leased RRset" can be invalidated by a secure transaction from the containing authority zone. so, that's a lot of data, and a lot of traffic. it wasn't practical until recently but it _is_ practical. second, we should employ IP multicast or similar announcement technology so that zone authorities whether primary or secondary, and whether published or hidden, can become known by local validating recursive iterative DNS servers. this is a harder problem than the early opportunistic discovery approach, because we don't know how to define "local" properly. however, i'd like to be able to reboot my entire network during times of upstream discontinuity, and still be able to discover and reach all services on my side of the fiber cut. also, i'd like to be able to operate a fully disconnected network without having to create my own fake "root zone" to delegate my own names to my own servers inside my disconnected network. this wasn't practical without DNSSEC, but it _is_ practical. > > it's long been known that ECS is a privacy nightmare; we must obsolete it > > and also > > erase set-associativity currently available by non-anycasted RDNS servers. > > What do you mean by set-associativity of non-anycasted RDNS servers? set-associativity means the authority server's opportunity to guess the topologic location of the stub resolver by examining the recursive server's uplink address. that's the original sin that led to ECS when RDNS anycast first became popular. authority servers should answer the questions they're asked, without topological favoritism. the 1.1.1.1 service does not speak ECS, yet the CDN world has not melted down. we can now move beyond not just ECS, but the privacy-violating original presumptions that ECS was based on. see also: https://queue.acm.org/detail.cfm?id=1647302 > Again, thank you for your comments and support. i hope this work continues. i'd like to see these problems solved, correctly and scalably, within my lifetime. -- Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
