Ray Bellis wrote: > ... > > 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.
connections weren't considered when EDNS was first described, nor when it was later redescribed. i think if you're specifying an option that refers to the connection (for example, to negotiate better "close" rules than is present in raw tcp/53 today) then any responder who acks your signal can be expected to know whether it can do so honestly and effectively. if the signal's meaning is "please change to these better 'close' rules for this tcp session" then the responder should be able to say "ok i changed to these better 'close' rules for this tcp session" without worrying about whether subsequent transactions in the same session repeat this negotiation. however, that's not the world we live in. consider for example proxy_dns (available as open source on https://github.com/BII-Lab/DNSoverHTTP) which is perfectly capable of carrying individual dns transactions over several parallel http(s) sessions, and to whom any new EDNS signalling will be opaque at least initially. this naive dns client only understands framing, not content, and it works. i think this naivety is likely present in some dns-aware load balancers as well. and i think that none of these are "broken" or in any way "noncompliant". furthermore, proxy-dns will use TCP on the regenerated far-end DNS transaction if it heard the original near-side DNS transaction via TCP. therefore even without multiplexing, putting a connection level negotiation into the OPT could make this TCP initiator ask (by opaquely carrying its payload) for something it doesn't understand and promise to do something it won't do. a rule of protocol evolution is, existing speakers should not become broken due to a spec change. so, connection semantics will have to be negotiated at the framing level not the content level. so, you might explore the use of a zero length request, which currently means nothing. vixie -- Paul Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
