In that case, since your ISP probably allows access to TCP ports you open, if you get a static IP in the first place, all you need to do is
DNS:
- Point your AAAA and A records of your heimdi.at domain to your static IPv6 and IPv4 address, respectively. Your ISP probably doesn't only give you one IPv6 address, but a whole subnet (mine gives me a /56 subnet, so that 4.7·10²¹ addresses to choose from!), so pick exactly one of these, and see step 7.
- (optionally) configure *.heimdi.at (if you want wildcard subdomains!) or specific subdomains (like www.) to CNAME to your heimdi.at domain or directly AAAA/A to your static IP address
- configure your homeserver's HTTP daemon¹ to react to requests for heimdi.at and, if applicable, to subdomains accordingly, on both the port 80 for HTTP and on port 443 for HTTPS.
- You mention an MX record: that probably points to some domain name, under whose address an SMTP/submission server is handling mail.
While technically theoretically possible to run the mail server at home, it will usually practically fail: end-consumer ISP networks typically are blacklisted by major email providers for spam reasons.
This means your MX record should continue to point at your own or an email provider's mail server.
- TXT records serve very different purposes, but the most common ones have to do with email handling, as well, so probably should continue to be what they are?
Now, and since you're not planning to run an email server on it, this is very optional,
- you can ask your ISP whether it is possible to add a reverse DNS (PTR) entry for your IPv6 and IPv4 addresses pointing to heimdi.at. It's not usual for ISPs to do that, so if they do, mention it's cool.
Networking setup:
- (unless your home server is also your router) Make sure your home router / modem / fiber adapter / whatsitcalled is configured to forward TCP/IPv4 port 80 and 443 to your home server's IPv4 address, and that it doesn't block TCP/IPv6 port 80 and 443 going to your servers IPv6 address. (Reason: usually, you have NAT for your internal IPv4 network, because your router only gets one public IPv4 address. That problem does not exist with IPv6, so every device on your internal network can have its own public network address. Much much easier to configure than IPv4.)
- Configure your home server to the public IPv6 address you chose for it, and to the private IPv4 address your router forwards 80/443 TCP/IPv4 to.
- Make sure ICMP and ICMPv6 work from external addresses: make sure you can
ping your homeserver from the internet.
- Make sure your homeserver has a firewall that blocks all ports you don't want to be accessible from the internet. (in other words, lock down, and open ports 80 and 443.)
Certificates:
- Well, it's your domain, and you probably don't have to prove your actually the homebanking website you claim to be! So, basically, a letsencrypt certificate is as good as any. With
certbot run --nginx -d heimdi.at on your home server, you'll apply for a certificate, and directly install it for your your website. If this is a modern Linux, there's a systemd timer unit that often gets installed alongside with certbot from the package repos, which allows you to enable auto-renewal of the certificates. Do that.
Maintainability / security:
- Set up your homeserver's OS to automatically install pressing security updates (and only these). You don't want to get caught in the middle of the next heartbleed.
- Consider whether and how you want to be able to remotely administrate your server. That might be as simple as installing and enabling an SSH server (typically, openssh), and adding firewall and forwarding rules for port 22. Disable password authentication and rather carry an SSH key (that you password-protect, or put on a smart card) on your laptop/phone.
¹ I do recommend that people use nginx instead of apache in new deployments these days, I personally find it easier to not mess up nginx configuration, especially when server-side execution comes into play.
