Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
On Sat, Aug 3, 2019, at 01:04, Tim Wicinski wrote: > This starts a Call for Adoption for draft-sah-resolver-information I think that I might have said this before, but I don't think that asking an HTTP server about a DNS server is the right solution. If this is information about the operation of a participant in the DNS protocol, then I think that this needs to use the DNS protocol. For connection-oriented interactions, having the information associated with a connection (and not a server identity) would be even better. This also bakes in the notion that a DNS resolver is identified by IP address. The domain name part is probably OK, but I don't know which trust anchors to use. I think that the document is assuming that we'll use the Web PKI, but it doesn't say that (nor does RFC 8310, as far as I can tell). If you can answer the question "why not DANE?" then you might start to understand my concerns here. The RESINFO RRtype seems OK, but I have less confidence in my ability to assess that aspect of this. The only thing that bothers me is the potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the protocol for everyone. I realize that there are no good solutions here, but it would be good if there were a little more clarity on the constraints this group thought applied to the design. The inventory thing is fairly irregular. The names of fields are right there already, why insist on repeating them in an array? With all that, I think that it would be premature to assume that this is the right direction. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
Original message From: Joe Abley On 2 Aug 2019, at 15:30, Bob Harold wrote:>> 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?> To my eye (such as it is) Olafur is on the right track with this. This is a provisioning > problem, not a DNS problem.> I think it makes more sense to consider the zone as just one parameter in a DNS > workload; other parameters like master servers, zone-specific configuration, > NOTIFY lists, etc are additional parameters. Together they make up a blob > of DNS provisioning workload. I think the ability to include RRSet metadata > (comments, change history, authorisation, data provenance, whatever) in such a blob > is most simply a further deconstruction of the "zone" member of that blob.I had a very similar thought.Recently, I had an opportunity to set up some rather complex bind views where tsig's were needed to keep private views private while allowing multiple views to be transferred to the same host(s).It works rather well and could easily be rolled into something more general purpose./John> Joe___DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
On 2 Aug 2019, at 15:30, Bob Harold wrote: > 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? To my eye (such as it is) Olafur is on the right track with this. This is a provisioning problem, not a DNS problem. I think it makes more sense to consider the zone as just one parameter in a DNS workload; other parameters like master servers, zone-specific configuration, NOTIFY lists, etc are additional parameters. Together they make up a blob of DNS provisioning workload. I think the ability to include RRSet metadata (comments, change history, authorisation, data provenance, whatever) in such a blob is most simply a further deconstruction of the "zone" member of that blob. I do see the benefits of standardising DNS provisioning in general. I would love to be able to have a standard mechanism to add a blob such as that imagined above to an anycast cloud of authoritative DNS servers, for example, instead of having to jump through provider-specific flaming hoops of tickets and APIs. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
On Fri, Aug 2, 2019 at 2:18 PM Joe Abley wrote: > On 2 Aug 2019, at 13:24, Witold Krecicki 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 > > COVERTN - as a replacement for RFC3597 TYPEN (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
Re: [DNSOP] proposal: Covert in-band zone data
On 2 Aug 2019, at 13:24, Witold Krecicki 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 > COVERTN - as a replacement for RFC3597 TYPEN (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
Re: [DNSOP] proposal: Covert in-band zone data
Hello Joe, W dniu 02.08.2019 o 18:28, Joe Abley pisze: > Hi Witold, > > On 2 Aug 2019, at 10:46, Witold Krecicki 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 COVERTN - as a replacement for RFC3597 TYPEN (it's not in the -00, I talked about it during presentation). Yes, the operator can write a COVERT type as RFC3597 TYPEN 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
Re: [DNSOP] proposal: Covert in-band zone data
> On 31 Jul 2019, at 6:51 am, Dan Mahoney wrote: > > > > On Tue, 30 Jul 2019, Paul Ebersman wrote: > >> dmahoney> I'd be fine with this data ONLY living on the master, but >> dmahoney> having it survive things like named-compilezone or rndc >> dmahoney> freeze/thaw, or the slew of DDNS updates that things like ACME >> dmahoney> DNS-01 requires. >> >> dmahoney> Effectively, this would be an internal-only DNS record that >> dmahoney> had a database representation but NO defined wire-format, so >> dmahoney> there'd be little chance of snooping over the wire (absent >> dmahoney> some kind of memory leak in the DNS implementation). >> >> Gotcha. So presumably also only on hidden master if that's the >> architecture. >> >> And transfer of data with these super-comments would be done by file >> copy, not any DNS standard method? >> > > Correct. I do also envision a limited use-case for this feature where > BIND might also add a note indicating the source/time of a DDNS update. > But again, purely for humans, not for any action by the nameserver. > > One possible format might be: > > ;NOTE foo.bar.NOTE"pauls workstation” I would do it as '$NOTE ' rather than as a comment which gets mapped to “ 0 NOTE ”. This formalises the construct and wont accidentally covert any existing comments that start with “;NOTE “. > -Dan > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
Hi Witold, On 2 Aug 2019, at 10:46, Witold Krecicki 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". 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. I am not in favour of this proposal, which I think is camel abuse. Joe signature.asc Description: Message signed with OpenPGP ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
On Aug 2, 2019, at 10:59, Töma Gavrichenkov wrote: > And while we're at it, doesn't it make sense to (kinda proactively) > include some potential transports in the draft (like DoQ) to avoid RFC > one-liners in future? Even only to note later that those didn't see > widespread adoption afterwards. I think for the sake of all of our sanity our terminology documents should describe observed usage, not make speculative decisions on what to call things that nobody has yet needed a name for. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
Errata: On Fri, Aug 2, 2019, 5:59 PM Töma Gavrichenkov wrote: > Even only to note later that those didn't see > widespread adoption afterwards. > * "Even _if_ only ...", I'm not really that pessimistic. -- Töma > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption: draft-sah-resolver-information
This draft has come up and has had a lot of discussion. Mostly positive, some desiring more details on the information that could be returned. If the working group adopts the draft, this can all be worked out. This starts a Call for Adoption for draft-sah-resolver-information The draft is available here: https://datatracker.ietf.org/doc/draft-sah-resolver-information/ Please review this draft to see if you think it is suitable for adoption by DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends: 16 August 2019 Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
In favor of adoption. And while we're at it, doesn't it make sense to (kinda proactively) include some potential transports in the draft (like DoQ) to avoid RFC one-liners in future? Even only to note later that those didn't see widespread adoption afterwards. -- Töma On Thu, Aug 1, 2019 at 7:09 PM Tim Wicinski wrote: > > > Back in 2014, we started with "DNS Terminology" which became RFC7719 > Then In 2016, this became a BCP version of "DNS Terminology" which is now > RFC8499 > > Now, in 2109, there is a request to include additional terms to reflect > the new transports DNS is being used over.There is still discussion over > whether all these terms make sense, but the underlying need exists. > > This starts a Call for Adoption for draft-hoffman-dns-terminology-ter > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 15 August 2019 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
W dniu 02.08.2019 o 16:32, Paul Ebersman pisze: > ebersman> If what you're arguing for is something that's actually mixed > ebersman> into the zone data, how do you handle non-compatible/legacy > ebersman> and avoid leakage? > > wpk> non-compatible/legacy servers won't know the RRTypes that are > wpk> covert - and therefore won't be able to load them from disk. > > In a polite/sane implementation, sure. But I have scars from my years at > ISC tech support dealing with very broken implementations not done by > the usual FOSS DNS folks. They might fail to load the zone at all, might > stop loading and serve what they have, only serve what they recognize, > crash, etc. 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. Witold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
ebersman> If what you're arguing for is something that's actually mixed ebersman> into the zone data, how do you handle non-compatible/legacy ebersman> and avoid leakage? wpk> non-compatible/legacy servers won't know the RRTypes that are wpk> covert - and therefore won't be able to load them from disk. In a polite/sane implementation, sure. But I have scars from my years at ISC tech support dealing with very broken implementations not done by the usual FOSS DNS folks. They might fail to load the zone at all, might stop loading and serve what they have, only serve what they recognize, crash, etc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
On 8/1/19 6:08 PM, Tim Wicinski wrote: > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. I'm in favor of adoption. I'm not sure if it's a good idea to suggest content changes in this same thread already, but I suppose adoption itself will be easy to get consensus about. RDoT: I believe the wording should not exclude forwarding between two resolvers (when neither is really a stub). That seems actually a relatively common use case for DoT. --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
Yes, MR Hoffmann has been faster than me. again. Tim On Fri, Aug 2, 2019 at 9:08 AM Paul Wouters wrote: > On Thu, 1 Aug 2019, Tim Wicinski wrote: > > > With no hats, I agree with George that I still don't like Do53. > > The d053 term has already been removed after initial feedback during > the dnsop meeting :) > > Paul > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
On Thu, 1 Aug 2019, Tim Wicinski wrote: With no hats, I agree with George that I still don't like Do53. The d053 term has already been removed after initial feedback during the dnsop meeting :) Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] proposal: Covert in-band zone data
W dniu 30.07.2019 o 22:16, Paul Ebersman pisze: > If what you're arguing for is something that's actually mixed into the > zone data, how do you handle non-compatible/legacy and avoid leakage? non-compatible/legacy servers won't know the RRTypes that are covert - and therefore won't be able to load them from disk. Witold ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
