Week 15, 2018 - Cloudflare DNS Resolver; AWS Secrets Manager

By (3 minutes read)

Cloudflare’s releases their DNS resolver 1.1.1.1 while AWS gives us a new Secrets Manager.

Cloudflare DNS Resolver

On the first of April1, Cloudflare announced their new DNS resolver. This DNS resolver is meant to replace the DNS resolver provided by your internet service provider2. To simplify, a DNS resolver translates a URL into an IP address. When you request something from a domain, say https://ig.nore.me, this gets turned into an IP address that your browser can then connect to.

As such, it is an essential part of your internet experience, and speed matters a lot. While your machine will do some local caching, to prevent it from requiring to call the same domain all the time, this cache is usually set to expire on a regular basis. This is especially the case in cloud environments, where your load balancer might randomly switch to a different IP address.

If you’re familiar with Cloudflare, it won’t come as a surprise that the main advantage here is speed. Because of their many endpoints, Cloudflare has a local presence in many locations and can, therefore, return results faster than most other resolvers. The best-known alternative is probably Google’s 8.8.8.8, which for me resolves in 8ms while Cloudflare takes less than 4ms.

There is also a privacy benefit to using this DNS resolver. DNS resolvers can track your every request, and especially in the case of public wifi that is unlikely something you want. 1.1.1.1, however, doesn’t write the requests to disk and is committed to wiping all logs within 24 hours.

AWS Secrets Manager

At the San Fransisco Summit, AWS announced several new things. Several of these are interesting, but I’ll focus on the new Secrets Manager. The Secrets Manager is a new service that allows you to store secrets3.

This is not the first service that AWS has offered to deal with the issue of storing secrets. I’ve mentioned the Parameter Store before, so it’s a good idea to have a look at the differences here. First, the Parameter Store is intended as a place to store not only secrets but other parameters as well. It is also complete managed by you. When storing a secret, you tell it which KMS key to use, and if you wish to update the values you have to write it into the Parameter Store and ensure any services are updated for it.

The idea behind the Secrets Manager is to automate this. You define a key once, and then you can enable automatic rotation. In addition, you can connect it to your RDS instances so that it will update those with the new credentials. This allows you to for example update your database password on an hourly basis and works by way of a Lambda function that Secrets Manager creates for you.

Naturally, this means you have to update your application to handle this rotation as well. Where with the Parameter Store it was possible to pull the secrets in when your instance is started, you now should call the Secrets Manager API as part of your call, or at the very least frequently refresh your credentials locally.

In addition to regular passwords, another powerful feature is the ability to store OAuth credentials. Or rather, instead of merely storing it, you can hook it up to a Lambda function that allows you to refresh the credentials automatically.


  1. In the first useful announcement on that day since GMail. ↩︎

  2. Or your corporate network, or the public wifi, etc. ↩︎

  3. Shocker, I know. ↩︎

comments powered by Disqus