Re: [dns-privacy] Multiple DNS requests per packet, multiple packet responses

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Mar 21, 2014 at 12:33 AM, Tim Wicinski <[e-mail]> wrote:
>
> On 3/20/14, 8:54 AM, Phillip Hallam-Baker wrote:

>> What I am saying here is that we have an opportunity to say that we
>> leave certain parts of the legacy behind without additional cost.
>>
>>
>> Or we could start the work by declaring that the DNS protocols were
>> handed down in a state of grace and that they represent the most
>> shining example of perfection we can hope to achieve and that anyone
>> who suggests the mere possibility of alternative approaches must be
>> cast out as a heretic.
>
>
> Or we can do something like HTTP/2 is doing and approaching it as a new
> mechanism and allow methods for choosing, but having a fall back strategy.

That is what I was proposing.

Every time we try to use the DNS for a particular project we end up
hitting our heads against a slew of deployment restrictions that make
it unusable or limit the value.

Encrypting the traffic is inevitably a significant discontinuity.

>
>>
>> DNSSEC has always had to dance round the problem that DNS responses
>> have to fit in one packet. And that pushes a huge number of
>> contortions onto designs. I think it is more than reasonable to
>> require that if people are going to start encrypting packets that they
>> be required to have a strategy that can transport DNSSEC packets for
>> almost all real world protocols without having to switch from UDP to
>> TCP. That could mean staying in UDP all along or starting in TCP from
>> the start. But switching horses in midstream from UDP to TCP hits all
>> sorts of ugly real world deployment issues.
>
>
> I would agree it should either all work in UDP or start in TCP.
>
> And Pauls' drafts are very relevant to this conversation.

Or possibly more practical would be to have a strategy where UDP is
the default but there is a fallback over HTTP.

-- 
Website: http://hallambaker.com/