Powering a Dynamic DNS Service with Fission.io

Like many users with some kind of home lab, but not a commercial/business class account with their ISP, I rely on dynamic DNS providers to give me a consistent pointer to my lab’s ingress points. I decided, after completing something like my 5 millionth “domain verification” form, this was a good problem for Fission.io to solve.

I could have a node in my home lab make a POST request with a new address (we’ll cover the client side in a moment) to Fission, which would then contact my DNS provider (in this case DigitalOcean) with the record update.

How do I do this?

The beauty here is that I do not need to persist this service; it only runs (i.e. consumes resources on my Kubernetes clusters) when an update is required.

The task would look something like this:

So, you have a pretty straightforward process here:

  1. Your computer makes a POST request with your current IP address (we’ll cover this in a second) to Fission
  2. If the record already exists, it will simply update; if it does not, it will be created.

You can, then, create the task:

fission function create --name ddns --env python --url /ddns --code ddns.py --method POST

Since this task updates data that you will be accessing (especially if your Kubernetes cluster does not run on-premise), you can also implement something like a key check, or rework the script to require that you provide a valid domain or record, etc. (or use Flask authentication, for example) to prevent unauthorized changes.

Updating Your Address

So, with the task created, there are a few ways of triggering this task, but I’ll focus on two:

You can take a cron-based approach, and run a job like:

* * * */1 * IP_ADDR=$(curl -s http://ipv4.icanhazip.com); curl -X POST -H 'Content-Type:application/json' -d "{'ip':$IP_ADDR}" $FISSION_ROUTER/ddns

or, you can run a script on a local node to detect IP changes, something like:

which will only make a call to Fission if the IP address changes between when the script is run.

Conclusions

I want to call out the use of FaaS here, vs. a persistent service:

In this case: do you need resources reserved 24/7 for an operation that will take less than a second (and, in this case, is fairly low priority), if it gets run on a given day at all? Probably not, but the inverse is true as well.

Does this approach scale?

Suppose your ISP (for some reason) changes your IP address multiple times every hour; at scale, that’s a pain to run as a persistent service, and implementing a FaaS solution makes every second count. You’ve only used what you needed, and those shaved increments will pile up.

My point is mostly that you can iterate over your solution, and find better, more efficient ways to run certain types of workloads, for different use cases, at different priority levels, using the same tooling (in this case, Kubernetes) as you might’ve been already.