Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
On Fri, Nov 5, 2021 at 10:02 AM Wessels, Duane wrote: > > > > On Nov 1, 2021, at 3:29 PM, Erik Kline wrote: > > > > Caution: This email originated from outside the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > > > >>> [S4.1, comment] > >>> > >>> * "Resolvers and other DNS clients should be aware that some servers > >>> might not be reachable over TCP. For this reason, clients MAY want > >>> to track and limit the number of TCP connections and connection > >>> attempts to a single server." > >>> > >>> I think the same comment could be made about paths to a server from > >>> a given network, e.g., in the case of one network filtering TCP/53 for > >>> some reason. > >>> > >>> I'm not sure how to best reword this to add a per-network notion to > >>> TCP connection success tracking, but I did want to note that a mobile > >>> client's measure of TCP connection success to a single server might > >>> vary from network to network. (for your consideration) > >> > >> Is this because mobile devices are more likely to have multiple network > choices (say wifi and cellular data) and so the device should include the > local network when remembering which works and which doesn’t? > > > > Yes, they have multiple networks simultaneously and also through time. > > What's reachable/unreachable on one network might not be > > reachable/unreachable on another. Just moving from one Wi-Fi SSID to > > another can make a difference, e.g.: > > > >* imagine two SSIDs that each hand out 8.8.8.8 but have different > > TCP 53 filtering policies, and > > > >* (more concretely) I have DNS-over-TLS active on my phone and on > > one nearby coffee shop SSID TCP 853 is blocked while on another > > everything works just fine > > > > (Hopefully I'm making some kind of sense.) > > Thanks Erik, how does this look to you? > >Resolvers and other DNS clients should be aware that some >servers might not be reachable over TCP. For this reason, clients >MAY track and limit the number of TCP connections and >connection attempts to a single server. Reachability problems >can be caused by network elements close to the server, close >to the client, or anywhere along the path between them. Mobile >clients that cache connection failures MAY do so on a per-network >basis, or MAY clear such a cache upon change of network. > > DW > > LGTM. s/MAY/SHOULD/g also LGTM (since I know some mobile OSes already do stuff like this) Thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
> On Nov 1, 2021, at 3:29 PM, Erik Kline wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > >>> [S4.1, comment] >>> >>> * "Resolvers and other DNS clients should be aware that some servers >>> might not be reachable over TCP. For this reason, clients MAY want >>> to track and limit the number of TCP connections and connection >>> attempts to a single server." >>> >>> I think the same comment could be made about paths to a server from >>> a given network, e.g., in the case of one network filtering TCP/53 for >>> some reason. >>> >>> I'm not sure how to best reword this to add a per-network notion to >>> TCP connection success tracking, but I did want to note that a mobile >>> client's measure of TCP connection success to a single server might >>> vary from network to network. (for your consideration) >> >> Is this because mobile devices are more likely to have multiple network >> choices (say wifi and cellular data) and so the device should include the >> local network when remembering which works and which doesn’t? > > Yes, they have multiple networks simultaneously and also through time. > What's reachable/unreachable on one network might not be > reachable/unreachable on another. Just moving from one Wi-Fi SSID to > another can make a difference, e.g.: > >* imagine two SSIDs that each hand out 8.8.8.8 but have different > TCP 53 filtering policies, and > >* (more concretely) I have DNS-over-TLS active on my phone and on > one nearby coffee shop SSID TCP 853 is blocked while on another > everything works just fine > > (Hopefully I'm making some kind of sense.) Thanks Erik, how does this look to you? Resolvers and other DNS clients should be aware that some servers might not be reachable over TCP. For this reason, clients MAY track and limit the number of TCP connections and connection attempts to a single server. Reachability problems can be caused by network elements close to the server, close to the client, or anywhere along the path between them. Mobile clients that cache connection failures MAY do so on a per-network basis, or MAY clear such a cache upon change of network. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
> > [S4.1, comment] > > > > * "Resolvers and other DNS clients should be aware that some servers > > might not be reachable over TCP. For this reason, clients MAY want > > to track and limit the number of TCP connections and connection > > attempts to a single server." > > > > I think the same comment could be made about paths to a server from > > a given network, e.g., in the case of one network filtering TCP/53 for > > some reason. > > > > I'm not sure how to best reword this to add a per-network notion to > > TCP connection success tracking, but I did want to note that a mobile > > client's measure of TCP connection success to a single server might > > vary from network to network. (for your consideration) > > Is this because mobile devices are more likely to have multiple network > choices (say wifi and cellular data) and so the device should include the > local network when remembering which works and which doesn’t? Yes, they have multiple networks simultaneously and also through time. What's reachable/unreachable on one network might not be reachable/unreachable on another. Just moving from one Wi-Fi SSID to another can make a difference, e.g.: * imagine two SSIDs that each hand out 8.8.8.8 but have different TCP 53 filtering policies, and * (more concretely) I have DNS-over-TLS active on my phone and on one nearby coffee shop SSID TCP 853 is blocked while on another everything works just fine (Hopefully I'm making some kind of sense.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Erik, thanks for the review > On Oct 26, 2021, at 1:09 PM, Erik Kline via Datatracker > wrote: > > > > -- > COMMENT: > -- > > [abstract vs. S1/S3, question] > > * The abstract says: > > "...strongly > encourages the operational practice of permitting DNS messages to be > carried over TCP" > > while section 1 says: > > "...all DNS resolvers and recursive > servers MUST support and service both TCP and UDP queries" > > and section 3 also some MUST text. > > Should the abstract be updated to say MUST rather than just > "strongly encourages", or is there a subtly in here I'm missing? Based on the suggestion from Ben, we’ve updated the text: This document updates RFC 1123 and RFC 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes > [S4.1, comment] > > * "Resolvers and other DNS clients should be aware that some servers > might not be reachable over TCP. For this reason, clients MAY want > to track and limit the number of TCP connections and connection > attempts to a single server." > > I think the same comment could be made about paths to a server from > a given network, e.g., in the case of one network filtering TCP/53 for > some reason. > > I'm not sure how to best reword this to add a per-network notion to > TCP connection success tracking, but I did want to note that a mobile > client's measure of TCP connection success to a single server might > vary from network to network. (for your consideration) Is this because mobile devices are more likely to have multiple network choices (say wifi and cellular data) and so the device should include the local network when remembering which works and which doesn’t? DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
On Tue, Oct 26, 2021 at 1:13 PM Benjamin Kaduk wrote: > On Tue, Oct 26, 2021 at 01:09:00PM -0700, Erik Kline via Datatracker wrote: > > Erik Kline has entered the following ballot position for > > draft-ietf-dnsop-dns-tcp-requirements-13: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ > > > > > > > > -- > > COMMENT: > > -- > > > > [abstract vs. S1/S3, question] > > > > * The abstract says: > > > >"...strongly > >encourages the operational practice of permitting DNS messages to be > >carried over TCP" > > > > while section 1 says: > > > >"...all DNS resolvers and recursive > >servers MUST support and service both TCP and UDP queries" > > > > and section 3 also some MUST text. > > > > Should the abstract be updated to say MUST rather than just > > "strongly encourages", or is there a subtly in here I'm missing? > > "require" might be better than "MUST", on the principle that if a given > requirement is stated in more than one place, there is risk of inadvertent > skew between what is actually stated; such skew can cause interoperability > failure or security vulnerabilities if different implementations use the > differing behaviors. > > -Ben > +1 sgtm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
On Tue, Oct 26, 2021 at 01:09:00PM -0700, Erik Kline via Datatracker wrote: > Erik Kline has entered the following ballot position for > draft-ietf-dnsop-dns-tcp-requirements-13: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ > > > > -- > COMMENT: > -- > > [abstract vs. S1/S3, question] > > * The abstract says: > >"...strongly >encourages the operational practice of permitting DNS messages to be >carried over TCP" > > while section 1 says: > >"...all DNS resolvers and recursive >servers MUST support and service both TCP and UDP queries" > > and section 3 also some MUST text. > > Should the abstract be updated to say MUST rather than just > "strongly encourages", or is there a subtly in here I'm missing? "require" might be better than "MUST", on the principle that if a given requirement is stated in more than one place, there is risk of inadvertent skew between what is actually stated; such skew can cause interoperability failure or security vulnerabilities if different implementations use the differing behaviors. -Ben > [S4.1, comment] > > * "Resolvers and other DNS clients should be aware that some servers >might not be reachable over TCP. For this reason, clients MAY want >to track and limit the number of TCP connections and connection >attempts to a single server." > > I think the same comment could be made about paths to a server from > a given network, e.g., in the case of one network filtering TCP/53 for > some reason. > > I'm not sure how to best reword this to add a per-network notion to > TCP connection success tracking, but I did want to note that a mobile > client's measure of TCP connection success to a single server might > vary from network to network. (for your consideration) > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ -- COMMENT: -- [abstract vs. S1/S3, question] * The abstract says: "...strongly encourages the operational practice of permitting DNS messages to be carried over TCP" while section 1 says: "...all DNS resolvers and recursive servers MUST support and service both TCP and UDP queries" and section 3 also some MUST text. Should the abstract be updated to say MUST rather than just "strongly encourages", or is there a subtly in here I'm missing? [S4.1, comment] * "Resolvers and other DNS clients should be aware that some servers might not be reachable over TCP. For this reason, clients MAY want to track and limit the number of TCP connections and connection attempts to a single server." I think the same comment could be made about paths to a server from a given network, e.g., in the case of one network filtering TCP/53 for some reason. I'm not sure how to best reword this to add a per-network notion to TCP connection success tracking, but I did want to note that a mobile client's measure of TCP connection success to a single server might vary from network to network. (for your consideration) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
