On 8/13/18, 11:50, "John Levine" <jo...@taugh.com> wrote: >As we may have mentioned once or twice before in this discussion, it lets you >do zone transfers over insecure channels and batch verify the zone before >using it.
Yes, I see that. As in no more argument is needed to convince me of that. >but the obvious consumer is a DNS server. Maybe, maybe not. I've seen DNS used in turnkey ways. Nevertheless, given the complexity of DNSSEC validation, a wise implementer should re-use the parts of a DNS server for this. (I.e., there's a lot of wacky stuff out there. See "DNS Zone Transfer Protocol (AXFR)", Definition of Terms section [RFC 5936, Sec. 1.1] definitions of "General-purpose DNS implementation" and "Turnkey DNS implementation. I've run across a lot of weird stuff in my studies of responder behavior [shuddering to think of these beasts as servers ;) ].) >it'd be nice to be able to check that the zone is correct and get notified of >failure There are many existing tools for such a set up. For one, use a VPN or in-band channel security, and/or make sure the zone file received matches the zone file sent. (If you use AXFR, which can only run on TCP, make sure the first and last resource record are the SOA. If you use RSYNC, use other filesystem checks - like file size for one.) I think the use case is the "we'll put the zone on some third party server and let others [the second party] retrieve it" - that's where you would want an end-to-end "secure" set up. This is where my "belts and suspenders" comment comes in, if whatever uses data sets from the zone as transferred will do DNSSEC validation on the sets, what's the need for a signed "checksum" of the whole zone? What is the relying party does not do validation? In essence, what would do DNSSEC validation for the ZONEMD and not for data sets within the zone? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
