On 8/9/18, 20:24, "DNSOP on behalf of Paul Wouters" <dnsop-boun...@ietf.org on behalf of p...@nohats.ca> wrote:
>The point was to allow redistribution and to not depend on a trusted source That, FWIW, is the heart of DNSSEC. Source authentication and data integrity for data sets is the advertised goal (as well as provable non-existence) of the extensions. The DNS is not a strict client-server protocol, there is no telling what path a resource record (set) would take from the zone administrator to the would-be validating receiver. Originally the set of paths included authoritative servers, forwarding servers, recursive servers, iterative servers, and such down to the point where DNSSEC validation could no longer be done. (Originally, CPU horsepower and reliable libraries weren't assumed to me on end devices, hence the stub resolvers aren't included. No reason they couldn't, no reason applications can't validate, except for performance/trust anchor management concerns.) Now we are envisioning the transfer of zones in bulk, not just single datasets, via non-port 53 means. But is that any different? Does it really matter whether RSYNC of a zone was used to get a dataset from A to B? There is a concern I can see. When a server is loaded from disk (secondary storage), it does not validate the DNSSEC records to save time. There's a risk that a maliciously inserted zone version be loaded and served, possible if the channel security is defeated. But, if that happens, validating recipients of data sets will fail the data sets that are altered. While this could be a denial of service for the server, but DNS provides fallback to other servers so relying parties are just as protected as they ordinarily are (including, no DNSSEC, no protection...). How realistic is it that a forged zone could defeat all of the channel security for a zone? How likely would it be for someone to load a false zone on all the places a recursive server would look for it? Answering that would be a crucial step in deciding whether to add a zone hash mechanism. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
