On Fri, Aug 2, 2019 at 2:18 PM Joe Abley <jab...@hopcount.ca> wrote: > On 2 Aug 2019, at 13:24, Witold Krecicki <w...@isc.org> wrote: > > > An implementation won't be able to load a covert RR from a masterfile > > because it won't understand it's TYPE field - it'd either be a specific > > COVERT type (which has to be supported to be loaded) or an opaque > > COVERTNNNNN - as a replacement for RFC3597 TYPENNNNN (it's not in the > > -00, I talked about it during presentation). > > Any implementation that doesn't ascribe special meaning to the range of > code-points you designate as covert will treat them as standard opaque > types. That's the point I'm trying to make. > > Further, loading zone data from a master file is just one (arguably > archaic) source of zone data. Anything that is received over the wire in an > [AI]XFR or an UPDATE is just a wire-format RR, for example, and there's no > useful precedent here for a nameserver having to distinguish between > different RRTypes when generating responses. The range of back-ends in use > today for provisioning RRSets to a master server is also far greater than > "master file", and I don't think it's reasonable to speculate about what > any/some/most/all of them might do. > > > We already have records that cannot be directly queried (NSEC5), > > implementations don't have any problems with not responding to direct > > NSEC5 queries. > > I would suggest that any implementation that doesn't support NSEC5 is in > fact very likely to respond to queries with QTYPE=NSEC5. > > > Thinking this way we should never use DNSSEC (or HTTPS) > > because a bug in implementation can cause private keys to leak. > > Private keys are not published as zone data, which I am suggesting. > > > Also, this mechanism is not backwards compatible - a server not > > supporting COVERT records won't be able, in any way, to serve a zone > > that has COVERT records > > I am suggesting that it will be able to serve those records perfectly > well. That's the crux of my concern, in fact.= > > >> I am not in favour of this proposal, which I think is camel abuse. > > Looking at what's happening recently at DNSOP everyone is abusing > > labeling everything they don't like a 'camel abuse', it's getting > > dangerously close to being just a pure insult... > > I certainly apologise if you took it that way; it was meant to be a > shorthand for describing my concerns and definitely not a cheap way to > discredit an idea. What I intended to mean by "camel abuse" is as follows: > > I think that modifying query-response behaviour with respect to specific > code points is expensive, and if it is to be done it needs to come with > commensurate benefits. I don't see those benefits in this case, as I have > described. For that reason I think the expense is not warranted. > > > Joe >
I am also concerned about data leaking, and special handling by the server. I just had what might be a crazy idea. What if the covert data was encrypted, and could be transferred normally, but only someone with the key could read it? It could then be put in a new record or in TXT records. Requires a tool (script) to read/write it, but no changes to the DNS servers. Does that make any sense? -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
