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

[Tim Wicinski <[e-mail]>]

On 3/20/14, 8:54 AM, Phillip Hallam-Baker wrote:
> Really?
>
> When DNSSEC was first proposed in 1995 or thereabouts it wasn't
> deployable because most of the DNS infrastructure could not support
> new RR types, there was a 500 byte limit on messages in many cases and
> several other issues.
>
> It took another five years to fix those issues in the infrastructure
> before deployment became practical.
>
> 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.

>
> 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.

tim