> 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. I'll probably regret this, but what about a COVERT class, instead type RR type? 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. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
