Hello Joe, W dniu 02.08.2019 o 18:28, Joe Abley pisze: > Hi Witold, > > On 2 Aug 2019, at 10:46, Witold Krecicki <w...@isc.org> wrote: > >> They should fail to load the zone as it will contain RRs that it does >> not understand. As long as they won't serve covert records to general >> public - I don't really care. > > Standard behaviour is to handle opaque types. You're speculating about the > broad range of possibly non-standard behaviour and deciding that anything > that is non-standard will exhibit one particular kind of behaviour. I think > that's the opposite of what we would normally attribute to "non-standard". 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). Yes, the operator can write a COVERT type as RFC3597 TYPENNNNN and load it into a server that does not support COVERT. Operator can also put his private DNSSEC keys into a TXT records - there always will be a chance of footshooting, no matter how perfect the standards or implementations.
> I continue to think that taking a protocol (DNS) and deployed implementations > (nameservers) that are designed to answer queries and trying to bolt on a > backwards-compatible mechanism for carrying data that is not exposed by > queries is just a recipe for data leakage. Any data that is really intended > not to be disclosed cannot use a mechanism that is almost guaranteed to leak, > which means that this proposed mechanism has no real use case. We already have records that cannot be directly queried (NSEC5), implementations don't have any problems with not responding to direct NSEC5 queries. Thinking this way we should never use DNSSEC (or HTTPS) because a bug in implementation can cause private keys to leak. 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 - it won't be able to load the zone (reasons stated above), it won't be able to transfer the zone from a COVERT-supporting primary (because it won't send COVERT-OK EDNS0) option, I'm thinking about putting a requirement that binary formats (bind9 mapfile/journal) must also be incompatible with non-COVERT-supporting versions. > 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... Witold _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
