Hetzner DNS-instellingen correct instellen - voorbeeldconfiguratie met hetzner dns configuration

Hetzner DNS-configuratie zodat de website, subdomeinen en mail zonder omwegen werken en wijzigingen snel effect hebben. In deze handleiding laat ik je de benodigde instellingen in het Hetzner DNS zien, een beproefde voorbeeldconfiguratie en praktische testmethoden zodat je fouten in een vroeg stadium kunt voorkomen en je zone schoon kunt houden.

Centrale punten

De volgende belangrijke punten geven een snel overzicht van wat belangrijk is voor een betrouwbare DNS-zone.

• Naamserver correct invoeren bij de registrar
• A/AAAA voor web, MX/TXT voor post
• TTL Selecteer op de juiste manier en wacht op voortplanting
• SPF/DKIM tegen spam en spoofing
• Controle en testen na wijzigingen

DNS in een notendop: wat u echt nodig hebt

Ik wijs een domein toe via Records specifieke bestemmingen zodat browsers en mailservers mijn diensten kunnen vinden. A A-Record wijst naar een IPv4-adres, een AAAA naar IPv6 en een MX definieert de aflevering van e-mails. Een CNAME vormt een alias die naar een andere naam verwijst, terwijl TXT informatie bevat voor SPF of verificaties. Een schone basislijn bestaat uit A/AAAA voor het hoofddomein, CNAME voor www, MX voor mail en een SPF-TXT. Op deze manier houd ik de zone overzichtelijk, snel te onderhouden en open voor latere uitbreidingen.

Domein toevoegen aan de Hetzner DNS-console

In de DNS-console maak ik eerst een nieuwe Zone en controleer of de spelling van het domein precies goed is. Vervolgens activeer ik het handmatige onderhoud van Recordszodat ik specifieke items kan maken en wijzigen. Tip: Ik noteer IP-adressen en mailbestemmingen van tevoren, zodat ik alles ongestoord kan invoeren. Zo voorkom ik typefouten en zet ik de vermeldingen in een rustige volgorde. Zodra de zone klaar is, plan ik de wijziging van de naamservers en de daaropvolgende controles.

Voer de naamserver correct in bij de registrar

Nadat ik de zone heb gemaakt, voer ik de Naamserver van Hetzner zodat het beheer wordt gecentraliseerd in de DNS-console. De gebruikelijke ingangen zijn ns1.first-ns.de, robotns2.second-ns.de en robotns3.second-ns.com. Voor .de- of .at-domeinen stel ik mijn eigen nameservers in met Lijmkoordenzodat de referenties en IP's worden opgeslagen. Als je dit nog nooit hebt gedaan, kun je de afzonderlijke stappen vinden in de handleiding bij Lijmrecords instellen. Ik neem dan wat tijd voor het overschakelen, omdat de update met verschillende snelheden kan aankomen over de hele wereld.

Voorbeeldconfiguratie: De website en e-mail uitvoerbaar maken

Voor een typische webaanwezigheid gebruik ik een A-Record voor het hoofddomein, een CNAME voor www en geschikte mailrecords. Een SPF-TXT voorkomt dat externe servers e-mails versturen in de naam van het domein. Optioneel voeg ik een AAAA-record toe als de webserver IPv6 levert. Voor externe maildiensten zoals ForwardMX pas ik de MX aan en sla ik hun specificaties op. De volgende tabel toont een solide uitgangspunt voor veel opstellingen.

Naam	Type	Waarde	Tip
@	A	195.201.210.43	Webserver IPv4
@	AAAA	Optioneel: 2a01:4f8:xxxx:xxxx::1	Webserver IPv6
www	CNAME	@	Alias op root
@	MX	mx1.forwardmx.net	Prio 10
@	TXT	"v=spf1 include:_spf.forwardmx.net -all"	SPF tegen spoofing

DNSSEC activeren en DS-record instellen

