> On Apr 19, 2021, at 9:34 AM, Peter van Dijk <[email protected]> > wrote: > >> This message starts the Working Group Last Call for >> draft-ietf-dnsop-tcp-requirements >> (https://secure-web.cisco.com/1GUztR-Nd5B-MpjncjmDNOnqlKoeK5-09UeTvbL1dFyQqc0x3GpwWIzNUMvS9B4MsWztiWQY9T4fEg5m6LLL1pIw6mIP3Glh5Dv0eS5QuBH0_Er0tAvzCWC4zQmflkrgxR33_ZI_bjrpDA44xWmAs5GaN2Xu6HgIlfNUxBYXJzJjwsgJ_xviwCeTT7debqaByK_Oko0XxsVpateA6jVRS5dByfqyYMX03JeB_kJbfBGxtfsoWTcBVWSYTpsCG7_KrY8EWi3H9J7_369rrwCogbQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-tcp-requirements%2F) > > This is a good document. > > One comment here: > > The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept > filter" feature ([accept_filter]) that postpones delivery of TCP > connections to applications until a complete, valid request has been > received. The dns_accf(9) filter ensures that a valid DNS message > is received. If not, the bogus connection never reaches the > application. Applications must be coded and configured to make use > of this filter. > > While it's good to point out that this feature exists, I do not think > mandating it makes sense - implementers and operators might have other > preferences for handling open-but-as-yet-unused TCP connections. (Also > the lowercase 'must' is confusing.)
It was not intended as a requirement, but rather to note that the application
needs to do some work to utilize them. Hows this?
These features are implemented as low-level socket options.
It is necessary for applications to be specifically coded and
configured to make use of them.
> Suggested extra text:
>
>> The Linux TCP_DEFER_ACCEPT feature, while more limited in scope, can
> provide some of the same benefits as the BSD accept filter feature.
Added, thanks.
DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
