Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?
>That aim doesn't seem consistent with the statement that the >proxy won't be trusted with DNSSEC validation. That way you >still need a rather complex DNS code, ideally in a library. >And you'll need to query to stub for extra records to form the >whole chain, so that you even can validate. Overall I don't >advise splitting DNSSEC validation away from the other stub work >- cache in particular. Also because of the mechanisms that you >want to happen in case validation fails. It seems to me that there are basically two cases: 1) The application does not depend on the security of the lookup. For example, a lookup that is used in a TLS connection. In this case, the proxy could do DNSSEC validation or leave it to the upstream resolver. 2) The DNS lookup is security sensitive, for example a DANE lookup. In my option, the application should do local DNSSEC validation and not trust either the proxy or the upstream resolver. If that requires the application to have a cache as well, then that is just part of the implementation of local DNSSEC validation. My experience with the getdns library, is that local DNSSEC validation can work quite well without a local cache. In my opinion the complexity of local DNSSEC validations comes from application requirements. This complexity will exist with or without a local proxy. If consensus among application/library developers is that DANE lookups can rely on DNSSEC validation done by a local proxy, then obviously, we can change the wording in the draft. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?
On 19/10/2022 10.06, Philip Homburg wrote: And then we end up with potentially many different implementations in applications, which seems worse to me. That aim doesn't seem consistent with the statement that the proxy won't be trusted with DNSSEC validation. That way you still need a rather complex DNS code, ideally in a library. And you'll need to query to stub for extra records to form the whole chain, so that you even can validate. Overall I don't advise splitting DNSSEC validation away from the other stub work - cache in particular. Also because of the mechanisms that you want to happen in case validation fails. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?
>OK. I suppose I'm stuck in the model of (at least) machine-wide >policies, thinking that it would be really messy if each app >chooses properties of their DNS separately. (Which sounds more >like a job for a library API anyway.) The goal is to move the implementation of the various DNS upstreams (DoT, DoH, DoQ, etc) to the proxy while keeping the stub resolver in the application in control. The division of labour between the application and the stub resolver is outside the scope of the draft. The draft focusses on mechanism. It allows the stub resolver to default to the system setting, and for example only require an encrypted transport. Or the application can take full control and specify exactly which upstreams should be used. I don't think every application should choose properties of their DNS. However, if we don't provide the mechanism, then people will just extend stub resolvers to give applications more control. And then we end up with potentially many different implementations in applications, which seems worse to me. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?
OK. I suppose I'm stuck in the model of (at least) machine-wide policies, thinking that it would be really messy if each app chooses properties of their DNS separately. (Which sounds more like a job for a library API anyway.)___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?
> The DNSOP WG chairs welcome feedback on the draft > draft-homburg-add-codcp, Control Options For DNS Client Proxies > ([1]https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). > >I find it a bit weird for a client to *choose* how the proxy/resolver >might connect to upstream, even choosing an IP address set. >And for each request separately. The goal of the draft is to give a stub resolver the same control over a local proxy as the stub resolver has when it connects to upstream resolvers directly. In most cases, stub resolvers just use systems defaults (usually in /etc/resolv.conf). But in quite a few cases, applications want to deviate from that. For example, Firefox allows the user to specify which DoH provider is used. To keep the system simple, we opted to include the proxy control option in every request. We assume that a connection to localhost is high speed and does not have MTU issues. The alternative would be to have a stateful session between the stub resolver and the local proxy. That deviates quite a bit from how stub resolvers work today. >Moreover, I fail to understand motivation for the caching part >- tagging by properties of transport. If an answer is cached, >what are the privacy concerns? No further connection to upstream >is made for that request anyway. The assumption is that in general, different upstream resolvers may give different answers. The obvious case is if one upstream goes out directly to the internet and another goes through a company VPN. To avoid confusion, the cache should keep those answers separate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-homburg-add-codcp potential new work for WG?
On 17/10/2022 23.28, Benno Overeinder wrote: The DNSOP WG chairs welcome feedback on the draft draft-homburg-add-codcp, Control Options For DNS Client Proxies (https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). I find it a bit weird for a client to *choose* how the proxy/resolver might connect to upstream, even choosing an IP address set. And for each request separately. Moreover, I fail to understand motivation for the caching part - tagging by properties of transport. If an answer is cached, what are the privacy concerns? No further connection to upstream is made for that request anyway. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-homburg-add-codcp potential new work for WG?
Dear WG, The DNSOP WG chairs welcome feedback on the draft draft-homburg-add-codcp, Control Options For DNS Client Proxies (https://datatracker.ietf.org/doc/draft-homburg-add-codcp/). The draft was submitted to the ADD WG for discussion and review, but the WG chairs and the int area AD considered it work outside the ADD WG charter. However, the WG chairs of ADD and DNSOP and the ADs of both WGs regard this draft as relevant work. Individuals in the IETF also showed interest and saw the value of the draft. The chairs are seeking feedback from the DNSOP WG whether this work can be discussed in the WG. The chairs of the DNS-related WGs see no other working group where the draft can be presented, while we prefer to let the work go through the IETF process via a WG. Best regards, -- Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
