On 12/06/2015 15:46, Paul Vixie wrote:
> 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. That would be ideal, yes. > 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". I think there's scope for a long argument on this last point. RFC 2671 (§4.1) says "OPT RRs shall never be ... forwarded". RFC 6891 is even more explicit in §6 about middleboxes. It's perhaps a shame that EDNS doesn't support the separation of "hop-by-hop" options vs "end-to-end" options that IPv6 has. To my mind proxy_dns is absolutely non-conformant, but clearly *some* EDNS options may be safely forwarded whilst others shouldn't be. However without a separation in the option number space (or a brand new OPT-alike RR) there's no way for an implementation to know without it being hard-coded for each then-known option. > 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. If only that were existing _conformant_ speakers ;-) > 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. The issue with that (and potentially anything else we might come up with) is that there's no guarantee *whatever we write* that some naive non-conformant implementation will find a way to forward the magic sequence. kind regards, Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
