Tag Archives: dns

000CPL, 04 - SSL & DNS

Ssl Dns

Welcome to the NZRT Wiki Podcast. Today we’re looking at SSL & DNS.

Let’s start with certificate coverage. NZRT runs four subdomains, and each one has its own SSL certificate managed through cPanel’s AutoSSL system using Let’s Encrypt. Those four subdomains are the main site at nzrtnetwork.com, the ERP system at erp.nzrtnetwork.com, the cloud storage instance at cloud.nzrtnetwork.com, and the mail server at mail.nzrtnetwork.com. All four certificates are stored in the same location — a folder called ssl inside the DavWWWRoot directory, accessed over a secure WebDAV connection. And here’s the good news: renewal is fully automatic. Let’s Encrypt certificates last ninety days, and cPanel handles the renewal cycle for you without any manual intervention needed on your end.

Now let’s talk about DNS records, because this is where things get a little more detailed. There are two groups of records you need to know about: core records and mail records.

Starting with the core records. You have a set of A records, which map your domain names to the actual server IP address. The root domain itself points to the server, and so does the www version of the domain. From there, you have three more A records for the subdomains: erp points to the server for Dolibarr, cloud points to it for Nextcloud, and mail points to it for the mail system. There is also the option of setting up a CNAME record for www that points back to nzrtnetwork.com — that is an alternative to using the A record for www, so you would choose one approach or the other.

Next are the mail records, and these are really important for making sure your outgoing email is trusted and does not end up in spam folders. First, you have an MX record on the root domain that routes all incoming mail to your mail server. Then there are three TXT records you need. The first is an SPF record, which tells the world that your mail server is authorised to send email on behalf of your domain. The second is a DMARC record, set on the underscore-dmarc subdomain, which defines a quarantine policy for emails that fail authentication checks and sends aggregate reports to the admin email address. The third TXT record lives on a subdomain called mail dot domainkey, and it holds your DKIM public key. DKIM adds a cryptographic signature to your outgoing emails so receiving servers can verify they genuinely came from you and have not been tampered with in transit.

Now let’s walk through the renewal checklist. There are four things you want to make sure are in place. First, confirm that AutoSSL is enabled in cPanel for all your subdomains — this is what drives the automatic renewal process. Second, make sure expiry alerts are configured in cPanel under the SSL/TLS Status section, so you get notified if a certificate is approaching its expiry date and renewal has not kicked in as expected. Third, after each renewal cycle completes, go and check the renewal logs — you will find them in the logs folder inside DavWWWRoot — just to confirm everything completed cleanly. And fourth, you should manually verify the certificate chain after renewal. There is a command you can run in your terminal that opens a connection to your domain on the standard HTTPS port and outputs the full certificate details, letting you confirm the certificate is valid, trusted, and presenting correctly to the outside world.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

000K8S, 04 - Networking

Services Dns

Welcome to the NZRT Wiki Podcast. Today we’re looking at Services & DNS.

Let’s start with the basics. Inside a Kubernetes cluster, CoreDNS is the engine that handles automatic DNS resolution. That means when a service or a pod needs to find another service or pod by name, CoreDNS is the one doing the lookup behind the scenes.

Now, DNS names in the cluster follow a predictable pattern depending on what you’re trying to reach and where you’re reaching from. There are four main formats to know. First, if you’re looking up a service from within the same namespace, you can just use the service name on its own — short and simple. Second, if you’re crossing into a different namespace, you add the namespace after the service name, separated by a dot. Third, if you want the full, unambiguous address — what’s called a Fully Qualified Domain Name — you build it out as the service name, then the namespace, then the suffix “svc.cluster.local”. And fourth, pods themselves get a DNS name too, built from the pod’s IP address with dashes instead of dots, followed by the namespace and then “pod.cluster.local”. A real example of a fully qualified service name would look like: wordpress-service dot nzrt-prod dot svc dot cluster dot local.

Next up, testing DNS resolution. The wiki shows two ways to do this. The first approach launches a temporary debug pod using a minimal image called busybox, runs an nslookup command against the wordpress-service inside the nzrt-prod namespace, and then automatically removes itself when done. The second approach skips creating a new pod altogether — instead, you jump directly into a pod that’s already running and fire the nslookup from inside it, this time using the cross-namespace format with the namespace included in the name.

Now let’s talk about headless services, because these work a little differently. A normal service gives you a single stable IP address that load-balances traffic across your pods. A headless service, by contrast, has no cluster IP at all — and that’s intentional. When you query a headless service, you get back the actual IP addresses of the individual pods behind it. This is particularly useful for StatefulSets, where each pod needs its own stable, predictable DNS name.

In the Nextcloud example from the wiki, you’d have two pods addressable individually. The first would be nextcloud-0 dot nextcloud dot nzrt-prod dot svc dot cluster dot local, and the second would be nextcloud-1 with the same suffix. Each pod is reachable directly by name, which matters a lot for stateful applications where pod identity is important.

The configuration for a headless service is straightforward. You define it as a standard Kubernetes service, give it the name “nextcloud” in the nzrt-prod namespace, set the cluster IP field explicitly to the word “None” — that’s what makes it headless — point the selector at pods with the app label of nextcloud, and expose port 80.

Finally, if you ever need to inspect or troubleshoot the CoreDNS configuration itself, the wiki shows a command that retrieves the CoreDNS config map from the kube-system namespace and prints it out in full. This is handy if you’re chasing a DNS issue at the cluster level and need to see exactly how CoreDNS is configured.

For more context, the related topics in the wiki are Networking Overview, Services, and StatefulSets — worth reading alongside this one if you want the full picture.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.