[dns-operations] DNS-over-TLS in public resolvers

[Phillip Hallam-Baker]

On Mon, Mar 6, 2017 at 10:16 AM, Paul Hoffman <phoffman at proper.com> wrote:

> On 5 Mar 2017, at 23:28, Ralf Weber wrote:
>
> Moin!
>>
>> On 5 Mar 2017, at 17:01, Phillip Hallam-Baker wrote:
>>
>>> There are two issues, both of which I brought up at the start of DPRIV:
>>>
>>> 1) Must be supported by browsers.
>>> 2) Protocol MUST be entirely state free
>>>
>>> If you want a protocol to be deployed, you need to solicit input from the
>>> people who you need for deployment and take notice of it. DNS over
>>> anything
>>> TCP is not going to measure up.
>>>
>> +1. I brought up similar concerns in dprive, but the counter argument was
>> always that people run web services with it so TCP does scale. The problem
>> with that argument is that people don't want to invest the same money in
>> DNS
>> services that they are investing in HTTP services.
>>
>> Running a DNS over TLS for a couple of users is easy, but running it for
>> millions of users is not easy. As these scaling issues were brushed aside
>> in the working group we now have to face them at deployment stage or maybe
>> we won't see widespread deployment.
>>
>
> They were not "brushed aside": there was a second document that used DTLS
> that is now RFC 8094. If you feel that it is superior for large-scale use,
> it would be valuable to show evidence of that so that implementors will
> know about it.


​Well if you had actually listened to the issues raised, you would know why
DTLS is not a solution either.​

You are trying to gaslight me here. Stop it.

​The large public resolvers all use anycast for performance. They also use
stateless load balancing inside their infrastructure.​ I know what DTLS
would do for our system and the issues at Google etc. must be orders of
magnitude worse.

Yet again a DNS area group proposing a security feature ignored the
deployment issues raised by the deployment stakeholders. Then when their
proposal is ignored they complain about the stakeholders not taking the
security problem seriously rather than their refusal to meet their needs.

DNSSEC was all ready to roll out in .com back in 2001 with the ATLAS
upgrade. The only reason it did not deploy was intransigence from the DNS
area.

DANE could have been a valuable contribution had the architecture separated
the certificate publication and security policy enforcement functions. You
refused and the proposal is worse than dead.

DPRIVE follows in a long list of failed projects.


At some time Paul, you might just realize that the ability to ram a
specification through IETF at the fastest possible speed is not the best
way to achieve deployment in the real world.

Getting fast IETF process has never been my primary objective. In fact I
have deliberately slowed some proposals because I needed to get some
stakeholder on board.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170306/6aa1860a/attachment.html>