W dniu 08.07.2019 o 19:20, Wessels, Duane pisze: > > >> On Jul 8, 2019, at 9:20 AM, Joe Abley <jab...@hopcount.ca> wrote: >> >> >> As far as this particular idea goes, I mentioned before what had given me >> pause: we're talking about taking a protocol where every RRSet in a zone to >> date has been public and is made available in DNS responses. Any server that >> doesn't implement this new mechanism would presumably treat the new covert >> RRTypes as they would any other unknown/opaque type and make the data public. >> >> There is hence an operational risk that data will leak (e.g. by >> configuration changes, software downgrades that are pragmatic necessities, >> side systems that publish zone data in ways other than the DNS). >> >> By keeping data that is already exchanged over a (manual) out-of-band >> channel separate, and not packaging them up with zone data, the existing >> segregation of private vs. public is preserved and the task is simply to >> automate a process that is currently manual. > > I share this concern raised by Joe. I agree that it can be useful to > exchange configuration/provisioning data this way, but leaks seem almost > inevitable as proposed.
One more thing - this feature is intended for operators, not for regular users. We should have more tolerance for shootfooting features there. > With respect to 2.6. Interaction with ZONEMD, I'd think it should follow > handling of DNSSEC. That is, covert types should not be included in a zone > digest. As I understand ZONEMD main purpose is to verify the full content of the zone, mainly for zone transfer. In that case, I'd include COVERT records - as the clients who can transfer the zone using XFR will also be able to transfer COVERT records. (but I'm not stuck to that opinion). Witold _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
