On 03/06/2015 17:22, Joe Abley wrote: > On 3 Jun 2015, at 17:17, Shane Kerr wrote: > >> On Wed, 03 Jun 2015 13:57:39 +0100 >> Ray Bellis <[email protected]> wrote: >> >>> Whilst discussing 5966-bis with my co-authors connection-close with the >>> co-authors, we were reminded of this point I made in >>> draft-bellis-dnsop-connection-close in relation to ยง7 of RFC 6891: >>> >>> " TODO: note - the constraint in RFC 6891 appears unnecessarily strict >>> - it appears to mandate that the EDNS(0) support indication is on a >>> per-request basis, but it would be reasonable on a connection- >>> orientated transport to assume that ANY preceding request on that >>> connection with an OPT RR is sufficient to indicate that the client >>> supports EDNS(0)." >>> >>> Is this something that the WG believes needs to be fixed? >> >> The potential benefit is that a client could omit the OPT RR on >> subsequent messages? Seems a relatively small benefit, and there are >> costs. (Are there other benefits?) > > I agree. > > I think there's a baked-in expectation that OPT pseudo-RR is included in > every DNS message, not on every connection (where the transport is > connection-oriented).
The use case we are considering is that absent an OPT RR in each request, RFC 6891 doesn't permit the server to unilaterally send back an OPT RR in a response (e.g. for connection signalling purposes) even it one was previously seen on the same persistent connection. Furthermore if the specification of a particular OPT code requires that it only be sent when received from the client then that must also apply *per message*. We're not saying this is wrong, but in the context of a persistent connection that could be quite an overhead and if necessary we should explicitly document this with full awareness of the potential consequences. It seems that EDNS is not an entirely suitable mechanism for *connection* related signalling and it's this issue that we're trying to find a solution to. kind regards, Ray _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
