W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:>> On Jul 8, 2019, at 9:20 AM, Joe Abley <[email protected]> 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. We tried to include as many safeguards as possible, but I don't think we'd ever be able to avoid footie-shootie. I'd just add a section in "Security consideration" with summary of the issues stated above.
> I'll probably regret this, but what about a COVERT class, instead type RR > type?But then a) we'll end up with a dual-class zones b) nobody would implement it, as I don't think anything but BIND supports classes other than IN (correct me if I'm wrong?) Witold _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
