Category: Tech/Geek

First let me acknowledge that there are many ways to accomplish this. An easy solution for me would have been to simply use dyndns.com, no-ip.com, or one of the other commercial DDNS services supported by my router. For various reasons, I decided not to use one of those. Actually I did use duckdns.org for a while, but there were occasional issues that I got tired of dealing with.

I’m currently using Porkbun for DNS. They’re cheap, reliable, and have a decent user interface. They, like many other DNS services, also provide an API to make changes programmatically, without needing to log into their web site and make manual changes.

In my case, I have a shell script that runs as a cron job every 5 minutes. It checks my router for the WAN address and compares it to the last recorded address. If the two are not the same, it emails me and runs a Python script to update DNS.

I realize that some of this is pretty specific to my setup. Still, it might be a useful starting point. I found the Python script to update Porkbun DNS on their web site. The command to check the WAN IP address at the router may work for yours, or you may need to take a different approach.

#!/bin/bash

# Read the old IP address from a file.  The EOL will go into a variable we don't use.  This is necessary.
read OldIP b < /home/dale/myipaddress.txt
# Get our curent IP address from the router.
OUTFILE=~/myipstatus.txt
MyIP=`ssh -o StrictHostKeyChecking=no [username]@[router.ip] "ifconfig eth0 \
| grep inet | sed -e 's/.*addr:\([^ ]*\) .*/\1/'"`

while [[ $MyIP == "" ||  $MyIP == "192.168."*  ]] ; do
 sleep 10
 MyIP=`ssh -o StrictHostKeyChecking=no [username]@[router.ip] "ifconfig eth0 \
 | grep inet | sed -e 's/.*addr:\([^ ]*\) .*/\1/'"`
done

if [  "$OldIP" != "$MyIP" ] ; then
  echo "`date`" > $OUTFILE
  echo "Found new IP $MyIP, which is different from our previous $OldIP!" >> $OUTFILE
  echo "Updating Porkbun DNS entries..." >> $OUTFILE
  python3 ~/porkbun/porkbun-ddns.py ~/porkbun/config.json <mydomain.com> <hostname> >> $OUTFILE
  mail -s "IP address change detected" <myemail@domain.com>  < $OUTFILE
  echo $MyIP > ~/myipaddress.txt
else
 echo -n "." >> $OUTFILE
fi

In practice, this can result in a 5-10 minute lag between the time your IP address changes and the time your DNS is updated. If your ISP changes your IP address frequently, it may be too long. In my case, our ISP only changes our IP on rare occasions — typically less than once a year.

Again, there are other approaches, but most will not update DNS entries in your own domain. You can get around this to a certain extent by using CNAME entries, but this was the best way that I found to update my own domain’s DNS.

Once upon a time, residential home Internet connections — cable modem and DSL being the choices at the time — were unfiltered and un-firewalled. This had good and bad aspects to it. You may or may not have been firewalled off from your neighbors. I remember a guy who worked for me demonstrating on the TV news one night how he could see every Windows PC in his neighborhood, and send print jobs to random peoples’ printers if he wanted to. Even after they wised up to that little bit of “openness”, it was still possible to run your own services — mail, web, and so on.

Since then ISPs have come a long way. Residential cable, DSL, and fiber connections, often topping out at 1 GB or even higher, are tightly restricted. Your ISP really wants to support only web prosing and gaming, and most certainly do not want any services running on their network. No web servers, no email (in or outbound). Anything inbound on ports 80, 25, and often 443 are blocked, as is outbound port 25.

So, you’ve got your own little web server you run for your own blog (like this one)… or one you run for a nonprofit, club, whatever. You’ve got your own domain and want to run your own email. The solution is usually some combination of a hosted VM, Google, what have you. But it can get a little expensive, and of course you’re dependent on others for critical bits and pieces of your infrastructure. I can’t take all of that pain away, but I can maybe help to reduce it somewhat.

So let’s look at the issues you may face, and how to solve them. I’ll detail each solution in subsequent blog posts, with solutions that may work for you as they have for me.

