On Mon, Jul 8, 2019 at 11:47 AM Witold Krecicki <w...@isc.org> wrote:
> 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. > 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?) > > What about using namespace instead of class or rrtype, or perhaps in addition to that? By making it an in-band thing but out-of-name-space, it makes it a little more difficult to achieve self-immolation. The namespace could be specified as having local-only significance, and putting it under a single parent name lets you manage it all however you want, including potentially in a single zone. E.g. zone "my.example.com.cover.t", or "example.com.covert.", or even "covert.". Protect *that* with TSIG etc., or possibly also use DNSSEC and/or ZONEMD for extra goodness. Maybe add it to the registry of special purpose names? Basically, if a query is seen on it, drop it, unless the query is AXFR/IXFR. Using the namespace allows you to break it up into subzones, e.g. to correspond to delegated or managed zones, where the transfer tree differs. Or not, if you don't have that particular use case to handle. Put it in a reserved TLD that is not delegated, and you should not expect any queries even by accident. Add whatever other magic your flavor of authoritative servers supports for limiting queries etc., and you're golden. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
