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

Phillip Hallam-Baker phill at hallambaker.com
Mon Mar 6 16:47:41 UTC 2017

On Mon, Mar 6, 2017 at 11:01 AM, Thomas Steen Rasmussen <thomas at gibfest.dk>

> On 03/06/2017 04:31 PM, Phillip Hallam-Baker wrote:
> On Mon, Mar 6, 2017 at 9:13 AM, Thomas Steen Rasmussen <thomas at gibfest.dk>
> wrote:
>> Hello,
>> If providers running large resolvers today are unwilling to use the extra
>> resources that dns-over-tls will require then maybe they should stop
>> running large resolvers.
> ​Or maybe:
> ​Just a suggestion you know..​
>> This is no different from the people who used to complain loudly that
>> HTTPS will never work large scale.
> ​Actually no it is not. I never argued that HTTPS would not scale. I did
> point out that certain aspects of PKIX would not scale, CRLs for example.
> But nobody I know of ever argued TLS does not scale.
> Maybe you personally didn't, but the biggest concern about https has
> always been the performance hit, right up until maybe 5 years ago. This is
> the whole reason sites like https://istlsfastyet.com/ existed. And as it
> turns out it was not an issue at all by the time we got around actually
> implementing it wide scale.

​The performance hit is not a scaling issue. ​It was always a performance
issue and we knew back in 1993 when the first Web security protocols were
developed that it would be solved by 2000 or so.

> Our hardware evolves faster than our workload. See also NSEC5 - it was
> considered downright impossible to to "live" signing/proof of non-existance
> to prevent zone walking, but lo and behold, what do you think we will all
> be doing in a few years?

​NSEC5 uses a set of cryptographic primitives that ​are entirely novel in
IETF work and use them in a completely original way. Regardless, the scheme
is only practical today because of the expiry of various patent claims on
the use of elliptic curves.

> DNS-over-TLS will not happen widescale from one day to the next. You will
> have plenty of time to adapt your setup to the new worloads.

No ​DNS over TLS won't happen at all.​

​I can't buy a TCP load balancer that works at the same speed as a UDP
balancer without spending vastly more money because the UDP balancer is
stateless and the TCP is not.

HTTP load balancing is possible because each host has a separate IP and
that is what makes load balancing stateless.​

You can't use the same capability for DNS resolution because it is the DNS
resolution layer that enables it.

> Of course it will, we might have to throw some more hardware at it though,
>> but more likely said hardware will have been naturally replaced with newer
>> hardware before we reach high adoption of dns-over-tls. Adoption will not
>> happen overnight.
> ​No, it is not just a question of different hardware. It is a completely
> different model because a DNS over UDP resolver is entirely stateless and a
> DNS over TCP resolver is not.​
> Just because it has been stateless historically does not mean it has to be
> stateless for all eternity. Stuff changes, deal with it.

​Just because some group of individuals decide to write a spec that doesn't
meet blocking deployment requirements does not mean people have to
implement. Deal with it.​

> ​The group was told repeatedly that this was a show stopper and they
> ignored us. And now their work is being ignored. DPRIV was not a waste of
> time, it was much worse than that.​
> Well that tends to happen when you yell your point at people. I am tempted
> to ignore you myself, so there's that. :)

​​Complaining about the way a point is raised is a classic form of agenda
denial. There was no way in which that point could have been raised that
would have produced a different outcome. The group wanted something that
got to RFC as fast as possible and they did not want to listen to any
deployment issues from anyone.

Now you might think that given that I work for a company that has one of
the public resolvers you would like to see change and you are the person
asking me for the favor, that maybe you might want to take your own advice.

​Like Tweetler, you are very good at seeing how other people are being
nasty and mean to you but utterly incapable of seeing what you are doing to
them. Being gaslighted by Paul does not ma​ke me at all inclined to accept
his position.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170306/5b00a5a8/attachment.html>

More information about the dns-operations mailing list