another positive feature of ports in this record is that it provides some address space independent of the origin security model of the URI. By this I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555 are different origins with different web security boundaries. While two different httpssvc records for 443 and 555 (both for https:// www.foo.com) are in the same origin.. this level of indirection can be used for A/B testing or even for encoding load balancing information in a IP constrained space. Just like the address is distinct from the URL, the port separates the 'what' from the 'how' and that's good.
On Mon, Mar 9, 2020 at 10:42 PM Erik Nygren <erik+i...@nygren.org> wrote: > On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie <p...@redbarn.org> wrote: > >> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote: >> > It occurs to me that I hit "publish" on this draft without updating the >> > release notes, so I'll mention some of the many changes since -01 here >> > instead: >> > >> > ... >> > >> > As always, please review and send comments. We also expect to do a >> > presentation on this draft (remotely) in the DNSOP session. >> >> i propose that section 6.2 for "port", and all references to same, be >> removed. >> > > We discussed this some on one of our authors' calls following > my seeing you allude to this a few weeks ago. > > The rationale for keeping port is that HTTPS is not just about the "web" > use-case. > While for Web use-cases it is common for most things to always tcp/443, > there > are plenty of non-"Web" use-cases (such as API calls in data centers, > service meshes, etc.) > where non-standard ports are commonly used. I know that Tim keeps > highlighting > a desire to make sure we consider these use-cases. > > There's a default when port is left out (perhaps that should be clarified > better?) > but there are cases when being able to switch to an alternate port has > value. > Another case where this applies is QUIC/UDP where udp/443 is commonly > used but where operators may wish to situationally use different ports. > > Adding a warning that the use of non-default ports could have > operational challenges might be warranted. (There are also > some confused deputy risks around non-default ports for servers > that don't validate the port in the Host header, but others convinced > me that that's a problem for another day.) > > A closely related issue is this one: > > https://github.com/MikeBishop/dns-alt-svc/issues/111 > > (regarding clarifying the default port.) > > Does this help address the concern? > It's helpful to know the historical context. > > Erik > > > > > > >> this is: >> >> --- >> >> 6.2. "port" >> >> The "port" SvcParamKey defines the TCP or UDP port that should be >> used to contact this alternative service. >> >> The presentation format of the SvcParamValue is a numeric value >> between 0 and 65535 inclusive. Any other values (e.g. the empty >> value) are syntax errors. >> >> The wire format of the SvcParamValue is the corresponding 2 octet >> numeric value in network byte order. >> >> === >> >> in the SRV RR (from RFC 2782) we specified a port number as part of the >> RData >> because a client would otherwise have to have an up-to-date /etc/services >> file >> (or local equivalent) to know what (TCP) port number a listener would >> listen >> on, and this seemed archaic. >> >> for HTTPSSVC and SVCB, the service is a constant (HTTPS) and its >> transport >> layer port number (443) is known. inviting listener operators to specify >> a >> different port number will result in unpredictable (other than >> wide-spread) >> failures for those accessors behind NAT, firewalls, or ALG's. >> >> please leave out this legacy from DNS SRV as you go forward with HTTPSSVC. >> >> -- >> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
