DDNS

Tags: tech homelab

With any homelab setup, you would ideally want to expose some of your services to the public. There are many usecases, and subsequently there are many ways you can implement those usecases. For instance, you might want to access your Plex library over the internet using a personal domain. Others might choose to restrict the access and availability by setting up a VPN tunnel, which gives only authorised clients the ability to connect back to the service running on the homelab.

I have mixed requirements. For example, I self-host my own web server on which I deploy this website, and I also self-host a Wordpress implementation, which I use as a collaborative blog space. These services should be made widely available to the public in an easy, shareable way, so they need to have their own dedicated human-readable domain names. For other usecases like accessing my media, music or audiobook library, only me or my family needs to access them from authorised client devices.

For the website, I purchased a domain from Cloudfare and used their DNS service to configure the name resolution to my router’s public facing IP address. But wait, anybody who knows my website address will be able to determine my home router’s IP address. This will open up my network for unwanted attacks and vulnerabilities. We can prevent this by using Cloudfare’s proxying service. This abstracts the actual IP address of the router, and only Cloudfare knows the real IP and it takes care of the routing.

The other problem with this approach that home router IP addresses change frequently and periodically. They are assigned by the internet service provider and the router configuration is largely controlled by them. Anytime the router restarts or resets and tries to make a fresh new connection with the service provider, it gets assigned with a new IP address. This is now problematic because Cloudfare name resolution will fail. I needed a way to get around this manual reconfiguration each time the IP address change.

This is where a simple utility called cloudfare-ddns comes in handy. This utility runs as a docker container in my homelab and runs every morning at 5 am and checks my current public IP address. It then checks to see in my Cloudfare configuration if the latest IP address is the same as the one currently configured. If not, it automatically updates it, without any manual intervention at all. Since each subdomain has its own A record in Cloudfare, we need separate containers of the cloudfare-ddns running to check and update the IP address of the corresponding A record.

A sample docker-compose for cloudfare-ddns:

  ddns-blog:
    image: oznu/cloudflare-ddns
    container_name: ddns-blog
    environment:
      - API_KEY=<YOUR_CLOUDFARE_API_KEY>
      - ZONE=your-domain.com
      - SUBDOMAIN=blog
      - PROXIED=false
      - PUID=1000
      - PGID=1000
      - TZ=Europe/London
      - CRON=0 6 * * *  # At 06:00 AM every day
    restart: unless-stopped

The above will run a check every morning at 6 and update the IP address configuration in Cloudfare for blog.your-domain.com.

This has made my life that much easier and taken the hassle out of maintaining the blog and the website. I no longer need to worry about constantly checking to see if my IP address has changed and if yes, login manually to Cloudfare and change each A record by hand (I have about 10 of them).

Image

Webmentions

Loading mentions...