Re: [DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
John, thanks for the review. > On Oct 28, 2021, at 6:42 AM, John Scudder via Datatracker > wrote: > > > > -- > COMMENT: > -- > > Thanks for the well-written document! > > A few comments -- > > 1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to > update the Standards Track documents in question. If I had a better option to > offer at this stage in the document's history, I would, but under the > circumstances I don't. If we had it to do over again, my preference would have > been to progress a small PS to update the Standards Track documents, and a BCP > to provide all the rest of the content. In addition to the points Ben made, my > discomfort also stems from the fact that the advice regarding implementations > has inherently short shelf life (relatively speaking) whereas the updates are > forever (or at least until the updated documents are bis'd). > I'm not requesting any change with this observation, just putting it out > there for discussion (without making it a DISCUSS...). > > 2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part > seemed especially loosy-goosy to me as written, as to what precisely is > updated > in RFC 1536. The flow of the prose is nice, but the conclusion is less than > clear. I do think some rewrite of this section would be helpful. Here’s how this part reads now: Lastly, Section 1 of [RFC1536] is updated to eliminate the misconception that TCP is only useful for zone transfers: OLD: DNS implements the classic request-response scheme of client- server interaction. UDP is, therefore, the chosen protocol for communication though TCP is used for zone transfers. NEW: DNS implements the classic request-response scheme of client- server interaction. > 3. Section 6 says applications should perform “full TCP segment reassembly”. > What does that mean? A quick google search doesn’t suggest it’s a well-known > term of art. I'm guessing that what you mean is that the applications should > capture (and log, etc) the bytestream that was segmented and transmitted by > TCP? This has been updated as follows: Applications that capture network packets (e.g., with libpcap [libpcap]) SHOULD implement and perform full TCP stream reassembly and analyze the reassembled stream instead of the individual packets. Otherwise, they are vulnerable to network evasion attacks [phrack]. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Hi Éric, thank you for the review! > On Oct 28, 2021, at 5:33 AM, Éric Vyncke via Datatracker > wrote: > > -- > COMMENT: > -- > > Thank you for the work put into this document. > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education), and some nits. > > Special thanks to Suzanne Woolf for the shepherd's write-up about the WG > consensus. > > Thank you also to Ron Bonica for the shortest (1 line) but positive review for > the Internet directorate: > https://secure-web.cisco.com/1jbJkhQyobZfJSmvsaMZeoGFdhMnstIYcTFajo1Q4Vr-CbsR5S5e8mFYoGc-Ne9ghqsEhgK0G36DyJQe-ZnMVNwjxMjwV2g6LrwwY3sO9ts9qb1jzShVafaFTeaFWakKikXfnicx4aEdtORvqF6TNyIcc8g4cNlNvptkD3jJ61pxlER2WobXcqR7pcPaFTKdUQ7vKOcrRa9jHgDA4i7G3dkRcQlA2JVoyMrj9Z9XtWB0ij4N4jL3a_wVh5-P4-gkJ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Freview-ietf-dnsop-dns-tcp-requirements-13-intdir-telechat-bonica-2021-10-26%2F > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > I would have expected a little more about anycast DNS servers as TCP is > probably a no-go for those servers. I see only one mention of anycast in the > whole document. RFC 7766 (which is the implementation requirements companion to this one) already says this about anycast: Long-lived TCP connections to anycast servers might be disrupted due to routing changes. Clients utilizing TCP for DNS need to always be prepared to re-establish connections or otherwise retry outstanding queries. It might also be possible for Multipath TCP [RFC6824] to allow a server to hand a connection over from the anycast address to a unicast address. IMO it doesn’t necessarily need to be repeated but there is probably no harm in doing so if there is consensus it is a good idea. > > -- Section 2.3 -- > To be honest, I smiled when reading "For example, as of 2014, DNS over TCP" in > 2021 ;-) > > -- Section 2.4 -- > The qualitative approach about IPv6 fragmentation makes me wonder about the > sources of this paragraph. > > Still about IPv6 fragmentation, while "hence is unable to fragment and re-send > anyway" is most probably correct, the originating host should populate its > Path > MTU cache for the destination. So, it is not that bad. This section has been rewritten based on feedback from others and your comment here. Does this look better now? For IPv6, the situation is a little more complicated. First, IPv6 headers are 40 bytes (versus 20 without options in IPv4). Second, approximately one third of DNS recursive resolvers use the minimum MTU of 1280 bytes [APNIC]. Third, fragmentation in IPv6 can only be done by the host originating the datagram. The need to fragment is conveyed in an ICMPv6 "packet too big" message. The originating host indicates a fragmented datagram with IPv6 extension headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 extension headers to be blocked by middleboxes. According to [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to receive a fragmented IPv6 packet. When the originating host receives a signal that fragmentation is required, it is expected to populate its Path MTU cache for that destination. The application, then, will retry the query after a timeout since the host does not generally retain copies of messages sent over UDP for potential retransmission. > > == NITS == > > -- Section 3 -- > While I appreciate 2nd degree, I wonder whether "serious" should really be > part > of "Furthermore, there has been serious research" Agreed. I’ve removed “serious” > > -- Section 4.4 -- > Should the DoT acronym be used ? My slight preference is to spell it out but I would defer to the working group and the RFC editor. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
> On 5 Nov 2021, at 3:19 pm, Olafur Gudmundsson wrote: > > Publishing iteration count higher than 10 is reckless as that affects the > performance of recursive resolvers in particular the ones that run on small > CPE equipment. > > The document should strongly discourage any use of NSEC3 > For the that want to keep using it the limit should be real low of > what resolvers accept. > Any value between 0 and 10 is fine with me I hope to see some hint of consensus at the meeting, but would like to mention, that a realistic *aggressive* target would 20 rather than 10. There are >0.5M zones with 20 iterations, and it is likely too much work for insufficient gain to get them to reduce this to 10 or less. If the WG consensus it to go *aggressive*, then the limit should I suggest be 20. Other plausible values that non-trivially reduce impact are 40, 50 and 100. The multiple-choice question for the recommended resolver limits (highest accepted, not lowest rejected) is then: A. 20 B. 40 C. 50 D. 100 E. 150 And as for SERVFAIL, note that wildcard responses are often NSEC3 authenticated, so they'd stop working in zones over the SERVFAIL limit. Therefore, I think the choices here are more limited, unless we're planning to hold off resolver implementation until many more zones make changes post publication of the RFC. In the short run, the realistic upper bounds before SERVFAIL are: A. 150 (More stringent current de facto limit) B. 500 (Raytheon special) C. Never(Carrot sans stick) If some zones don't care that they're now insecure, we can report their DoE and wildcards as insecure, and hope they'll eventually care. Meanwhile, their positive answers still validate, but can be freely replaced with an insecure NODATA (zone apex) or any insecure answer (positive, NODATA or NXDOMAIN) at any qname properly below the zone apex. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
Publishing iteration count higher than 10 is reckless as that affects the performance of recursive resolvers in particular the ones that run on small CPE equipment. The document should strongly discourage any use of NSEC3 For the that want to keep using it the limit should be real low of what resolvers accept. Any value between 0 and 10 is fine with me Olafur > On Nov 5, 2021, at 12:09 PM, Benno Overeinder wrote: > > Wes, > > On 05/11/2021 09:40, Vladimír Čunát wrote: >> On 04/11/2021 23.44, Wes Hardaker wrote: >>> The most important sticking point is there are 4 implementations (thank >>> you for the links Matthijs) that have implemented 150. Since DNSOP >>> strives for implementations of specs, I think this is the number we >>> should publish*unless the vendors speak up and say they'll drive lower*. >> I'm convinced that 150 was just a quick stop-gap compromise and that from >> the start vendors expected that dnsop might set it lower later. Therefore I >> don't think this *argument* for keeping 150 is really valid. >> As for Knot Resolver, I see no problem in setting the hard limit lower, >> especially if that gets published in this RFC. From Viktor I gather that >> 100 shouldn't cause issues even at this moment, especially if it's only a >> limit for downgrading to insecure (which won't be even noticed by most DNS >> consumers). So personally I expected the draft to lower the bound to <=100, >> though as I said... for us the *overall* performance ratio from e.g. 150 -> >> 50 isn't that large. > > For Unbound, we have no problem setting the iteration cap to a value lower > than the current 150. If Viktor's analysis shows a limit of 100 is feasible > without (m)any problems for operators, and this value will be adopted in the > soon-to-be-released RFC, we will use the new limit value. > > > Cheers, > > -- Benno > > > -- > Benno J. Overeinder > NLnet Labs > https://www.nlnetlabs.nl/ > > ___ > 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] 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] nsec3-parameters opinions gathered
Wes, On 05/11/2021 09:40, Vladimír Čunát wrote: On 04/11/2021 23.44, Wes Hardaker wrote: The most important sticking point is there are 4 implementations (thank you for the links Matthijs) that have implemented 150. Since DNSOP strives for implementations of specs, I think this is the number we should publish*unless the vendors speak up and say they'll drive lower*. I'm convinced that 150 was just a quick stop-gap compromise and that from the start vendors expected that dnsop might set it lower later. Therefore I don't think this *argument* for keeping 150 is really valid. As for Knot Resolver, I see no problem in setting the hard limit lower, especially if that gets published in this RFC. From Viktor I gather that 100 shouldn't cause issues even at this moment, especially if it's only a limit for downgrading to insecure (which won't be even noticed by most DNS consumers). So personally I expected the draft to lower the bound to <=100, though as I said... for us the *overall* performance ratio from e.g. 150 -> 50 isn't that large. For Unbound, we have no problem setting the iteration cap to a value lower than the current 150. If Viktor's analysis shows a limit of 100 is feasible without (m)any problems for operators, and this value will be adopted in the soon-to-be-released RFC, we will use the new limit value. Cheers, -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
On 04/11/2021 23.44, Wes Hardaker wrote: The most important sticking point is there are 4 implementations (thank you for the links Matthijs) that have implemented 150. Since DNSOP strives for implementations of specs, I think this is the number we should publish*unless the vendors speak up and say they'll drive lower*. I'm convinced that 150 was just a quick stop-gap compromise and that from the start vendors expected that dnsop might set it lower later. Therefore I don't think this *argument* for keeping 150 is really valid. As for Knot Resolver, I see no problem in setting the hard limit lower, especially if that gets published in this RFC. From Viktor I gather that 100 shouldn't cause issues even at this moment, especially if it's only a limit for downgrading to insecure (which won't be even noticed by most DNS consumers). So personally I expected the draft to lower the bound to <=100, though as I said... for us the *overall* performance ratio from e.g. 150 -> 50 isn't that large. I'm not sure how low a "SERVFAIL limit" could go, though. (And I probably won't bring other stuff like salt into this thread.) --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] nsec3-parameters opinions gathered
[ Quoting in "[DNSOP] nsec3-parameters opinions g..." ] I was waiting for the last discussion to die down (and then, um, for me to finally examine the opinions). The results are in from the people that weighed in: | who | wants | accepts| |--+---+| | Peter van Dijk | 0 | anything low | | Matthijs Mekking | 150 | 150 -- vendors implemented | | Miek Gieben | 100 | or lower | | Paul Vixie | 0 || | Vladimír Čunát | any || | Viktor Dukhovni | 0 | 100 or 150 | I think the consensus is "everyone wants low", but most are willing to accept any value up to 150. To update, my 'wants' would actually be 0. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