• Your IP address is dynamic, and you need reliable DNS. This can be fixed using a script to detect when your IP address changes, and update your DNS accordingly. It’s not perfect in that there will be a delay before the IP address change is detected and updated, but if your IP only changes occasionally it’s “good enough”. Of course there are dynamic DNS (DDNS) solutions that will do this as well, if you don’t mind paying for them. I’m a cheap bastard and I like a challenge, so I rolled my own.
• Your ISP blocks connections on port 25 (SMTP). This is pretty much going to require an external mail relay. I have yet to find a way to get the rest of the world to use any port other than 25 for SMTP connections… it really is too bad there’s not a DNS based way around this, like a SRV record (see RFC 6186). Until that happens, I use a small external hosted VM relaying mail on a different port. It could actually be a lot simpler, but I prefer to keep our actual email on a server here, at my house.
• Your ISP blocks incoming traffic on web ports 80 and 443. Easy. Nginx is your answer, what was the question?

The fun part is sizing this stuff. If you’re used to working in a corporate environment like I have been for the past (mumble) years, you’re thinking, “OK, a 4 CPU 16 GB machine for a mail server, than another one for the proxy… that might be OK… ” Nah. You might be shocked at just how little power it takes to do this stuff. After all, we’re just passing packets around. The TLS encryption is the most heavyweight thing being done, I think. If I had a solid place to hang a Raspberry Pi where it would have a static IP and no filtering of privileged ports, it wouldn’t break a sweat — though I’ve had too many of them just stop working to trust them for this kind of stuff, really.

Like some other ISPs, Cox blocks all incoming access to port 80 on residential connections. They also use DHCP to assign dynamic IP addresses, which can can and do change occasionally — especially when you reboot your router. That’s fine in most cases, but can be a real pain in the ass if you run any local services that you need to access from outside the home. For example, if you run your own email and want to use IMAP, you’re likely going to need an SSL certificate. You need a way to have your DNS update to point to your new IP when it changes.

One way to do all of this without paying subscription fees is with Duckdns and Letsencrypt. Duckdns is a free DNS service with an easy to use API that can be updated by a script when your IP address changes. Letsencrypt is a free SSL certificate CA; I can’t say enough good things about Letsencrypt and encourage you to support them with a donation as I have.

So. First we can use cron to run a command that updates our duckdns IP address every ten minutes or so.

echo url="https://www.duckdns.org/update?domains={my_domain}&token={my_token}&ip=" | curl -k -o ~/duck.log -K -

Simple, right? Now we have a hostname that always points to our own home IP address – or at least always does within ten minutes of an IP address change, which is probably good enough for most purposes.

Now for the SSL certificate. Letsencrypt will happily issue free a 90 day SSL cert for your domain. Normally, one runs a script from cron that renews the certificate if the cert is expiring in less than 30 days. IF you can expose port 80 to the web, even temporarily, then life is good — just run ‘certbot renew‘ once a day, or even once a week, and everything happens for you in the background. If, however, your ISP filters port 80… well, there’s the pain-in-the-ass part. The certbot script renew script will only work if you have port 80 open to the web. I haven’t found a way to get Letsencrypt’s server to use any other port to reach your web server, so forwarding a non-blocked port (8880, for example) to your local server’s port 80 does you no good.

All is not lost; it just means a bit more work. Letsencrypt will also issue certificates using DNS challenges for authentication, placing specific TXT records to prove that you have control of the domain or subdomain in question. The process looks like this:

certbot certonly --manual --preferred-challenges dns -d example.com-d -d example-com.duckdns.org

The certbot script will tell you to create TXT records in DNS for your domain, and will wait for you to do so before proceeding. You can use your DNS provider’s web or API interface to add or change the TXT record accordingly. Duckdns now supports TXT records in addition to A records, and updating yours is simple:

curl 'https://www.duckdns.org/update?domains={my_domain}&token={my_token}&txt={my_txt}&verbose=true'

Once you’ve verified that the TXT records are there using, say, ‘dig _acme_challenge.{my_domain}.duckdns.org TXT‘ — simply hit ENTER to let the script finish. You should end up with a renewed SSL cert.

My previous ISP didn’t block port 80, so I never had to do any work at all for this. I ran the ‘certbot renew’ command from cron once a day, and it automatically updated the certs for me. Now that port 80 is no longer an option, I will need to manually renew the certificate every 90 days. I’ll actually do it at around 75 days, because Letsencrypt helpfully sends out emails to let you know when your certificate is within 15 days of its expiration.

I’ve moved the blog to a new web service… one of the AWS virtual server offerings. So far, so good… and dirt cheap.