Als manipulatiebeveiliging belangrijk voor me is, activeer ik DNSSEC voor de zone. In de Hetzner-console genereer ik hiervoor handtekeningsleutels en ontvang vervolgens de benodigde DS-gegevensdie ik deponeer bij de registrar. Ik controleer of het algoritme en de digest correct zijn overgedragen. Vervolgens wacht ik tot de keten van de registrar naar de zone goed gevalideerd is. Voor grote sleutelrotaties verlaag ik de TTL en plan ik een tijdvenster zodat resolvers de nieuwe handtekeningen op tijd zien. Belangrijk: Als er een fout optreedt tijdens de wijziging, mislukken de validaties voor ontvangers - ik houd daarom een rollback gereed (verwijder oude sleutels niet te vroeg) en test met validatieresolvers.

TTL correct instellen en propagatie begrijpen

De TTL bepaalt hoe lang resolvers een item cachen. Voor conversies kies ik een korte TTL (bijv. 300 seconden) zodat veranderingen snel zichtbaar worden. Na de definitieve instelling verhoog ik de waarden weer om aanvragen te besparen en een consistente resolutie te bereiken. Degenen die vaak implementeren houden het graag bij 600-1200 seconden, terwijl degenen die zelden wijzigingen aanbrengen 3600-14400 gebruiken. Een praktisch overzicht van de beslissing wordt gegeven door mijn blik op de Optimale TTL-selectie.

Apex-domein, CAA en certificaten onder controle

Voor SaaS-doelen op Zone Apex Ik herinner me dat CNAME is niet toegestaan op @. Daarom gebruik ik de A/AAAA van de provider of stel ik op webserverniveau een redirect in naar www. Voor de certificaattoewijzing controleer ik met CAA-gegevenswelke CA's geautoriseerd zijn om certificaten uit te geven. Ik onderhoud bijvoorbeeld alleen de CA die ik daadwerkelijk gebruik en voeg optioneel een mailadres toe voor rapporten. Als ik de CA wijzig, verhoog ik kort de TTL en werk ik CAA bij voordat ik het certificaat uitgeef. Voor wildcards via ACME DNS-01 zorg ik ervoor dat TXT-records onder _acme-uitdaging kan snel worden ingesteld en automatisch worden opgeschoond zodat er geen oude uitdagingen achterblijven.

Maak netjes subdomeinen en services aan

Voor elk subdomein maak ik een geschikte A- of CNAME-record, afhankelijk van of het subdomein rechtstreeks naar een IP of naar een naam verwijst. Voorbeeld: blog.example.de als A-record naar de blog VM, cdn.example.de als CNAME naar een CDN-naam. Voor API's maak ik een strikt onderscheid tussen interne en openbare namen om risico's te vermijden. Gestandaardiseerde namen zoals api, app, img helpen bij onderhoud en monitoring. Op deze manier houd ik de zone gestructureerd en kan ik wijzigingen duidelijk toewijzen.

Wildcards, SRV en speciale recordtypes

Ik gebruik Wildcard Records (*.example.de), bijvoorbeeld voor opstellingen met meerdere clients. Ik zorg ervoor dat exacte vermeldingen altijd voorrang hebben op jokertekens. Voor services zoals SIP, Matrix of Autodiscover maak ik SRV-records en controleer het formaat en de prioriteiten. TXT records met lange inhoud (bijv. 2048-bits DKIM) worden opgesplitst in meerdere aanhalingsegmenten zodat parsers ze correct kunnen samenvoegen. Ik vermijd meerdere SPF-records en combineer vermeldingen in een geldige SPF om de opzoeklimiet niet te doorbreken.

Betrouwbare e-mailaflevering: SPF, DKIM en DMARC

Voor betrouwbare e-mail gebruik ik de MX een schone SPF-TXT die mijn verzendsystemen dekt. Ik activeer ook DKIM bij de gebruikte mailservice en publiceer de DKIM selector als TXT onder selector._domainkey. Ik gebruik DMARC om te definiëren hoe ontvangers omgaan met mails die niet door SPF/DKIM komen. Ik begin vaak met "p=none", evalueer rapporten en schakel later over op "quarantaine" of "afwijzen". Deze volgorde vermindert risico's en verhoogt geleidelijk de afleverkwaliteit.

Verdieping SPF/DKIM/DMARC in de praktijk

