Configuring DNS Records for a Secure Amarok Linux Home Server

Turning an Amarok Linux machine into a home server is deeply satisfying. You own the data. You control the services. You get to learn exactly how the internet works, layer by layer, with no abstractions hiding the machinery from you. But skipping straight to DNS configuration without first securing the machine underneath it is building on sand. An exposed SSH port, permissive firewall defaults, and DNS records that point to a box anyone can walk into, that combination is a problem waiting to become an incident. This guide works through the full path: locking down SSH, writing sensible firewall rules, configuring A, MX, and TXT records, and then verifying all of it resolves correctly before you call the job done.

Why Amarok Linux Holds up Well as a Home Server Base

Amarok Linux does not fight you. The package manager behaves reliably, the init system is predictable, and the system does not pile on background services you never asked for. That simplicity is genuinely useful for server work, because you end up with a machine whose running processes you actually understand rather than one that is doing things you cannot account for.

Self-hosting on Amarok Linux means running your own mail, file storage, VPN endpoints, personal productivity apps, or anything else you would normally trust to a third party. The upside is full autonomy. The responsibility that comes with it is keeping the machine secure and keeping your DNS configured correctly so that your services are reachable when you need them.

Locking Down SSH Before You Open Anything to the Outside

SSH is almost always the first service that gets exposed when a home server goes public, and it is also the most commonly targeted. Automated bots start probing port 22 within minutes of a machine becoming reachable. The default configuration on most distributions allows password-based logins, which means credential-stuffing attacks can run against your server indefinitely without any friction.

The answer is to generate an SSH key pair on the machine you use to connect, copy the public key to the server with ssh-copy-id, confirm you can log in with the key, and then make the configuration changes below. Do not make these changes until you have confirmed key-based login works, or you risk locking yourself out.

Disabling Root Login and Password Authentication

Open /etc/ssh/sshd_config and set PasswordAuthentication no. This removes password-based logins entirely. Set PermitRootLogin no to prevent anyone from logging in as root over SSH, even with a valid key. After saving the file, restart the daemon with sudo systemctl restart sshd. These two changes handle the bulk of automated attack traffic without any additional tooling.

Changing the SSH port from 22 to something above 1024 is worth doing at this stage. A non-standard port does not provide real security against a targeted attacker, but it cuts down log noise from opportunistic scanners significantly. Update any firewall rules and your SSH client configuration to match the new port before restarting the daemon.

Limiting Which Accounts Can Connect Remotely

The AllowUsers directive in /etc/ssh/sshd_config lets you specify an explicit list of accounts that are permitted to log in over SSH. If only one non-root account ever needs remote access, add a line like AllowUsers yourusername and reload the daemon. Any account not named in that directive gets refused at the SSH layer before authentication is even attempted, which reduces the attack surface without touching individual account settings.

Writing Firewall Rules That Cover What Your Server Actually Runs

A home server benefits from a deny-all inbound policy with explicit allow rules for specific ports. The goal is not to allow traffic from known-good sources only, which is difficult to maintain on a home connection. The goal is to allow traffic only on ports where a real service is listening, and to refuse everything else.

On Amarok Linux with firewall-cmd, you add rules with the --permanent flag to ensure they survive reboots, then apply them immediately with sudo firewall-cmd --reload. A web server needs ports 80 and 443. A mail server needs ports 25, 587, and typically 993. SSH needs whichever port you moved it to. After adding rules, run sudo firewall-cmd --list-all to confirm the active configuration matches your intent. A rule that exists only in memory and not in the permanent set will disappear the next time the firewall service restarts.

Applying server security best practices from NIST reinforces the same principle: only open what is necessary, audit what is open, and repeat that audit on a schedule. The principle of least privilege applies to network access just as it applies to user permissions.

What A, MX, and TXT Records Are Actually Doing

DNS records are how the internet knows where your server lives. Each record type carries a different kind of information, and mixing them up or leaving any of them misconfigured causes failures that can take time to track down.

