Hi Philip, Are you suggesting that web servers can't be massively scaleable? I'm not sure I understand your examples.
You cite overprovisionoing in the root server system as a reason not to try and supplement it, but I think it makes sense to look at it the other way round -- if there were ways to distribute the root zone reliably and accurately without presenting the attack targets that the root server system does, the need for continued investment in the infrastructure could be reduced (or the effective benefit to end-users from that investment could be increased). The bandwidth available at the consumer edge, where a lot of the attack sources now live, continues to grow far faster than the bandwidth that can be provisioned at the root server edge. The observation that "there's enough bandwidth that we're safe" doesn't seem future-proof (it doesn't even seem present-proof, really). For "root server system" also read "publishing system for any zone that people care about" -- the root server system is just a handy example. Joe On Jul 31, 2018, at 05:44, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: >>> The draft states in the Motivation section: >>> >>> "The motivation and design of this protocol enhancement is tied to the >> DNS root zone [InterNIC]." >> >> That may be a motivation, but as a prospective user I want to use >> it for much more. My LocalRoot server is already going to be >> serving 3 zones, and I have plans for many more. It would be >> helpful to know that on the distribution side of things that I had >> indeed grabbed an authentic source before sending it off to all >> the resolvers that want to pre-cache a random zone X. >> >> Be careful that we don't collectively interpret the sentence you >> quote as meaning 'this is only useful for the root zone' just >> because that was the original motivation. > > I think there is a big difference between distributing the root zone and > distributing a few 'local' zones. > > In the first case you need something that is massively scalable. > > In the second case, just create a tar file with a zone file and a hash, put > it up on a web server and the problem is solved. Verifying the contents of a > file is not exactly a new problem. > > I wonder if there still is a use case for distributing the root zone. With > QNAME minimization and NXDOMAIN based on NSEC records, the major use cases > seem to be gone. Compared to other zones, the root is massively over > provisioned. So if (from an availability point of view) there is need to have > a local copy of the root, then you would need a local copy of .com as well. > > Though I'm sure that are people who want to reinvent DNSSEC. > > One final remark, maybe it is worth investigating a 'NSDEL' record type, > and possibly 'ADEL' and 'AAAADEL'. Which are the equivalents of NS, A, AAAA > for delegations/glue. With separate record types, we can define that they are > covered by a RRSIG. Solving issues with data not being signed. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
