On 27. 11. 19 21:49, David Conrad wrote: > Petr, > >> I think there is even more fundamental problem: >> Someone has to pay operational costs of "the new system”. > > The “new system” is simply the existing network of resolvers, augmented to > have the root zone. As far as I can tell, the operational cost would be in > (a) ensuring the resolver is upgraded to support obtaining the root zone and > (b) dealing with the fetch of the root zone with some frequency.
Oh, sorry, this is misunderstanding! My reference to "the new system" was meant to be "the new system for root zone distribution". Please let me try again: Even if "the new system for root zone distribution" is BitTorrent it still: - (most likely) needs a set of static IP addresses to solve the bootstrap problem, - trackers need to be highly resilient against DDoS, - trackers most likely need to be anycasted to limit scope of DDoS. I hypothetise that in the end requirements for "the new system for root zone distribution" will be fairly close to current requirements for current DNS root system... so I do not see where the cost reduction comes from. Or in other words: If current root system must survive 1 TB/s attack so must the "the new system for root zone distribution" system, unless we move to decenralized root. Changing one centralized system to another does not solve the fundamendal problem of costly-to-defent-single-point-of-failure. Hopefully it is clearer this time. Petr Špaček @ CZ.NIC > > There would be an additional cost, that of making the root zone available to > myriads of resolvers, but I believe this is an easily handled issue. > >> 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. > > Two ways: > - greater decentralization: there are a lot more resolvers than the number of > instances root server operators are likely to ever deploy. While an > individual resolver might melt down, the impact would only be the end users > using that resolver (and it is relatively easy for a resolver operator to add > more capacity, mitigate the attacking client, etc). > - the cost of operating and upgrade the service to deal with DDoS is > distributed to folks whose job it is to provide that service (namely the ISPs > or other network operators that run the resolvers). Remember that the root > server operators have day jobs, some of which are not particularly related to > running root service, and they are not (currently) being compensated for the > costs of providing root service. > >> 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. >> ... >> 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. > > Yep. As mentioned before, steady state is largely irrelevant. > > In my view, the fact that root service infrastructure funnels up to a > (logical) single point is an architectural flaw that may (assuming DDoS > attack capacity continues to grow at the current rate or even grows faster > with crappy IoT devices) put the root DNS service at risk. One of the > advantages of putting the root zone in the resolver is that it mitigates that > potential risk. > > Regards, > -drc > (Speaking for myself, not any organization I may be affiliated with) _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations