DNS-subzone: wat het is en hoe het werkt binnen een DNS-zone

Informatic Digital » Middelen » DNS-subzone: wat het is en hoe het werkt binnen een DNS-zone

Als je met domeinen en hosting werkt , of simpelweg een website beheert, kom je vroeg of laat termen tegen zoals DNS-zone, subzone, zonebestanden en records . Ze klinken technisch, maar zodra je ze in de praktijk brengt, zul je zien dat het allemaal heel logisch is en dat je met een paar duidelijke ideeën je eigen DNS kunt beheren zonder de weg kwijt te raken.

In de volgende alinea's zullen we rustig onderzoeken wat een DNS-zone en een subzone zijn, hoe ze passen in de hiërarchie van het domeinnaamsysteem, welke soorten zones er bestaan , hoe ze worden toegewezen, wat de meest voorkomende records zijn, welke problemen zich voordoen en hoe deze te voorkomen zijn. Dit alles wordt in begrijpelijke taal uitgelegd, zonder aan technische nauwkeurigheid in te boeten.

Even een korte samenvatting: hoe DNS intern werkt

Om te begrijpen wat een DNS-subzone is, moet je eerst het Domain Name System (DNS) zelf begrijpen . Het DNS is een hiërarchisch en gedistribueerd systeem dat voor mensen leesbare namen (zoals example.com) vertaalt naar IP-adressen die computers kunnen begrijpen.

Veel mensen vergelijken DNS met een "internet telefoonboek", hoewel het idee van een contactenlijst op een mobiele telefoon tegenwoordig beter past : je zoekt op naam en het systeem vindt het nummer zonder dat je het hoeft te onthouden.

Wanneer je een domein in je browser typt, wordt er een DNS-query (opzoeking of resolutie) gestart . Het apparaat van de gebruiker vraagt ​​een "recursieve resolver" (meestal de DNS van je internetprovider of een openbare dienst zoals Google of Cloudflare) om informatie, en die resolver raadpleegt verschillende DNS-servers totdat het juiste record is gevonden.

De resolutie volgt een zeer duidelijke hiërarchische structuur: eerst worden de rootservers geraadpleegd , die de DNS-rootzone beheren en aangeven welke servers elk top-level domein (TLD) zoals .com, .es, .ovh, enz. bevatten.

Vervolgens vraagt ​​de resolver de naamserver voor het betreffende TLD (.com, .gov, .ovh, enz.) op welke naamservers gezaghebbend zijn voor het specifieke domein, bijvoorbeeld mydomain.com. Ten slotte reageren die gezaghebbende naamservers voor het domein met de specifieke DNS-records: het IP-adres van de website , de mailserver, subdomeinen, enz.

Domeinhiërarchie, FQDN en gelaagde structuur

Dit hele systeem is gebaseerd op het feit dat een domein is opgebouwd uit blokken die gescheiden worden door punten , die van rechts naar links worden opgelost. De volledig gekwalificeerde domeinnaam, de bekende FQDN (Fully Qualified Domain Name), omvat al deze niveaus en eindigt met een punt, hoewel die laatste punt normaal gesproken niet in de browser wordt weergegeven.

In een naam als support.mydomain.ovh is het meest rechtse blok dus de TLD (.ovh) , links daarvan het tweede-niveaudomein (mydomain), en daarna komen de subdomeinen (support, www, blog, enz.). De DNS lost elk blok in omgekeerde volgorde op: eerst de root, dan de TLD, dan het domein en dan het subdomein.

Elke internetverbinding heeft doorgaans minstens één primaire en één secundaire DNS-server , die automatisch via DHCP worden verkregen. De secundaire server dient als back-up voor het geval de primaire server uitvalt, waardoor websites en diensten toegankelijk blijven.

Wanneer een DNS-server een query ontvangt, kan deze op twee manieren reageren: als de server het domein al kent omdat het in de cache is opgeslagen, reageert hij direct met behulp van de opgeslagen informatie, beperkt door de TTL-parameter (Time To Live) ; als de server het domein niet kent, start hij de volledige queryketen via de root-, TLD- en autoritatieve servers totdat hij de zone bereikt die het gevraagde subdomein of domein bevat.

Wat is een DNS-zone en wat is een DNS-subzone?

Binnen die grote boom van namen is de DNS-ruimte georganiseerd in DNS-zones . Een DNS-zone is een deel van de naamruimte dat wordt beheerd door een specifieke entiteit (een bedrijf, een hostingprovider of een beheerder).

In de praktijk is een DNS-zone een administratieve eenheid: deze definieert de reikwijdte van de bevoegdheid om records aan te maken, te wijzigen en te verwijderen . Een zone kan alleen het basisdomein omvatten (bijvoorbeeld ecohosting.cl) of ook een of meer subdomeinen daarvan.

Stel je voor dat het domein ecohosting.cl de volgende subdomeinen heeft: support.ecohosting.cl, clients.ecohosting.cl en blog.ecohosting.cl. Als support en clients eenvoudige services zijn die gekoppeld zijn aan de hoofdhosting, is het handig om ze in dezelfde zone als ecohosting.cl te beheren. Maar als de blog een onafhankelijk project is, ontwikkeld door een ander team of bij een andere provider, is het volkomen logisch om er een eigen DNS-zone aan toe te wijzen.

In dat geval zouden ecohosting.cl, soporte.ecohosting.cl en clientes.ecohosting.cl een zone delen, terwijl blog.ecohosting.cl een gedelegeerde DNS-subzone zou vormen , met eigen naamservers en zonebestand. Dit is waar het concept van een "DNS-subzone" om de hoek komt kijken: een deel van het domein dat aan een andere zone wordt toegewezen om de controle te delegeren.

DNS-zones hoeven niet fysiek van elkaar gescheiden te zijn op verschillende servers; het is meer een logische scheiding om bevoegdheden te delegeren . Een enkele naamserver kan meerdere zones hebben, elk met een eigen onafhankelijk zonebestand.

Soorten DNS-zones: primair, secundair, forward, reverse en stub

Als je je wat dieper verdiept in DNS-beheer, zul je zien dat niet alle zones hetzelfde zijn. Er bestaan ​​verschillende soorten DNS-zones , ontworpen om aan verschillende behoeften binnen de infrastructuur te voldoen.

De primaire DNS-zone is de belangrijkste lees-/schrijfkopie van een zone. De gegevens ervan worden opgeslagen in een masterbestand op een specifieke server, en alle wijzigingen in de records moeten daar worden doorgevoerd. Er kan slechts één masterbestand per zone op een bepaalde server aanwezig zijn.

De secundaire DNS-zone is een alleen-lezen kopie van de primaire zone. Deze wordt gesynchroniseerd met de masterzone door middel van volledige AXFR- of incrementele IXFR-overdrachten. De belangrijkste functie ervan is het bieden van redundantie en beschikbaarheid : als de primaire server uitvalt, kunnen resolvers de secundaire servers die in de NS-records zijn opgenomen, blijven bevragen.

We hebben ook de zogenaamde forward lookup zone , die wordt gebruikt om domeinnamen om te zetten in IP-adressen. Deze zone slaat A-records (voor IPv4) en AAAA-records (voor IPv6) op, samen met andere soorten records die aan de naam zijn gekoppeld.

Aan de andere kant is er de omgekeerde opzoeking , die precies werkt: deze retourneert de domeinnaam op basis van een IP-adres met behulp van PTR-records. Het is heel gebruikelijk dat e-mailservices en beveiligingssystemen deze omgekeerde relatie controleren om te valideren dat een IP-adres daadwerkelijk overeenkomt met het domein dat het claimt te zijn.

Ten slotte is er een speciaal type zone, een zogenaamde stubzone . Dit is een gereduceerde versie van een zone die alleen essentiële gegevens bevat: NS om gezaghebbende servers te identificeren, A/AAAA om die servers vindbaar te maken en de SOA. Dit type zone helpt grote netwerken om actuele lijsten met gezaghebbende servers voor gedelegeerde zones bij te houden zonder dat alle gegevens hoeven te worden opgeslagen.

DNS-zonebestanden en sleutelelementen

Alle informatie voor een zone wordt opgeslagen in het DNS-zonebestand , een gewoon tekstbestand op de naamserver. Elke regel vertegenwoordigt een resource record en de verzameling van alle records beschrijft volledig hoe dat domein en de bijbehorende subdomeinen moeten worden opgelost.

Elk zonebestand moet beginnen met een Start of Authority (SOA)-record . De SOA specificeert de primaire naamserver voor de zone, de technische leider, serienummers en tijdstempels die de caching, overdrachten naar secundaire servers en herhaalpogingen regelen.

Een cruciale parameter in dit alles is de Time To Live (TTL) , die resolvers vertelt hoe lang ze elk record in de cache mogen bewaren voordat ze het opnieuw opvragen. Een hoge TTL vermindert het DNS-verkeer, maar zorgt ervoor dat wijzigingen langer nodig hebben om te worden doorgevoerd; een lage TTL versnelt wijzigingen, maar verhoogt het aantal query's.

Deze zonebestanden bevatten verschillende soorten records: IP-adressen, mailservers, tekstrecords voor e-mailbeveiliging, subdomeinaliassen, enzovoort. Elk record gebruikt een zeer specifieke DNS-syntaxis , vergelijkbaar met kleine "instructies" die de server begrijpt om te weten hoe te reageren.

Meest voorkomende typen DNS-records in een zone of subzone

Binnen een DNS-zone werk je voornamelijk met een specifieke set records. Dit zijn de meest voorkomende DNS-records die je tegenkomt bij het beheren van een zone of subzone.

Het A-record koppelt een domeinnaam of subdomein aan een IPv4-adres. Bijvoorbeeld: www.mydomain.com verwijst naar 203.0.113.10. Het is essentieel dat een website vanaf een specifiek IP-adres wordt geladen.

Het AAAA-record dient hetzelfde doel, maar verwijst naar een IPv6-adres. Het wordt steeds vaker gebruikt in moderne omgevingen, vooral als uw provider IPv6 volledig ondersteunt.

MX-records geven aan welke mailservers verantwoordelijk zijn voor het ontvangen van e-mails voor het domein. Ze worden meestal vergezeld door een numerieke prioriteit die aangeeft welke server als eerste wordt gebruikt en welke als back-up dienen.

CNAME-records worden gebruikt om aliassen te creëren: een naam verwijst naar een andere naam, niet naar een IP-adres. Zo zou blog.mydomain.com een ​​CNAME-record kunnen zijn voor mydomainblog.externalhosting.com. Ze geven niet direct een IP-adres terug, maar verwijzen door naar een andere naam die wel een IP-adres heeft.

NS-records specificeren welke naamservers gezaghebbend zijn voor een zone of subzone. Ze zijn essentieel voor delegatie: wanneer u een DNS-subzone voor een subdomein aanmaakt, registreert u NS-records in de hoofdzone die verwijzen naar de gezaghebbende servers voor die subzone.

Het bovengenoemde SOA-record slaat de autorisatiegegevens op: masterserver, e-mailadres van de beheerder (speciaal geformatteerd), zoneserienummer en diverse vernieuwingstijden, herhaalpogingen, vervaldatum en minimale TTL.

TXT-records slaan willekeurige tekstreeksen op die aan een domein zijn gekoppeld. Ze worden veel gebruikt voor e-mailbeveiliging (SPF, DKIM, DMARC), domeinverificatie met externe services (Google, Microsoft, enz.) en diverse metadata.

SRV-records geven aan welke host en poort een specifieke service leveren (bijvoorbeeld VoIP, berichtenverkeer of bepaalde interne services), terwijl PTR-records in reverse zones worden gebruikt om IP-adressen aan domeinnamen te koppelen.

Minder vaak voorkomende maar belangrijke DNS-records

Naast de klassieke records definieert de DNS-standaard een flink aantal minder bekende records die in zeer specifieke contexten worden gebruikt, vaak gerelateerd aan beveiliging of geavanceerde diensten.

Het AFSDB-register is ontworpen voor het Andrew Distributed File System (AFS) en helpt bij het lokaliseren van AFS-cellen in netwerkopslagstructuren.

Het APL-register is experimenteel en wordt gebruikt om lijsten met adresbereiken op te slaan, iets wat in gangbare omgevingen zeer ongebruikelijk is.

CAA-records worden steeds belangrijker: ze stellen domeineigenaren in staat te specificeren welke certificeringsinstanties (CA's) certificaten voor dat domein mogen uitgeven , waardoor de beveiliging van de TLS-laag wordt versterkt. Zonder een CAA zou elke CA certificaten voor dat domein kunnen uitgeven.

Het DNSKEY-record slaat de openbare sleutels op die worden gebruikt door DNSSEC (Domain Name System Security Extensions), de set extensies die cryptografische handtekeningen toevoegt aan DNS-records om manipulatie te voorkomen.

Het CDNSKEY-record is in feite een "dochter"-kopie van DNSKEY, bedoeld om naar de bovenliggende zone te worden overgedragen en zo validatie in DNSSEC-strings mogelijk te maken.

Het CERT-register slaat openbare sleutelcertificaten op, terwijl het DHCID-register informatie opslaat die door DHCP (het dynamische hostconfiguratieprotocol) wordt gebruikt om toewijzingen te coördineren en conflicten te voorkomen.

Het DNAME-record is vergelijkbaar met een CNAME-record, maar op een ander niveau: het creëert een complete domeinalias, zodat niet alleen de naam waarnaar wordt verwezen, maar ook al zijn subdomeinen worden doorverwezen naar een andere naamstructuur.

Het LOC-record kan geografische informatie (breedtegraad, lengtegraad, hoogte) opslaan die aan een domein is gekoppeld. Deze informatie wordt soms gebruikt in geolocatieservices of interne documentatie.

Het NAPTR-register in combinatie met SRV maakt het mogelijk om dynamisch service-URI's te creëren op basis van patronen, wat nuttig is in bepaalde Voice over IP- of berichtenapplicaties.

In de DNSSEC-wereld bestaan ​​er ook NSEC-records , die dienen om cryptografisch te bewijzen dat een record NIET bestaat, en RRSIG-records , die de digitale handtekeningen van recordsets opslaan.

Ten slotte zijn er nog andere, zoals het RP-record (responsible person) , dat verwijst naar het e-mailadres van de domeineigenaar, of het SSHFP-record , waarmee SSH-openbare sleutelvingerafdrukken kunnen worden gepubliceerd om de beveiliging van externe verbindingen te versterken.

DNSSEC, beveiliging en best practices voor zonebeheer

DNS-zones en -subzones zijn aantrekkelijke doelwitten voor aanvallers, omdat het wijzigen van zelfs maar een paar records webverkeer kan omleiden, e-mails kan kapen of diensten kan imiteren . Daarom is de beveiliging van zonebeheer zo cruciaal.

Een eerste stap is het beschermen van uw DNS-beheergegevens (of het nu cPanel, Plesk, een providerspecifiek paneel of een paneel zoals core-admin is). Het is raadzaam om sterke wachtwoorden te gebruiken, toegang niet te delen en waar mogelijk tweefactorauthenticatie in te schakelen.

Door DNSSEC in te schakelen, wordt een extra beveiligingslaag toegevoegd: DNS-records worden digitaal ondertekend en resolvers die DNSSEC valideren, kunnen detecteren of iemand probeert valse antwoorden te injecteren of records tijdens de overdracht te manipuleren.

Het is ook cruciaal om elke wijziging in een record zorgvuldig te controleren om configuratiefouten te voorkomen: een onjuiste prioriteit in MX , een verkeerd gespeld IP-adres in een A, een CNAME die in een oneindige lus terechtkomt of een ontbrekende punt aan het einde van een naam kunnen ervoor zorgen dat uw website of e-mail onbruikbaar wordt.

Het is raadzaam om vertrouwd te raken met het gebruik van DNS-verificatietools om wijzigingen te valideren: CMD (dig, nslookup), diagnostische panelen van de provider zelf, of online services voor het controleren van de propagatie- en DNSSEC-status.

Voortplanting van veranderingen en TTL in zones en subzones

Wanneer u een DNS-zone of -subzone bewerkt (bijvoorbeeld door het IP-adres van de webserver te wijzigen of de MX-records aan te passen), worden de wijzigingen onmiddellijk doorgevoerd op de gezaghebbende servers, maar ze worden niet direct wereldwijd weergegeven.

De oorzaak is caching : DNS-resolvers slaan antwoorden op gedurende de tijd die is gespecificeerd door de TTL van het record. Totdat die TTL verloopt, blijven ze de oude versie aanbieden, vandaar het welbekende "DNS-propagatie".

Dit proces kan enkele minuten tot 24-48 uur duren in extreme gevallen, afhankelijk van de geconfigureerde TTL-waarden en hoe elke internetprovider gegevens cachet . Daarom is het bij kritieke wijzigingen raadzaam om de TTL een paar dagen van tevoren tijdelijk te verlagen, te wachten tot de nieuwe TTL-waarden zijn doorgevoerd en vervolgens de grote wijziging door te voeren.

Tijdens de uitrol zien sommige gebruikers mogelijk nog de oude website of e-mail, terwijl anderen al door de nieuwe server worden bediend. U kunt dit proces volgen met online tools die uw logbestanden vanaf meerdere locaties analyseren.

Gebruik van subdomeinen, subzones en redirects

Het aanmaken van subdomeinen is een zeer flexibele manier om je project te organiseren: je kunt bijvoorbeeld blog.mydomain.com, store.mydomain.com, support.mydomain.com hebben en zo diensten, technologieën of zelfs providers van elkaar scheiden.

Voor veel subdomeinen is het voldoende om ze in dezelfde zone als het hoofddomein te beheren en waar nodig A-, AAAA- of CNAME-records toe te voegen. Wanneer een subdomein echter erg complex wordt of wanneer u wilt dat een ander team of een andere provider het beheert, kan het zinvol zijn om het naar een aparte DNS-subzone te delegeren.

Deze delegatie vindt plaats door NS-records aan te maken binnen de hoofdzone die verwijzen naar de naamservers van het subdomein. Vanaf dat moment worden alle query's voor die tak van de naamruimte in de subzone afgehandeld.

Naast subdomeinen is het ook gebruikelijk om HTTP-redirects te gebruiken van het ene domein of subdomein naar het andere. Deze redirects worden gedefinieerd op de webserver of via de redirect-services van de registrar. Dit is geen DNS-record in de traditionele zin (behalve in specifieke gevallen met gespecialiseerde records), maar eerder een HTTP-serverreactie.

Controlepanelen zoals cPanel, Plesk, ISPConfig of de panelen die door de hostingproviders worden aangeboden, bieden meestal grafische wizards om subdomeinen aan te maken, zones te bewerken en redirects te configureren zonder dat het zonebestand direct hoeft te worden aangepast.

Voordelen van DNS-zonering en -subzonering

Het opdelen van een grote naamruimte in meerdere DNS-zones en subzones heeft duidelijke voordelen, vooral naarmate een project of organisatie groeit.

Enerzijds is er sprake van decentralisatie : verschillende eenheden, afdelingen of leveranciers kunnen hun eigen deel van het domein beheren zonder elkaar in de weg te zitten.

Het verbetert ook de prestaties en schaalbaarheid : met kleinere zonebestanden verlopen updates en overdrachten tussen primaire en secundaire servers soepeler, en wordt de belasting verdeeld over meerdere naamservers.

Subzonedelegatie vergemakkelijkt ook de verdeling van verkeer tussen verschillende datacenters of providers, wat helpt bij het balanceren van de belasting, het verbeteren van de latentie en het vergroten van de weerbaarheid tegen uitval bij één enkele provider.

Vanuit organisatorisch oogpunt maakt het gedetailleerd beheer mogelijk : elk team beheert alleen de gegevens die op hen van toepassing zijn, waardoor het risico op fouten in externe domeinen of diensten wordt verkleind.

Stap voor stap (conceptueel) een DNS-subzone delegeren

Het delegeren van een DNS-subzone houdt in dat een grote zone wordt opgedeeld in kleinere zones en dat aan elke zone een andere gezaghebbende server wordt toegewezen , meestal voor specifieke subdomeinen.

Stel, u bent eigenaar van het domein yourdomain.com en u wilt dat een ander team of een andere provider het beheer van it.yourdomain.com overneemt. De eerste stap is het aanmaken van NS-records voor it.yourdomain.com in de hoofdzone, die verwijzen naar de namen van de DNS-servers die deze subzone zullen beheren.

Als die servers zich binnen het domein zelf bevinden (bijvoorbeeld ns1.yourdomain.com), moet u in de hoofdzone ook A- (of AAAA-) records voor die servers toevoegen , zodat ze oplosbaar zijn en de resolvers ze correct kunnen vinden.

Vervolgens wordt op de server die is aangewezen voor de subzone it.yourdomain.com een ​​nieuw zonebestand aangemaakt met een eigen SOA, NS en alle benodigde records (A, MX, TXT, enz.) voor dat subdomein.

Op deze manier worden aanvragen voor www.yourdomain.com nog steeds afgehandeld in de hoofdzone, terwijl aanvragen voor it.yourdomain.com of subdomeinen binnen die tak worden doorgestuurd naar de gedelegeerde subzone , die nu de autoriteit is in dat deel van de boomstructuur.

Wijzigingen, monitoring en veelvoorkomende problemen in DNS-zones

Elke keer dat u een record toevoegt, wijzigt of verwijdert in de DNS-zone of -subzone, voert u een zonewijziging uit . Hoewel dit ogenschijnlijk eenvoudige wijzigingen zijn, kan een foutje ernstige gevolgen hebben voor de beschikbaarheid van de website, e-mail of essentiële services.

Sommige systemen bieden de mogelijkheid om meldingen over zonewijzigingen (ZCN) of vergelijkbare mechanismen te activeren, zodat secundaire servers of externe services weten dat er updates zijn en de nieuwe versie synchroniseren.

Een veelvoorkomend probleem bij de eerste updates zijn vertragingen in de signaaloverdracht als gevolg van lange TTL-waarden. Gebruikers in verschillende delen van de wereld kunnen tegelijkertijd oude en nieuwe versies zien, wat de diagnose bemoeilijkt als niet duidelijk is welk probleem wie treft.

Een andere reeks veelvoorkomende fouten betreft configuratiefouten : verkeerde IP-adressen, onjuiste MX-prioriteiten, slecht opgestelde CNAME's, namen zonder een punt aan het einde waar die er wel zou moeten zijn, dubbele of conflicterende records, enzovoort.

Om risico's te minimaliseren, is het raadzaam een ​​gecontroleerde wijzigingsmethode te gebruiken: documenteer wijzigingen, voer wijzigingen indien mogelijk eerst door in testomgevingen en controleer vervolgens met DNS-diagnostische tools of alles naar behoren werkt.

Verschil tussen DNS-zone, subzone en DNS-server

Het is gemakkelijk om de DNS-zone te verwarren met de DNS-server zelf of met het concept van een domein , maar dit zijn verschillende zaken die mentaal van elkaar gescheiden moeten worden.

Een DNS-zone is het administratieve bereik dat de reikwijdte van de bevoegdheid van een specifiek zonebestand definieert. Het kan een volledig domein en al zijn subdomeinen omvatten, of slechts een gedelegeerd gedeelte, zoals een specifieke subzone.

Een DNS-server is de machine (fysiek of virtueel) of software die deze zonebestanden opslaat en op query's reageert. Meerdere zones en subzones die bij verschillende domeinen horen, kunnen naast elkaar op dezelfde server bestaan.

Een domein is de naam die is geregistreerd in een TLD (topdomein) (mydomain.com, mydomain.es, enz.). Dit domein kan op DNS-niveau worden geïmplementeerd als één zone of als meerdere subzones, afhankelijk van hoe u het beheer en de belasting wilt verdelen.

Het scheiden van zones door middel van subdomeinen is niet verplicht, maar het is een zeer nuttige werkwijze naarmate uw infrastructuur groeit, omdat het zorgt voor betere delegatie, schaalbaarheid en probleemisolatie . De sleutel is altijd om duidelijk te definiëren welk deel van uw naamstructuur administratieve of technische onafhankelijkheid nodig heeft.

Zodra deze concepten begrepen zijn en het duidelijk is wat een zone, een subzone, de rol van zonebestanden en de verschillende soorten records zijn, is het beheren van DNS geen ondoorzichtige materie meer. Met een goede zone- en subzoneplanning, verstandig gebruik van TTL en diagnostische tools is het veel gemakkelijker om domeinen, subdomeinen en services stabiel, efficiënt en veilig te laten functioneren.