DNS im Detail: E-Mail für eine Custom Domain einrichten DNS Deep Dive: Setting up Email for a Custom Domain

Als ich harisn.de registriert habe, habe ich nicht nur einen Namen gekauft; ich habe die Autorität erworben, festzulegen, wie das Internet meine digitale Präsenz findet. Aber ein Domain-Name ist ohne eine Landkarte nutzlos. Diese Landkarte ist das Domain Name System (DNS).

In meinen vorherigen Beiträgen habe ich über die Auswahl der Domain und die Wahl des Hostings (AWS vs. GitHub) gesprochen. Jetzt möchte ich den Kleber beschreiben, der alles zusammenhält: die Konfiguration von DNS-Einträgen in AWS Route 53 und das Einrichten eines sicheren E-Mail-Dienstes mit Tutanota.

Dieser Prozess umfasst zwei distinct Phasen:

1. Die Kontrolle übernehmen: Verschieben der Domain von den Standard-Nameservern des Registrars zu AWS Route 53.
2. Die Dienste konfigurieren: Hinzufügen spezifischer Einträge für meine Website (CloudFront) und meine E-Mail (Tutanota).

Hier ist die Schritt-für-Schritt-Reise, wie ich harisn.de konfiguriert habe.

Phase 1: Die Kontrolle übernehmen mit AWS Route 53

Wenn Sie eine .de-Domain bei einem Registrar (wie dem, den ich verwendet habe) registrieren, geben sie Ihnen nicht nur die Domain; sie weisen sie auch ihren eigenen Standard-Nameservern zu. Das sind die Server, die dem Internet zunächst sagen, wo es nach Ihrer Domain suchen soll.

Da ich jedoch AWS für meine Hosting-Infrastruktur nutzen wollte, musste ich diese "Telefonbuch"-Autorität zu Amazon verlagern. Dies geschieht durch das Erstellen einer Hosted Zone in Route 53.

Schritt 1: Die Hosted Zone erstellen

In der AWS Route 53-Konsole habe ich eine neue Hosted Zone für harisn.de erstellt.

Was ist eine Hosted Zone?
Stellen Sie sich eine Hosted Zone als Container für alle DNS-Einträge vor, die mit einer bestimmten Domain verknüpft sind. Sie enthält die Liste der Anweisungen wie "Die Website befindet sich unter dieser IP" oder "Senden E-Mails an diesen Server".

Sobald ich diese Hosted Zone erstellt hatte, generierte AWS automatisch vier NS (Nameserver)-Einträge für mich. Diese sahen ungefähr so aus:

• ns-123.awsdns-12.com
• ns-456.awsdns-34.net
• ns-789.awsdns-56.org
• ns-000.awsdns-78.co.uk

Schritt 2: Der Registrar-Wechsel (Delegation)

Dies ist der kritische Schritt. Um AWS zur maßgeblichen Quelle für harisn.de zu machen, musste ich mich im Portal meines Domain-Registrars einloggen und die Nameserver aktualisieren.

Ich habe die Standard-Nameservers des Registrars durch die vier von AWS bereitgestellten NS-Einträge ersetzt.

Warum ist das notwendig?
Dieser Prozess wird Delegation genannt. Durch das Aktualisieren dieser Einträge beim Sage ich dem globalen Internet effektiv: "Wenn du etwas über harisn.de wissen willst, frag mich nicht mehr. Geh diese AWS-Server fragen."

Sobald diese Änderung gespeichert war, konnte es überall zwischen wenigen Minuten und 48 Stunden dauern, bis sie weltweit propagiert ist. Während dieser Zeit konnte AWS verifizieren, dass ich die Domain besitze, weil ich die NS-Einträge kontrollierte, die zu ihnen zeigten.

Phase 2: Die Website konfigurieren (AWS-Einträge)

Mit der aktiven Hosted Zone und der Delegation konnte ich mit dem Hinzufügen von Einträgen beginnen. Die erste Priorität war meine Website.

Der Alias-Eintrag

Für meine statische Site, die auf AWS S3 und CloudFront gehostet wird, habe ich keinen Standard-A-Eintrag (der auf eine IP-Adresse zeigt) verwendet. Stattdessen habe ich einen Alias-Eintrag verwendet.

• Name: @ (dies repräsentiert die Root-Domain, harisn.de)
• Typ: A (Alias)
• Wert: Meine CloudFront-Distributions-ID (z.B. d111111abcdef8.cloudfront.net)

