On 17 July 2016 at 11:45, Ray Bellis <[email protected]> wrote: > > It's *definitely* intended for TCP. > > > I found myself wondering how the server is meant to initiate SS > > messages to the client in a UDP context where the client is behind a > > NAT, for example. > > On that particular note - see the first paragraph of the "Protocol > Details" section. Since UDP doesn't provide the required guarantee it's > implicitly not suitable. >
Fair enough. On my first read I was thinking that it's a reasonable interpretation that unicast UDP meets the requirements, as stated in the first paragraph of ยง3. The client couldn't guarantee it, but the server could have enough information about whether and what type of load balancing is in use in its environment to make that guarantee. Thinking about it further though, I realize that the server wouldn't know for sure whether the client is behind a NAT, and then the "guarantee" requirement is out the window. I still think it would be helpful to be a little more explicit about it. > I think it would *not* be suitable for DNS with Cookies, since that has > an expectation that server farms could share cookie state, and I think > it would be onerous to expect any other "session state" to be shared > across farms. > I agree. Even if session state could be reliably shared across servers within a farm, or across multiple farms, you're still looking at setting up a new session if the individual server the client is in contact with becomes unavailable. The client has no way of knowing the architecture behind the IP address it's reconnecting to, and so shared session state on the server end would require additional negotiation to make sure that the new server and the old client still agree on whatever state was shared previously. You have similar issues if the client end is also a farm initiating queries from behind some sort of NAT or load balancer. It quickly gets more complex than simply renegotiating session state. > > > I'm also wondering if wouldn't be possible to implement this in a > > more backward-compatible way. I anticipate a lot of people who don't > > even intend to capture SS messages having to update their code > > anyway, because the messages won't be automatically discarded and > > will confuse parsers that attempt to analyze them. On the other > > hand, I am wiling to discuss the merits of advancing the expectation > > that the message format could change with the opcode. > > I've had feedback from both ends of the spectrum - some would like to > use an RR, others would like a completely clean break. > > Personally, I think the 12-octet header with what should appear as > "trailing garbage" is a fair compromise. I've written plenty of DNS > packet parsing code myself that I know would do "interesting things" if > the octets used for the section counts had "odd" data in them, but never > any that would reject a packet outright if there was stuff tacked on the > end. > Perhaps I'm misreading it, but this sounds like an argument in favour of an RR-based format. If the packet isn't rejected, and the software does odd things with unexpected data, then that's a problem that requires recoding to avoid corrupting or polluting whatever the output of the analysis is. However, as much as we admonish middleware boxes for thinking they know what to expect in the DNS, and doing bad things when it no longer looks that way, perhaps we should learn the same lesson and only select packets with opcodes that we know we know how to analyze correctly.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
