> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to