John Heidemann wrote: > On Sun, 26 Jul 2015 22:56:10 -0700, Paul Vixie wrote: >> John Heidemann wrote: >>> ... >>> >>> I have some ideas, but it seems premature to talk about handling UDP >>> queries until we have significant deployment experience with DNS-over-TCP. >>> I hope we will get there :-) >> that won't happen. or at any rate we should all we can to prevent it >> from happening. don't be alarmed-- what i mean is, until we have >> some idea what we'll do with parallel tcp sessions and what we'll do >> with concurrent udp transactions from the same initiator, we MUST NOT >> deploy, and we will therefore not garner any deployment experience. >> "build it first, secure it later" has not worked, ever, anywhere, for >> anybody. > > I'm sorry, I feel like I'm stuck in "bring me a rock". > > There's been plenty of discussion about how one can safely deploy > DNS-over-TCP (that is: security is not worse). That is not this thread.
please remind me what thread in what forum i should join in order to participate. > If you want to talk about transitioning UDP to TCP and sunsetting UDP, > that's a new topic. That's not "secure it later". it is, though. dns protocol agents have a very long tail. it takes at least a decade to get something like EDNS or DNSSEC to show up in the field in large numbers, and apparently at least two decades to make it the default. you only get one shot, operationally speaking, at getting folks to deploy any new tcp session option. if at that time you don't also advise them as to how many tcp sessions to permit in parallel, and what to do with udp packets having the same endpoints while a session is open, then you'll have added a new feature (and its associated complexity) without doing anything to actually stop the problem you started with (spoofed-source reflection and/or amplification.) -- Paul Vixie _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop