Dns on blog.iankulin.com

Moving a domain from Wordpress

Mon, 30 Dec 2024 00:00:00 +0000

I love the convenience of a hosted blog on wordpress.com, but one of the justifications for my ‘investment’ in homelab hardware and learning time was that I’d reduce my spend on hosted platforms by self-hosting them. I’ve already quit Evernote and dropped back to the free plan on Dropbox by building systems to replace them for less money and more data sovereignty. And now, the recent Wordpress drama has made me uneasy about Matt having control of domains I’ve got registered with wordpress.

For the moment, I’m leaving content there, but I’d like to keep my options open for the future, so that means moving any domains to an independent registrar, in my case, porkbun.

Wordpress have a good article explaining their part of the process (kudos to them for not trying to make it difficult) but I ran into a bump not mentioned there, so it’s worth writing out the steps for future travelers.

Make sure your email is correct

It probably is fine, but this process is going to rely on you having control of the email address attached to your wordpress account. If you don’t currently receive the emails for renewals etc, then you need to fix that first. Registrars like to be careful that they are not giving away people’s domains to bad actors, so there will be a bit of a “verify you own this email that is the contact for the domain” dance as part of this process.

Be settled

For reasons outside WordPress’s control, you can’t be moving domains around all the time. It needs to have been with the current registrar for 60 days. If not, you’ll just need to wait that out.

Even if that’s not your situation, still keep in mind this transfer will take about a week. There are ways of pointing a domain elsewhere a bit quicker, but actually moving it takes five days or more.

Turn the transfer lock off

Most domain registrars allow you to (probably be default) ’lock’ a domain to prevent changes. To get to this on Wordpress, go into your site, and look in “Upgrades” | “Domains” for “Transfer”. There’s a toggle to turn that off.

This is also where you can request the “Authorization Code”. This is the key that you’ll take over to your new domain registrar. But don’t do that yet - that’s what I did and got this:

Lol. What?! Someone objected by fax to me moving my domain? I feel like the only people who could have done that to this transfer I initiated two seconds ago could be Wordpress.

Turn Private Registration off

To their credit (again) this was explained in another email shortly after:

Ah, so I need to turn ‘private registration’ off. This is the mechanism that hides your personal details as a domain owner from scammers and grifters. Apparently it has to be ‘off’ to transfer the site. This is not a source of stress to me, as soon as the domain is transferred to PorkBun, the apparent owner of the domain when someone does a whois on it, will be “Private By Design LLC”.

Once again, this setting is in the Wordpress site settings under “Domain”.

Get your Authorization Code

Now is the time to hit the button in Wordpress to request the “Authorization Code”. It will be sent to the email attached to the domain. This is the hex string you’ll need to take to your domain registrar to request the transfer.

Start the transfer

I guess every domain registrar will have a slightly different set up. With porkbun, I just went to https://porkbun.com/transfer and entered the domain name and the authorisation code. They did charge me $11 for this, then advised that the transfer would take about five days. Maybe that’s built into the domain transfer system to allow more people to object by fax.

On the porkbun status page for the transfer, I was able to set up an A record to the wordpress IP where by blog still lives, so that the second the transfer went through, it would be set up to direct traffic there with a minimal downtime. I guess in this case that would have no effect since the wordpress name servers would still be in place (see further down), but it’s a good idea since often when you’re moving a domain, the losing registrar would be deleting your name-server entry.

Once the email came through on the sixth day, I checked the domain was still pointing to the blog, and it was all good. But we’re not done yet.

Change the nameservers

Although I’ve now got control of the domain, we’re still using WordPress’s nameservers. That’s not a big deal for me, but I do want to bring them over to porkbun so it’s the same setup as all my other domains. Before I nuke the wordpress nameservers, we need to check what records are in it.

First step is to see who are the nameservers for a domain. We do this with the dig NS <domain-name> command:

In this example the name servers are b.iana-servers.net and a.iana-servers.net In the case of your wordpress blog they are probably ns1.wordpress.com etc.

Once you know the name of the nameservers you can query them with the domain name to see what the records are. The most important will be the A records, but you probably want to go ahead and check the MX (mail) and TXT records as well so you can reproduce them on the new registrar.

This is done with dig @<name-server> <domain-name> <record-type> for example dig @b.iana-servers.net example.com A

In this case there is a single A record pointing the domain to 93.184.215.14 We need to note all of these to reproduce them in the domain settings in your new registrar. Again this is going to be different for each one, but if you’ve ever pointed a domain anywhere, you’ll know how to do it on yours.

Change the nameservers

Now those records are all in, it’s time to change the nameservers. There will be an option somewhere in your domain management tools at the registrar to allow for this. In my case, I’ll be switching to porkbun’s default ones.

Profit

That all was a bit of a dance, but it feels good to be in control of the domain so I can redirect it in the future if needed.

Edit from the future: This (pointing the domain I now controlled at my wordpress.com blog) died after a couple of weeks. I’m not sure if they changed something, but when I went into the wordpress settings to check it was still set up to use an external domain name, it greeted me with an ‘upgrade’ offer to turn that on at an annual cost greater than my old plan. So, I had to hurriedly set up a wordpress instance on a VPS - which turned out to be not much drama and will probably be the subject of a future post.

Solved DNS Issues - Proxmox, LXC, Ubuntu, Tailscale

Fri, 06 Oct 2023 00:00:00 +0000

I’ve picked up an new TP-Link WAP with Omada, so I wanted to spin up an Ubuntu 20.04 LXC to run the controller software in, and ended up spending a couple of hours figuring out why things where not working.

The initial problem was I was having connectivity issues pulling down the updates for all the packages required. I went down a bit of a tangent because I installed an apt cache the other day, so I was looking for problems there. Eventually I narrowed it down to DNS not working and started A/B testing like this:

A more seasoned sysadmin probably would have been looking at the /etc/resolv.conf a bit earlier where the glaring hint was. I’ll get to that in a second, but first a bit about my setup.

I’m running Proxmox 8.0.4 on one of my HP G2 800 Minis (love these little power-frugal gems) and I use Tailscale to tie all my network (my homelab here, and two remote locations) together. The Tailscale version on this node is 1.48.1

You can see in the table above, that a LXC using the Ubuntu 20.04 template had no domain name resolution, but the Debian 12 (and Debian 11 I tried earlier did). The /etc/resolv.conf on the Debian containers looked like this:

nameserver 192.168.100.1

And on the Ubuntu container

# --- BEGIN PVE ---
search tailaf96a.ts.net
nameserver 100.100.100.100
# --- END PVE ---

192.168.100.1 is my local DNS which is provided from the DHCP, but clearly Ubuntu is not using that. The PVE comments tells me it’s Proxmox messing with my container, and that’s the Tailscale DNS server number in there. The container does not have a route to 100.100.100.100 so that DNS is not going to be able to resolved anything.

So, that’s a bit weird, but easily fixed by just editing this back to set the nameserver to 192.160.100.1 right? Well, yes - if you do that, it works, but then as soon as the container is rebooted, the Tailnet DNS gets written back in. Those blocky PVE comments are probably part of the automated system for doing that. So, what’s going on here?

There’s two screens for network configuration when you’re creating an LXC container in the Proxmox GUI.

There’s no option in the GUI to just say “Use the DNS settings provided by the DHCP server”, although we’ll see later, there is a work around for this.

Since I’d been leaving the DNS domain: set to use host settings. You might reasonably wonder what the Proxmox node /etc/resolv.conf looks like:

# resolv.conf(5) file generated by tailscale
# For more info, see https://tailscale.com/s/resolvconf-overwrite
# DO NOT EDIT THIS FILE BY HAND -- CHANGES WILL BE OVERWRITTEN

nameserver 100.100.100.100
search tailaf96a.ts.net local

So actually, although I was thinking there must be some bug with Ubuntu since Debian was working how I expected, it’s the other way around - Ubuntu and Proxmox are working together to do exactly what the settings have told it to - to use the host settings. And actually, the Debian containers are not working correctly (although they were working how I expected). The process of Proxmox making these types of changes is documented in the Admin Guide. I’d actually never seen that guide till today (although there is a large “Documentation” button in the top right of the web GUI), but it looks pretty great so I’ll be revisiting it.

Solution 1

The first solution is just to specify the DNS address in the GUI - then our container works exactly as the PVE developers intended. A slight downside is that if I change the network configuration in future and update the DNS address in the DHCP server (which is the logical way to do that) then it won’t update for this container and domain name resolution will stop working for it.

If I do that, the /etc/resolv.conf looks like this:

# --- BEGIN PVE ---
search tailaf96a.ts.net
nameserver 192.168.100.1
# --- END PVE ---

And it all works fine.

Solution 2

This post on the Proxmox Forums lead me to a second solution. It’s possible to stop Proxmox from adding the host by adding a little signal file with

touch /etc/.pve-ignore.resolv.conf

When Proxmox sees that. it won’t mess with the /etc/resolv.conf file, so if that’s been edited to:

nameserver 192.168.100.1

It will be left alone, and things will work fine. This is not quite what I’d like - I’d really prefer it picks everything up from DHCP, but I don’t know enough about how that works in Linux to fix it, yet.

Local host names with Pi-hole

Mon, 13 Feb 2023 00:00:00 +0000

I run an instance of Pi-hole as a network-wide advert and surveillance blocker. It also has a setting to block individual domain which I use to force myself to really consider if 30 minutes of Reddit is a good idea when I should probably just be going to bed.

As I’ve increased the number of real and virtual devices on my network, it’s getting to be a pain remembering all of their IP addresses. So I’d like to have DNS entries for them, for example I’d much rather:

ssh ian@vm100-dockhost

than

ssh ian@192.168.100.29

Luckily, since Pi-hole works by being a DNS server (who drops requests for domains it doesn’t like) it has the capability of handling these local names.

How to set up

Down the left side of the Pi-hole interface, there’s a link for Local DNS | DNS Records. Click on that for this screen, then input the name you’d like to use and the IP address it should go to. I use the device host names so there’s less confusion, but there’s no rule for this - you can use whatever you like.