Warum ein Alias-Eintrag?
AWS-Alias-Einträge sind speziell. Sie erlauben es einer Root-Domain (wie harisn.de), direkt auf AWS-Ressourcen (wie CloudFront oder S3) zu zeigen, ohne die zugrundeliegenden IP-Adressen preiszugeben. Sie sind in Route 53 außerdem kostenlos und werden automatisch aktualisiert, wenn sich die AWS-Ressource ändert.

Phase 3: E-Mail mit Tutanota einrichten

Mit der Web-Routing sortiert, war die nächste Herausforderung die E-Mail. Ich wollte info@harisn.de nutzen, aber ich wollte keinen eigenen Mailserver betreiben. Ich habe Tutanota wegen seines Fokus auf Verschlüsselung und Datenschutz gewählt.

Das Einrichten einer Custom Domain bei Tutanota ist eine Partnerschaft. Tutanota stellt die Werte bereit, und ich muss sie in meine Route 53 Hosted Zone eintragen.

Schritt 1: Der Verifizierungs-Eintrag (TXT)

Bevor Tutanota mir erlaubt, E-Mails für harisn.de zu empfangen, müssen sie beweisen, dass ich die Domain tatsächlich besitze.

Im Tutanota-Einrichtungsassistenten stellten sie einen spezifischen TXT-Eintrag bereit:

• Name: @
• Typ: TXT
• Wert: t-verify=xxxxxxxxxxxx (ein eindeutiger Hash-String)

Ich habe diesen Eintrag zu Route 53 hinzugefügt. Sobald gespeichert, überprüfen die Systeme von Tutanota regelmäßig mein DNS. Wenn sie diesen spezifischen String sehen, wissen sie, dass ich administrativen Zugriff auf harisn.de habe, und sie schalten die E-Mail-Konfiguration frei.

Schritt 2: Der MX-Eintrag (Mail Exchange)

Dies ist der wichtigste Eintrag für E-Mail. Er sagt dem Internet, wohin E-Mails gesendet werden sollen, die an @harisn.de adressiert sind.

Tutanota stellte den folgenden MX-Eintrag bereit:

• Name: @
• Typ: MX
• Wert: mail.tutanota.de
• Priorität: 10

Wie es funktioniert:
Wenn jemand eine E-Mail an info@harisn.de sendet, schaut der Mailserver des Absenders den MX-Eintrag für harisn.de nach. Mein Route 53-Eintrag antwortet: "Senden Sie es an mail.tutanota.de." Die E-Mail wird dann an die Server von Tutanota zugestellt, wo sie in meinem Posteingang landet.

Schritt 3: Der SPF-Eintrag (TXT)

Spam ist ein riesiges Problem. Um zu verhindern, dass Spammer vorgeben, E-Mails von meiner Domain zu senden (Spoofing), benötige ich einen SPF-Eintrag (Sender Policy Framework).

Tutanota stellte diesen TXT-Eintrag bereit:

• Name: @
• Typ: TXT
• Wert: v=spf1 include:spf.tutanota.de ~all

Was das bedeutet:
Dieser Eintrag sagt der Welt: "Nur die Server, die in spf.tutanota.de aufgeführt sind, sind autorisiert, E-Mails im Namen von harisn.de zu senden. Wenn du eine E-Mail von harisn.de erhältst, die von woanders kam, lehne sie ab."

Schritt 4: DKIM-Einträge (CNAME)

SPF ist gut, aber es kann während der Übertragung gefälscht werden. DKIM (DomainKeys Identified Mail) fügt meinen ausgehenden E-Mails eine kryptografische Signatur hinzu.

Tutanota verlangte zwei CNAME-Einträge:

• Name: s1._domainkey → Wert: s1.domainkey.tutanota.de
• Name: s2._domainkey → Wert: s2.domainkey.tutanota.de

Wie es funktioniert:
Wenn ich eine E-Mail von Tutanota sende, hängen sie eine digitale Signatur an, die mit den Schlüsseln erstellt wurde, die unter diesen Adressen gespeichert sind. Der Mailserver des Empfängers kann diese CNAME-Einträge nachschlagen, die Signatur verifizieren und bestätigen, dass die E-Mail tatsächlich von mir stammt und nicht manipuliert wurde.

Schritt 5: Der DMARC-Eintrag (TXT)

