Hi Daniel, On Thu, Mar 19, 2020 at 11:16 AM Daniel Migault <[email protected]> wrote:
> Hi Ted, > > > > Thanks for the feed back. The dns uri scheme has the port optional and > provides port flexibility. > I believe the port is optional to include in any URI, but I believe support for a port is mandatory to implement. Are you aware of implementations that don't implement it? If we are using the port as an indication of the transport protocol, we are > losing this flexibility. A consequence is that is it would prevent using > other ports than non standard port. > I think it means there's a different trade-off. If you use an existing port in a non-standard way, this will fail (and that's pretty correct behavior in the face of squatting). If you use a non-standard port, you can use this mechanism to specify the port. The client would then need to attempt the connections with its preferred mechanism (for the TLS ones, using ALPN) and then decide whether to fall back to less-preferred methods if those are not available. I would strongly urge that preference go from most confidential transport to less confidential transports, but that would ultimately be a client decision. At least from my point of view, what you appear to want is configuration protocol, but neither what you specified nor the original is a DNS client configuration protocol. They primarily provide a reference to specific resource record data in the DNS, and this form: dns:www.example.com?clAsS=IN;tYpE=A looks like it ought to be the most common; it tells you the reference to a specific RR, without requiring you to get it from anywhere in particular. That works with whatever resolver you have configured, at least in the common case. The extended forms, which name or provide an address for a specific resolver are useful (e.g. for split DNS), but I think creating a bunch of different URI schemes to extend that to specify a protocol is more harmful than helpful, as you then have an equivalence problem. Are dot://server.example:2836/:www.example.com?clAsS=IN;tYpE=A and dns: www.example.com?clAsS=IN;tYpE=A presumed to be equivalent or not? What that suggests is, if you really believe the trade-off to focus on specific servers and non-standard ports is critical, that you should mint a single URI scheme for the purpose, with a mandatory paramater that lists the transports . I would personally still feel that was heading this in the wrong direction, but it would avoid some of the worst questions about equivalence. regards, Ted > My impression also is that some people are willing to deploy DoT or DoH on > non standard port, thought I might wrong. > > > > For DoH, my understanding is that URI is formed according to the URI > template. I think that being able to provide the path could be useful > especially when different paths will be associated to different service. > Maybe additional element may also be useful to add. I do not think the > current dns scheme enables this and I would be happy to have your thoughts > on it as I am not particularly familiar with uri template. > > > > Basically using the old dns uri, this would be something like: > > dns://host.example:443/dns-with-parental-protection/ > www.example.org?clAsS=IN;tYpE=A > > dns://host.example:443/dns-without-filtering/ > www.example.org?clAsS=IN;tYpE=A > > > > Yours, > > Daniel > > On Thu, Mar 19, 2020 at 1:44 PM Ted Hardie <[email protected]> wrote: > >> Hi Daniel, >> >> I'm not sure I understand the need here. The existing DNS URI scheme >> uses the standard authority semantics, so it permits a port. It seems >> like using that gives you the same semantics as these additional schemes. >> That is: >> >> dns://host.example:53/www.example.org.?clAsS=IN;tYpE=A >> >> dns://host.example:853/www.example.org.?clAsS=IN;tYpE=A >> >> dns://host.example:443/www.example.org.?clAsS=IN;tYpE=A >> >> seem to handle the cases where you need to specifically call out DNS is >> being served over traditional transports (UDP and TCP over 53), DoT, and >> DoH. >> >> What am I missing here? >> >> thanks, >> >> Ted >> >> On Thu, Mar 19, 2020 at 9:52 AM Daniel Migault <daniel.migault= >> [email protected]> wrote: >> >>> Hi, >>> >>> Please find a draft describes URIs that describes the DNS resource being >>> accessed through DNS53, DoT and DoH. >>> >>> Any comment / suggestions are welcome. >>> >>> Yours, >>> Daniel >>> >>> -----Original Message----- >>> From: [email protected] <[email protected]> >>> Sent: mercredi 18 mars 2020 22:57 >>> To: Daniel Migault <[email protected]> >>> Subject: New Version Notification for draft-mglt-dprive-dns-uri-00.txt >>> >>> >>> A new version of I-D, draft-mglt-dprive-dns-uri-00.txt has been >>> successfully submitted by Daniel Migault and posted to the IETF repository. >>> >>> Name: draft-mglt-dprive-dns-uri >>> Revision: 00 >>> Title: Domain Name System Uniform Resource Identifiers for DNS >>> over HTTPS and DNS over TLS >>> Document date: 2020-03-18 >>> Group: Individual Submission >>> Pages: 7 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-mglt-dprive-dns-uri-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-mglt-dprive-dns-uri/ >>> Htmlized: https://tools.ietf.org/html/draft-mglt-dprive-dns-uri-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-mglt-dprive-dns-uri >>> >>> >>> Abstract: >>> Today DNS resources may also be accessed using multiple transport >>> which includes DNS over UDP/TCP port 53 [RFC1034],[RFC1035]. DNS >>> over TLS [RFC7858] or DNS over HTTPS [RFC8484]. This document >>> describes URIs that describes the DNS resource as well as indicate >>> the transport to access the resource. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at >>> tools.ietf.org. >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> dns-privacy mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dns-privacy >>> >> _______________________________________________ >> dns-privacy mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dns-privacy >> > > > -- > Daniel Migault > Ericsson >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
