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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