Schließlich verknüpft DMARC (Domain-based Message Authentication, Reporting, and Conformance) SPF und DKIM. Es sagt dem empfangenden Server, was er tun soll, wenn eine E-Mail die SPF- oder DKIM-Prüfungen nicht besteht.

Tutanota stellte diesen TXT-Eintrag bereit:

• Name: _dmarc
• Typ: TXT
• Wert: v=DMARC1; p=none; rua=mailto:dmarc@harisn.de

Was das bedeutet:
"Bitte verwenden Sie DMARC1. Wenn eine E-Mail die Authentifizierung fehlschlägt (p=none), lehnen Sie sie nicht sofort ab (noch nicht), aber senden Sie einen Bericht an dmarc@harisn.de, damit ich überwachen kann, was passiert."

Zusammenfassung der finalen Route 53 Konfiguration

Nach Abschluss beider Phasen enthielt meine Route 53 Hosted Zone für harisn.de eine Mischung aus Einträgen, die unterschiedlichen Zwecken dienen:

1. NS-Einträge: Delegierung der Autorität an AWS.
2. A-Eintrag (Alias): Routing von Web-Traffic an CloudFront.
3. MX-Eintrag: Routing von E-Mail-Traffic an Tutanota.
4. TXT-Einträge: Verifizierung des Domain-Besitzes (Tutanota) und Definition von E-Mail-Richtlinien (SPF, DMARC).
5. CNAME-Einträge: Handhabung kryptografischer Schlüssel für E-Mail-Signierung (DKIM).

Fazit

Die Konfiguration von DNS mag wie langweilige Texteingabe wirken, aber sie ist das Fundament einer professionellen Web-Präsenz. Durch das Verschieben meiner Nameserver zu AWS Route 53 habe ich die volle Kontrolle über mein Traffic-Routing erlangt. Durch die sorgfältige Integration der Tutanota-Einträge habe ich sichergestellt, dass meine E-Mail nicht nur funktional, sondern auch sicher und vertrauenswürdig ist.

Jedes Mal, wenn jemand harisn.de besucht oder mir eine E-Mail sendet, interagiert er mit diesen spezifischen Einträgen. Es ist ein starkes Gefühl zu wissen, dass ich die Landkarte selbst gebaut habe.

When I registered harisn.de, I didn't just buy a name; I bought the authority to dictate how the internet finds my digital presence. But a domain name is useless without a map. That map is the Domain Name System (DNS).

In my previous posts, I talked about selecting the domain and choosing the hosting (AWS vs. GitHub). Now, I want to cover the glue that holds it all together: configuring DNS records in AWS Route 53 and setting up a secure email service with Tutanota.

This process involves two distinct phases:

1. Taking Control: Moving the domain from the registrar's default nameservers to AWS Route 53.
2. Configuring Services: Adding specific records for my website (CloudFront) and my email (Tutanota).

Here is the step-by-step journey of how I configured harisn.de.

Phase 1: Taking Control with AWS Route 53

When you register a .de domain with a registrar (like the one I used), they don't just give you the domain; they also assign it to their own default nameservers. These are the servers that initially tell the internet where to look for your domain.

However, since I wanted to use AWS for my hosting infrastructure, I needed to move that "phonebook" authority to Amazon. This is done by creating a **Hosted Zone** in Route 53.

Step 1: Create the Hosted Zone

In the AWS Route 53 console, I created a new hosted zone for harisn.de.

What is a Hosted Zone?
Think of a hosted zone as a container for all the DNS records associated with a specific domain. It holds the list of instructions like "The website lives at this IP" or "Send emails to this server."

As soon as I created this hosted zone, AWS generated four **NS (Nameserver)** records for me. These looked something like:

• ns-123.awsdns-12.com
• ns-456.awsdns-34.net
• ns-789.awsdns-56.org
• ns-000.awsdns-78.co.uk

Step 2: The Registrar Switch (Delegation)

This is the critical step. To make AWS the authoritative source for harisn.de, I had to log into my domain registrar's portal and update the nameservers.

I replaced the registrar's default nameservers with the four NS records provided by AWS.

Why is this necessary?
This process is called **Delegation**. By updating these records at the registrar, I am effectively telling the global internet: "If you want to know anything about harisn.de, don't ask me anymore. Go ask these AWS servers."

Once this change was saved, it could take anywhere from a few minutes to 48 hours to propagate worldwide. During this time, AWS was able to verify that I owned the domain because I controlled the NS records pointing to them.

Phase 2: Configuring the Website (AWS Records)