An A record maps a hostname to an IPv4 address. When someone connects to home.yourdomain.com, their device queries for the A record to find which IP to contact. AAAA records do the same for IPv6. An MX record is specific to email. It tells other mail servers which host accepts incoming mail for your domain. Without a valid MX record, mail sent to your domain will bounce or disappear. A TXT record is a free-form text field used for several things: SPF records that authorize specific servers to send mail for your domain, DKIM public keys used to verify message signatures, DMARC policy declarations, and domain ownership verification tokens required by many services.

The structural rules for all of these record types are defined in DNS record formatting standards, which remains the authoritative reference for how records are encoded, queried, and responded to at the protocol level.

Configuring Your DNS Records in the Right Order

DNS records are managed through your domain registrar or DNS hosting provider, not on the server itself. The server just needs to be listening at the IP address those records point to. Work through the steps below in order, because some records depend on others being in place first.

1. Confirm your public IP address. Home internet connections almost always have a dynamic IP. Arrange a static IP with your ISP if your budget allows, or set up a DDNS service that automatically updates your DNS records when the IP changes. If neither option works, keep a note to update your A record manually whenever the IP changes.
2. Create an A record for your domain and each subdomain. Multiple services can share the same IP. A reverse proxy on the server routes requests to the right service based on the hostname. Common patterns include mail.yourdomain.com, files.yourdomain.com, and vpn.yourdomain.com, each pointing to the same IP.
3. Set a conservative TTL while testing. Time-to-live controls how long resolvers cache your records. Start with 300 seconds during setup so changes propagate in under five minutes. Once your configuration is stable, raise the TTL to 3600 or higher to reduce query overhead.
4. Add your MX record if you are running a mail server. Point the MX record to a hostname, not a bare IP address. Use mail.yourdomain.com with a priority value of 10 as a standard starting point. The hostname in the MX record must have its own A record for mail delivery to work.
5. Create a TXT record for SPF. A minimal SPF record like v=spf1 mx ~all tells receiving servers that hosts listed in your MX record are authorized to send mail for your domain. Without an SPF record, outgoing mail from your server has a much higher chance of being marked as spam or rejected outright.
6. Add DKIM and DMARC TXT records. DKIM requires generating a key pair on your mail server and publishing the public key under a specific subdomain as a TXT record. DMARC adds a policy record that tells receiving servers what to do when SPF or DKIM checks fail. These three records together form the foundation that makes self-hosted email deliverable.

Checking That Your DNS Changes Are Actually Resolving

DNS changes do not take effect immediately. Propagation time depends on the TTL of the records being changed and how aggressively resolvers in the path are caching. After making any change, you need a way to confirm what external resolvers are actually seeing, not just what your local network returns.

Running dig or nslookup from a terminal on the server queries from your network, which might still be serving cached values. A browser-based tool queries from external infrastructure and gives you a clearer view of what the wider internet sees at that moment.

Using a DNS lookup tool from your browser is the right move here. You enter your domain, select the record type you want to inspect, and get back exactly what external resolvers are returning. That makes it useful right at the moment you need it, immediately after making a change and waiting on propagation. Check A, MX, and TXT records separately. A resolving A record does not mean your MX record is correct. A missing or malformed SPF TXT record can quietly break email deliverability for days before you notice the pattern in your bounce logs. Verification is not a one-time step. Make it part of the process every time DNS changes.

A Home Server That Actually Does What You Built It to Do

Getting a hardened Amarok Linux home server running correctly is a methodical process. SSH lockdown removes the easiest attack vector. Tight firewall rules ensure that only traffic you intended to allow can reach your services. DNS records configured in the right order and verified against external resolvers complete the picture, making your machine reachable under the names you chose, with email that delivers reliably.

None of these pieces are optional extras to add when you feel like it. An SSH daemon accepting password logins will be hammered continuously. A firewall with permissive defaults gives attackers a wide surface to probe. DNS records that are correct but unverified will surface misconfiguration at the worst possible time, when you are trying to reach a service and something is quietly broken.

Amarok Linux gives you a clean, stable platform to build on. The tooling is there. Working through these steps in order, and checking your work at each stage, results in a machine that is genuinely yours: secured, configured, and reachable exactly the way you intended.