@ISC, we have been discussing this since we started implementing RZ local copy and it’s not that simple.
There are at least two problems with BitTorrent: a) the hash has to be independent to zone, so either the hash has to reside outside of the root zone, or the root zone file would have to be reconstructed with “the torrent hash” and “the torrent data”; generally you would want the hash to be signed, so the TORRENT RR + RRSIG would have to be distributed outside of the data received via BitTorrent b) to be effective, most of the peers would have to seed, and I am not sure if the places that would benefit the most would be the places where operators would be willing to seed Ondrej -- Ondřej Surý — ISC > On 27 Jul 2018, at 16:57, Bob Harold <rharo...@umich.edu> wrote: > > >> On Thu, Jul 26, 2018 at 11:07 PM Mark Andrews <ma...@isc.org> wrote: >> >> >> > On 27 Jul 2018, at 12:39 pm, Steve Crocker <st...@shinkuro.com> wrote: >> > >> > The passage below puzzles me. Why do you want servers to get the root >> > zone from less trusted sources? >> >> 1) to spread load. >> 2) not all recursive servers have direct access to authoritative sources. >> Some times they need to go through intermediaries. The same will be true >> with transfers of the root zone. > > Maybe I am wrong, but having lots of servers all around the world asking for > the same update at the same time looks like a good place to use bittorrent. > (Is that reasonable?) So the 'sources' will be untrusted, and we do need > some way to verify the resulting file that we get.. > > I like the XHASH idea, it seems to reduce the work required on each update.. > But I would be ok with ZONEMD also. > > -- > Bob Harold > >> > And why does the source matter if the zone entries are DNSSEC-signed? >> >> Steve please go and re-read the parts you cut out when quoting the previous >> message. It gave several reasons. >> >> Also please look at what is and isn’t signed in a zone and think about what >> can be done when you can change the unsigned parts. >> >> Also think about what can be done when you change the signed parts but don’t >> individually verify the RRsets but rather just trust the zone content. >> >> I have a local copy of the root zone. It lives in a seperate view which is >> not accessed directly by clients The name server validate its contents when >> performing recursive lookups on behalf of clients. Such configurations are >> complicated and error prone. It also doesn’t remove potential privacy leaks. >> >> Having a way to verify the entire zone’s contents without having to verify >> every RRset individually after each zone transfer would make running such >> configurations easier. It also removes threats that DNSSEC alone does not >> remove. >> >> > Thanks, >> > >> > Steve >> > >> > Sent from my iPhone >> > >> >> On Jul 26, 2018, at 7:33 PM, Mark Andrews <ma...@isc.org> wrote: >> >> >> >> Additionally most nameservers treat zone data as fully trusted. This is >> >> reasonable when you are getting data from a “trusted" source. For the >> >> root zone we want servers to be able to get a copy of the zone from a >> >> untrusted / less trusted source. >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > _______________________________________________ > 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
