TLS & *

Presto takes security very seriously. That is why nearly every Presto network connection uses TLS 1.2. TLS 1.2 encrypts all communication and can also validate that clients are actually talking to who they think they are talking to. The validation check is a somewhat complicated protocol, beyond the scope of this article, but it’s important to note that all Presto 2.5 components perform this check. Most services like Presto use self signed certificates and disable the validation checks, because they will fail. Earlier versions of Presto actually did that too! However we wanted to do better and use all of TLS to make our system as secure as possible. To make this work in every environment, it became necessary to move away from self signed TLS certificates and towards TLS certificates that are signed by recognized certificate authorities. This posed some interesting engineering challenges.

Every Presto server component is secured using a wildcard certificate for * Collobos administers the name servers for the domain. When a Presto client connects to a Presto server, it will ultimately use some form of a * domain name to connect to. Here is where things get a bit tricky.

After a Presto client discovers a Presto server component that it wishes to connect to, the client will send the server a message asking for a secure name to use to connect to. The server component will respond with it’s IP address encoded with a suffix. For example, if the server component is running on, it will respond with a DNS name that is So in other words, it replaces the dots (“.”) in with dashes (“-“) and appends to it.

Collobos DNS is programmed to return an IPv4 address of the form a.b.c.d. when asked to resolve a name of the form For example, if asked to resolve, it will return That is how Presto clients can make secure TLS connection to Presto server components, on whatever network they happen to be running on.

One thing to note in this is the following. Some network routers have something called DNS rebinding attack protection. Part of that protection prevents a public DNS server (like Collobos DNS) from returning non-routable IP addresses.
It is very straightforward to check whether DNS rebinding attack protection is affecting Collobos DNS. To check, open up a command prompt window and type in the following:

C:\> nslookup

If everything is working as it should, you should see output that looks something like this:


If there is no address listed, it’s quite possible that DNS rebinding attack protection has stripped the address from the answers supplied by Collobos name servers.

It is important to ensure that the domain is whitelisted in any DNS rebinding attack protection, otherwise Presto client components will be unable to successfully connect to Presto server components.

Feedback and Knowledge Base