Ik houd SPF zo beperkt mogelijk: alleen noodzakelijk opnemen-mechanismen en nooit meer dan één SPF per hostnaam. Om te voldoen aan de limiet van 10 DNS lookups, verklein ik ketens of gebruik ik IP4/IP6-mechanismen als deze stabiel zijn. Voor DKIM rotatie Ik gebruik twee actieve selectors (oud/nieuw), publiceer de nieuwe sleutel, schakel de e-mailservice over en verwijder de oude pas na een paar dagen. Met DMARC In eerste instantie stel ik rapportageadressen in (rua/ruf) en controleer ik de uitlijning (aspf/adkim). Voor subdomeinen kan ik het volgende gebruiken sp= een afzonderlijk beleid definiëren als ze afzonderlijk verzenden. Op deze manier reageer ik op echte verkeersgegevens in plaats van aannames.

Omgekeerde DNS (PTR) voor schone mailaflevering

Naast MX, SPF en DKIM heb ik het volgende ingesteld Omgekeerde DNS (PTR) voor uitgaande mailservers. De PTR van het IP wijst naar een hostnaam, die op zijn beurt correct naar hetzelfde IP verwijst via A/AAAA (Vooruit/achteruit match). Ik stel PTR per IP direct in bij de IP-eigenaar (bijv. in de serverinterface) - niet in het zonebeheer van het domein. Ik gebruik het nibble-formaat voor IPv6. Een geschikte PTR vermindert spamclassificaties en helpt bij reputatie. Als mail via een externe service loopt, laat ik zijn PTR zoals hij is en vermijd ik gemengde afzenderbronnen zonder SPF-aanpassing.

Typische fouten en snelle oplossingen

Als een domein niet wordt omgezet, controleer ik eerst TTLnaamserververmeldingen en de juiste spelling van de records. De tweede blik gaat naar de PropagatieSommige resolvers cachen langer, vooral nadat de TTL is verhoogd. Ik vergelijk de resolutie met verschillende DNS-checkers om regionale verschillen te herkennen. Bij lokale problemen schakel ik tijdelijk over op publieke resolvers zoals 1.1.1.1 of 8.8.8.8. Als de fout alleen optreedt in interne netwerken, controleer ik interne resolvers en regels in containers, Kubernetes of CoreDNS-configuraties.

Testmethoden: dig, nslookup en end-to-end

Ik test niet alleen records, maar het hele pad:

• graven A/AAAA/CNAME/MX/TXT: Antwoorden, TTL en autoriteit controleren
• graven + opsporenZie delegatieketen en naamservergedrag
• SMTP-testsControleer HELO/EHLO, TLS en banner
• HTTPS echtCertificaatketen, hostnaam, omleidingen

Op deze manier herken ik ook fouten die niet zichtbaar zijn in pure DNS-reacties, zoals onjuiste VirtualHost-toewijzingen of verlopen certificaten. Na het aanbrengen van wijzigingen wacht ik ten minste één TTL af voordat ik definitieve conclusies trek.

Efficiënt werken met de Hetzner console

Ik groepeer verwante Inzendingen tijd, stel een korte TTL in voordat ik grote wijzigingen aanbreng en publiceer alles dan in één keer. Voordat ik opsla, controleer ik nogmaals MX-prioriteiten, SPF-syntaxis en het doel-IP van het A-record. Voor serverbeheer en -processen zijn de compacte instructies op Hetzner Robot tips. Na implementaties test ik http, https en mail met echte verzoeken, niet alleen via ping. Hierdoor kan ik fouten herkennen die pure DNS-query's niet laten zien.

Automatisering: API, sjablonen en ACME

Ik bespaar tijd door te automatiseren. Voor regelmatige implementaties gebruik ik de API van de DNS-console om records aan te maken, te wijzigen of te verwijderen. Ik werk met sjablonen voor terugkerende patronen (bijv. Web + Mail + DMARC) en voeg alleen projectspecifieke waarden toe. Voor Let's Encrypt DNS-01 voeg ik een geautomatiseerde TXT-recordschrijver toe en integreer deze in de vernieuwingsworkflow. Belangrijk: ik behandel API tokens als wachtwoorden, wijs ze toe aan specifieke projecten en trek de toegang in als ze niet langer nodig zijn.

Geavanceerde opstellingen: Split-Horizon, CDN en ACME

