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

Reply via email to