With the hosted zone active and delegated, I could start adding records. The first priority was my website.

The Alias Record

For my static site hosted on AWS S3 and CloudFront, I didn't use a standard A record (which points to an IP address). Instead, I used an **Alias Record**.

• Name: @ (this represents the root domain, harisn.de)
• Type: A (Alias)
• Value: My CloudFront Distribution ID (e.g. d111111abcdef8.cloudfront.net)

Why an Alias Record?
AWS Alias records are special. They allow a root domain (like harisn.de) to point to AWS resources (like CloudFront or S3) without exposing the underlying IP addresses. They are also free of charge in Route 53 and update automatically if the AWS resource changes.

Phase 3: Configuring Email with Tutanota

With the website routing sorted, the next challenge was email. I wanted to use info@harisn.de, but I didn't want to run my own mail server. I chose Tutanota for its focus on encryption and privacy.

Setting up a custom domain in Tutanota is a partnership. Tutanota provides the values, and I have to put them into my Route 53 hosted zone.

Step 1: The Verification Record (TXT)

Before Tutanota allows me to receive emails for harisn.de, they need to prove that I actually own the domain.

In the Tutanota setup wizard, they provided a specific **TXT record**:

• Name: @
• Type: TXT
• Value: t-verify=xxxxxxxxxxxx (a unique hash string)

I added this record to Route 53. Once saved, Tutanota's systems periodically check my DNS. When they see this specific string, they know I have administrative access to harisn.de, and they unlock the email configuration.

Step 2: The MX Record (Mail Exchange)

This is the most important record for email. It tells the internet where to send emails addressed to @harisn.de.

Tutanota provided the following MX record:

• Name: @
• Type: MX
• Value: mail.tutanota.de
• Priority: 10

How it works:
When someone sends an email to info@harisn.de, the sender's mail server looks up the MX record for harisn.de. My Route 53 record responds: "Send it to mail.tutanota.de." The email is then delivered to Tutanota's servers, where it lands in my inbox.

Step 3: The SPF Record (TXT)

Spam is a huge problem. To prevent spammers from pretending to send emails from my domain (spoofing), I need an SPF (Sender Policy Framework) record.

Tutanota provided this TXT record:

• Name: @
• Type: TXT
• Value: v=spf1 include:spf.tutanota.de ~all

What this says:
This record tells the world: "Only the servers listed in spf.tutanota.de are authorized to send email on behalf of harisn.de. If you receive an email from harisn.de that came from anywhere else, reject it."

Step 4: DKIM Records (CNAME)

SPF is good, but it can be spoofed in transit. DKIM (DomainKeys Identified Mail) adds a cryptographic signature to my outgoing emails.

Tutanota required two CNAME records:

• Name: s1._domainkey → Value: s1.domainkey.tutanota.de
• Name: s2._domainkey → Value: s2.domainkey.tutanota.de

How it works:
When I send an email from Tutanota, they attach a digital signature to it using the keys stored at these addresses. The recipient's mail server can look up these CNAME records, verify the signature, and confirm that the email was truly sent by me and hasn't been tampered with.

Step 5: The DMARC Record (TXT)

Finally, DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together. It tells the receiving server what to do if an email fails the SPF or DKIM checks.

Tutanota provided this TXT record:

• Name: _dmarc
• Type: TXT
• Value: v=DMARC1; p=none; rua=mailto:dmarc@harisn.de

What this says:
"Please use DMARC1. If an email fails authentication (`p=none`), don't reject it outright (yet), but send a report to `dmarc@harisn.de` so I can monitor what's happening."

Summary of the Final Route 53 Configuration

After completing both phases, my Route 53 hosted zone for harisn.de contained a mix of records serving different purposes:

1. NS Records: Delegating authority to AWS.
2. A Record (Alias): Routing web traffic to CloudFront.
3. MX Record: Routing email traffic to Tutanota.
4. TXT Records: Verifying domain ownership (Tutanota) and defining email policies (SPF, DMARC).
5. CNAME Records: Handling cryptographic keys for email signing (DKIM).

Conclusion

Configuring DNS might seem like tedious text entry, but it is the foundation of a professional web presence. By moving my nameservers to AWS Route 53, I gained full control over my traffic routing. By carefully integrating Tutanota's records, I ensured that my email is not only functional but also secure and trusted.

Every time someone visits harisn.de or sends me an email, they are interacting with these specific records. It's a powerful feeling to know that I built the map myself.