Ik scheid interne en externe gebruikers indien nodig DNS-views zodat de interne app naar privé-IP's wijst en bezoekers naar openbare bestemmingen. Gebruik ik een CDNIk verwijs subdomeinen naar de CDN-naam via CNAME en activeer TLS daar. Voor automatische certificaten via ACME/Let's Encrypt stel ik optioneel DNS-01 uitdagingen in via TXT als HTTP-01 niet overeenkomt. Automatisering is hier belangrijk zodat vernieuwingen op tijd worden uitgevoerd. Logs en meldingen helpen om fouten op tijd te herkennen.

Prestatie- en beschikbaarheidspatronen

Ik verhoog de beschikbaarheid met eenvoudige middelen: Verschillende A/AAAA records (round robin) belasting delen zonder extra diensten, op voorwaarde dat de backends stateless zijn of sessies delen. Tijdens onderhoud verwijder ik tijdelijk individuele IP's en verhoog dan de entry weer. Een te korte TTL kan resolvers belasten; ik vind een balans tussen reactiesnelheid en cache hit rate. Ik stel duidelijke processen in voor failovers zonder health checks: In het geval van een fout verwissel ik entries, controleer ze actief en reset ze weer na herstel.

Veiligheid en zonehygiëne

Ik deactiveer onnodige Zoneoverdrachten (AXFR) en publiceer alleen de NSdie echt gezaghebbend zijn. Ik verwijder regelmatig oude of verweesde subdomeinen zodat er geen schaduwvlakken ontstaan. Voor IDN's controleer ik de Punycode-spelling om typefouten en fouten met speciale tekens te voorkomen. Rolgebaseerde toegang in de console zorgt ervoor dat alleen de juiste mensen zones wijzigen. En heel pragmatisch: ik documenteer wijzigingen kort in de teamtool - dit vermindert het aantal vragen tijdens het gebruik aanzienlijk.

Migratie- en terugdraaistrategie

Voor een verhuizing verlaag ik de TTL (24-48 uur van tevoren), spiegel alle Records in de nieuwe zone en test de resolutie rechtstreeks via de nieuwe nameservers. Pas als alles correct is, stel ik de Naamserver bij de registrar. Na de delegatie controleer ik het verkeer en de fouten. Als er iets fout gaat, rol ik dit gecontroleerd terug of corrigeer ik afzonderlijke vermeldingen. Ik plan DNSSEC-migraties bijzonder conservatief en laat de oude handtekeningsketen op zijn plaats totdat de nieuwe veilig is. Tot slot zet ik de TTL terug naar productieconforme waarden.

Korte vergelijking van providers voor prestaties en flexibiliteit

Prestaties, functies en DNS-vrijheid beslissen hoe flexibel ik projecten uitrol. In de praktijk leveren de grote hosters solide Reactietijdenmaar verschillen qua werking, functies en ondersteuning. Ik beoordeel de selectie op basis van prestaties, scala aan functies, kwaliteit van de hulp en DNS-opties. Het volgende overzicht geeft een beknopt beeld dat ik kan gebruiken om beslissingen te nemen. Uiteindelijk gaat het om wat mijn project echt nodig heeft, niet om de grootste lijst met functies.

Aanbieder	Prestaties	Functieomvang	Steun	DNS-flexibiliteit	Rangschikking
webhoster.de	Hoog	Zeer uitgebreid	Top	Maximaal	1
Hetzner	Hoog	Uitgebreid	Goed	Hoog	2
Contabo	Medium	Standaard	O. K.	Medium	3

Kort samengevat

Ik stel een Hetzner DNS-zone op een gestructureerde manier: Zone aanmaken, naamserver opgeven bij registrar, core records instellen voor web en mail en dan testen. Met geschikte TTL Ik verkort de wisseltijden en verhoog ze weer na afloop voor minder belasting. SPF, DKIM en DMARC versterken de aflevering en beschermen het domein tegen misbruik. Ik houd subdomeinen consistent en scheid interne van publieke bestemmingen. Met deze voorbeeldconfiguratie en de dagelijkse controles blijft je hetzner dns-configuratie betrouwbaar, snel en eenvoudig te onderhouden.