Belangrijkste punten
- Forward en reverse DNS zijn aparte systemen: het toevoegen van een DNS-naam maakt niet automatisch de bijbehorende reverse vermelding aan, dus beide kanten moeten apart worden beheerd.
- Ontbrekende reverse DNS veroorzaakt subtiele maar ernstige problemen: de meeste systemen maken nog steeds verbinding. Maar e-mailbezorging, beveiligingstools en logs worden onbetrouwbaar of minder goed te vertrouwen.
- DNS vereist doorlopend onderhoud om nauwkeurig te blijven: DHCP-wijzigingen, veroudering en scavenging zijn nodig om te voorkomen dat oude of onjuiste records zich opstapelen en het systeem vervuilen.
- Reverse DNS is belangrijk waar identiteit en vertrouwen nodig zijn: e-mailservers, security monitoring en beheertools zijn er meer van afhankelijk dan gewone gebruikerssubnetten.
- Duidelijk eigenaarschap en regelmatige controles voorkomen stille storingen: toegang beperken, wijzigingen loggen en lookups vanaf clients valideren houden DNS betrouwbaar en controleerbaar.
Fouten bij het instellen en configureren van forward en reverse DNS kunnen de connectiviteit en beveiliging van uw bedrijfsnetwerk ernstig schaden. Deze gids legt de beste praktijken uit die u moet volgen wanneer u forward en reverse DNS-lookups configureert, inclusief PTR-records, DNS-veroudering en scavenging.
Wat is DNS?
DNS (Domain Name System) is het gedistribueerde client-serversysteem dat domeinnamen (zoals www.example.com) koppelt aan de IP-adressen van servers. Het bestaat zodat u namen kunt gebruiken om naar websites te navigeren, e-mails te versturen en andere diensten te benaderen, in plaats van moeilijk te onthouden IP-adressen. DNS-servers slaan DNS-records op die namen aan IP-adressen koppelen, die uw apparaten vervolgens opzoeken via een DNS-resolver. Voor de beheersbaarheid zijn DNS-records opgedeeld in zones per domein of subdomein, waarbij elke zone een eigen zonebestand heeft waarin de records worden vastgelegd.
Wat is het verschil tussen een forward en een reverse DNS-lookup?
Een forward DNS-lookup vindt plaats wanneer een domeinnaam wordt ingevoerd en er een IP-adres (IPv4 of IPv6) wordt teruggegeven. Een reverse DNS-lookup is precies het tegenovergestelde: er wordt een IP-adres ingevoerd en de bijbehorende domeinnaam wordt teruggegeven.
Hiervoor is een PTR-record (pointer record) nodig dat een speciale in-addr.arpa-domeinnaam gebruikt (.ip6.arpa voor IPv6) om IP-adressen met omgekeerde segmenten op te slaan. Zo wordt 192.168.0.1 bijvoorbeeld 1.0.168.192.in-addr.arpa. Deze records staan in een eigen zone en zonder PTR-record werkt reverse DNS niet, omdat er dan geen manier is om te bepalen welke domeinnaam bij een IP-adres hoort.
Waarom u zowel forward als reverse DNS nodig hebt
Forward en reverse DNS-lookupzones worden niet automatisch gesynchroniseerd en het aanmaken van een forward DNS-record maakt niet meteen het omgekeerde record aan. U moet dus beide onderhouden. Reverse DNS en PTR-records zijn geen vereiste bij het opzetten van DNS (anders dan forward lookups, want zonder die records zou het hele DNS-systeem zinloos zijn) en blijven daarom vaak ongeconfigureerd. Toch zijn ze voor sommige toepassingen van groot belang, zeker voor e-mail.
Tools voor spamdetectie gebruiken reverse DNS om te controleren of een e-mail daadwerkelijk afkomstig is van de server die wordt opgegeven. Dat helpt spam en e-mailspoofing te voorkomen. De meeste e-mailsystemen weigeren berichten van een domein waarvoor geen reverse DNS is geconfigureerd.
Reverse DNS is ook handig voor IT-beheerders en ontwikkelaars die leesbare domeinnamen willen zien in query’s en logbestanden.
Wat u nodig hebt om forward en reverse DNS-lookupzones in te stellen
Er zijn vaste beste praktijken die u bij het aanmaken van forward en reverse DNS-lookupzones kunt volgen om netwerkproblemen te voorkomen en de beveiliging te waarborgen.
| Beste praktijk voor DNS | Resultaat | Werkelijke meerwaarde |
| Pariteit tussen forward en reverse DNS-records | Nauwkeurige recordkoppeling | Logs en security-analytics zijn nauwkeuriger en beter te begrijpen |
| Beveiligde DHCP-updates | Regelmatig ververste DNS-gegevens | Minder verouderde of ontbrekende records |
| Veroudering en scavenging van DNS-records | Betere DNS-hygiëne | Schonere zonerecords op termijn |
| Validatie vanaf DNS-clients | Zekerheid dat DNS correct werkt | Vertrouwen in de werking en het beveiligingsbeleid |
| Toegangsbeheer en logging | Governance en toezicht | Betrouwbare, controleerbare DNS-activiteiten |
Om dit te bereiken, hebt u het volgende nodig:
- Een lijst met gezaghebbende DNS-zones en IP-subnetten die reverse lookupzones nodig hebben
- Toegang tot beheertools voor DNS en DHCP
- Vastgelegde wijzigingsvensters voor configuratie, testen en uitrol
- Testhosts op elke locatie of in elk subnet voor validatie vanaf de client
- Toegang tot de command line of PowerShell voor DNS-lookups en cachecontroles
Beste praktijk 1: plan zones en DNS-records en wijs eigenaarschap toe
Planning is bepalend voor de effectiviteit van elk IT-systeem op de lange termijn. Breng bij het ontwerp van uw DNS-implementatie zorgvuldig uw forward zones en subdomeinen in kaart en daarna uw reverse zones, zodat beide met elkaar in lijn liggen. Reverse DNS is weliswaar niet verplicht, maar zorg dat het geconfigureerd is voor zones die uitgaande e-mail verwerken. Duidelijk eigenaarschap draagt bovendien bij aan de betrouwbaarheid en beveiliging van uw DNS-systeem en houdt uw IT-team optimaal ingericht.
Beste praktijk 2: maak de juiste soorten records aan voor forward lookups
Zorg dat u bij het configureren van uw DNS-systeem de juiste soorten DNS-records aanmaakt. Gebruik A- en AAAA-records voor statische hosts en belangrijke diensten en CNAME-records (canonical name) voor namen richting clients die kunnen veranderen. Zo hoeft u clientconfiguraties die naar CNAME-records verwijzen niet aan te passen wanneer de domeinnaam waarvoor ze een alias zijn wijzigt.
Beste praktijk 3: maak reverse lookupzones en PTR-records die overeenkomen met uw forward DNS-records
Zorg er bij het aanmaken van de PTR-records voor uw reverse lookupzones voor dat ze overeenkomen met uw bestaande A- en AAAA-records. Controleer voor subnetten die u niet zelf beheert of de upstream-autoriteit voor openbare netwerken klopt of stem de delegatie af met de beherende partij.
Beste praktijk 4: schakel beveiligde dynamische updates in met DHCP
Automatische DNS-registratie via DHCP kunt u gebruiken als uw DHCP-server dit ondersteunt (op Windows Server heet dit “dynamische DNS-updates”). Clientapparaten kunnen hiermee hun records bij de DNS-server bijwerken wanneer hun IP-adres verandert, waardoor er minder handmatig beheer nodig is. Gebruik beveiligde updates en configureer veroudering en scavenging met de juiste timing (op basis van het gedrag van apparaten in uw netwerk) om de hygiëne en beveiliging van uw netwerk verder te verbeteren.
Beste praktijk 5: valideer resolutie en caching van begin tot eind
Gebruik op clientapparaten (bijvoorbeeld Windows-werkstations) lokale DNS-testtools om forward en reverse lookups te testen en te controleren of ze correct zijn geconfigureerd en worden toegepast. Gebruik de opdrachten nslookup of ipconfig vanuit de Windows-opdrachtprompt of Resolve-DnsName vanuit PowerShell. Gebruik op Linux of macOS het DNS-lookupprogramma dig.
U kunt het uitvoeren van bovenstaande opdrachten op clientapparaten automatiseren en de uitvoer verzamelen met platforms voor monitoring en beheer op afstand (RMM). Houd na wijzigingen ook de logs van uw DNS-server in de gaten om te bevestigen dat registraties zijn gelukt.
Beste praktijk 6: los veelvoorkomende storingen op
Er zijn verschillende veelvoorkomende problemen waar u op moet letten nadat u wijzigingen hebt aangebracht in uw forward en reverse DNS-zones:
- Forward lookups werken wel, maar reverse lookups mislukken omdat er geen bijbehorende PTR-records zijn aangemaakt.
- Reverse DNS-lookups die de verkeerde naam teruggeven, komen meestal door verouderde PTR-records of dubbele A/AAAA-records.
- NXDOMAIN-fouten (Non-Existent Domain) ontstaan wanneer er geen record voor het domein gevonden kan worden.
- Overschrijvingen in het lokale hosts-bestand op clients kunnen zowel forward als reverse lookups verstoren.
Er zijn daarnaast nog andere redenen waarom een DNS-server niet reageert, zoals time-outs, firewalls en onbereikbare servers, die u zowel op client- als netwerkniveau kunt onderzoeken.
Beste praktijk 7: governance en beveiliging
DNS is een kernonderdeel van uw netwerk en gebrekkige configuraties kunnen worden misbruikt voor cyberaanvallen. Beperk wie records mag beheren en log en beoordeel alle wijzigingen. Controleer regelmatig uw instellingen voor veroudering en scavenging, zodat uw DHCP- en DNS-records schoon blijven en er geen stapel verouderde records ontstaat. Let op ongebruikelijke aantallen nieuwe A- of PTR-records, want die kunnen wijzen op een DNS-spoofingaanval.
NinjaOne automatiseert de configuratie en validatie van forward en reverse DNS
Zelfs de best geplande DNS-systemen gaan achteruit door configuratiedrift, verouderde records en veranderende eisen als ze niet voortdurend worden gemonitord en onderhouden.
NinjaOne biedt een geautomatiseerd platform voor IT-monitoring en -beheer dat taken kan inplannen om DNS- en DHCP-records en -logs te exporteren, deze te vergelijken met actieve leases en inventaris en ontbrekende PTR-records en verouderde records te markeren. Validatielookups kunnen vanaf clients worden gescript om de werking van begin tot eind te waarborgen en rapporten kunnen worden gegenereerd en opgeslagen in het ingebouwde platform voor IT documentatie van NinjaOne.
Wanneer actie nodig is, kan NinjaOne automatisch helpdesktickets aanmaken en indien nodig escaleren. Zo is uw DNS-systeem altijd volgens de beste praktijken geconfigureerd en vormt het een kleiner risico als aanvalsvector.
