On 27. 11. 19 9:53, Ondřej Surý wrote: > Mark, > > I believe that any distributed system that won’t have a fallback to the RZ > is inevitably doomed and will get out of sync. > > The RFC7706 works because there’s always a safe guard and if the resolver > is unable to use mirrored zone, it will go to the origin. > > Call me a pessimist, but I’ve yet to see a loosely often neglected > distributed system > that won’t get out of sync. > > So, while the idea of distributing the full RZ to every resolver out there, > there are two > fundamental problems: > > 1. resilience - both against DoS and just plain breakage > 2. the old clients - while the situation out there is getting better, we will > still be stuck with > old codebase for foreseeable future > > What we can do is to make the load on RZ servers lighter, but we can’t make > them just go.
I think there is even more fundamental problem: Someone has to pay operational costs of "the new system". Personally I do not see how transition to another root-zone-distribution system solves the over-provisioning problem - the new system still has to be ready to absorm absurdly large DDoS attacks. Example: Have a look at https://www.knot-dns.cz/benchmark/ . The numbers in charts at bottom of the page show that a *single server machine* is able to reply *all* steady state queries for the root today. Sure, we have speed-of-light limits, so let's say we need couple hunderd servers in well connected places to keep reasonable latency. That's not a huge cost overall (keep in mind that these local nodes could be pretty small *if we were ignoring the over-provisioning problem*). Most of the money is today spent on *massive* over-provisioning. As an practical example, CZ TLD is over-provisiong factor is in order of *hunderds* of stead-state query traffic, and the root might have even more. Once we have similarly resilient HTTP system it is matter of simple configuration :-D https://knot-resolver.readthedocs.io/en/stable/modules.html#cache-prefilling -- Petr Špaček @ CZ.NIC _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
