In een recente posthebben we de valkuilen geschetst van een zelfgehost, gezaghebbend Domain Name System (DNS) vanuit het perspectief van een startende of middelgrote onderneming die een doe-het-zelf-systeem in elkaar zet met behulp van BIND DNS of andere open source-tools. Het hoofdidee was dat elk bedrijf op een punt komt waarop het zijn eigen, zelfgehoste, gezaghebbende DNS-systemen ontgroeit. Om welke reden dan ook (of het nu gaat om functionaliteit, kosten, betrouwbaarheid of middelen) kiezen de meeste bedrijven er uiteraard voor behoefte aan een beheerde DNS dienst geleverd door een derde partij.

Niettemin is er een bepaalde klasse van grote ondernemingen waar zelfgehoste, gezaghebbende DNS volgens een ander soort logica opereert. Met een wereldwijde voetafdruk en voldoende schaalgrootte om zelfs complexe technische projecten intern op te lossen, zijn dit soort bedrijven vaak geneigd om goede voornemens te maken in plaats van het product van een ander bedrijf te kopen.

De voordelen van self-hosting voor grote ondernemingen

Er zijn verschillende redenen waarom een ​​grote onderneming zelf een gezaghebbende DNS-service zou willen bouwen en hosten:

Specifieke functionele eisen: Grote ondernemingen willen hun applicaties, diensten en content vaak op maat leveren. Dit kan van alles zijn, van hyperspecifieke routering van DNS-query's tot ondersteuning op systeemniveau voor onderscheidende applicatie-architecturen tot compliance-eisen.

Gebruik maken van bestaande bronnen: Wanneer bedrijven al servers en technische middelen op grote schaal over de hele wereld hebben geïmplementeerd, lijkt het gebruik van die footprint om gezaghebbende DNS te leveren vaak een logische volgende stap.

Controle: Sommige bedrijven willen eenvoudigweg niet afhankelijk zijn van een leverancier, vooral niet voor zoiets bedrijfskritisch als gezaghebbende DNS. Andere bedrijven hebben een ‘build it’-cultuur die waarde hecht aan het ontwikkelen van interne benaderingen die technische vaardigheden bevorderen.

Theorie versus realiteit

Dit zijn allemaal geldige redenen om uw DNS op grote schaal zelf te hosten, althans in theorie. Wat we uit gesprekken met grote ondernemingen in verschillende sectoren hebben ontdekt, is dat de waargenomen voordelen van zelfgehoste, gezaghebbende DNS vaak niet worden gerealiseerd. De logica achter zelfhosting ziet er goed uit op een PowerPoint, maar levert geen werkelijke bedrijfswaarde op.

Hier zijn enkele gebieden waarop de realiteit van zelfgehoste, gezaghebbende DNS niet overeenkomt met de theorie:

Veerkracht: Elk groot bedrijf is waarschijnlijk zo belangrijk dat elke downtime een verwoestende impact op het bedrijfsresultaat zou hebben. Dat is de reden waarom de meeste gezaghebbende DNS-beheerders aandringen op een secundaire of failover-optie voor het geval zich een ramp voordoet. Zelfgehoste, gezaghebbende DNS omvat dit zelden: het kost te veel middelen om een ​​secundair systeem als een vorm van verzekering te bouwen en te onderhouden.

Brosse architecturen: De meeste gezaghebbende DNS-infrastructuren zijn gebouwd op BIND, waarvoor doorgaans een Rube Goldberg-machine met scripts vereist is. Na verloop van tijd kan de complexiteit van deze scripts moeilijk te onderhouden worden als u rekening houdt met nieuwe mogelijkheden en operationele vereisten. Eén verkeerde zet, zoals één enkele codeerfout, kan gemakkelijk uw gehele gezaghebbende DNS-infrastructuur neerhalen en uw klantgerichte sites offline halen. Voor een grote, complexe onderneming kunnen broze BIND-architecturen en -scripts bijzonder gevaarlijk zijn.

technische schuld: Wanneer u uw eigen gezaghebbende DNS gebruikt, kunt u gemakkelijk een aanzienlijke achterstand aan functieverzoeken opbouwen. Dit geldt vooral als je een DevOps-, NetOps- of CloudOps-team hebt dat tegen een deadline werkt. Laten we eerlijk zijn: de meeste van deze DNS-functies zullen binnen een veel langere tijdlijn worden geleverd dan welk applicatieontwikkelingsteam dan ook nodig heeft.

Kosten: Een door zichzelf gehoste grote onderneming heeft misschien de berekeningen gemaakt en geconcludeerd dat het bouwen, implementeren en onderhouden van een gezaghebbend DNS-systeem de investering waard is. De realiteit is echter dat deze beslissingen meestal plaatsvinden zonder een weloverwogen kosten-batenanalyse. Op de lange termijn kosten de uitgaven en de verborgen opportuniteitskosten van zelfgehoste, gezaghebbende DNS wegen doorgaans zwaarder dan de waargenomen financiële voordelen.

Personeelsverloop: DIY-architecturen werken alleen zolang de persoon (of het team) die ze heeft gebouwd bij het bedrijf blijft. Als die persoon het bedrijf om welke reden dan ook verlaat, vertrekt zijn institutionele kennis over hoe doe-het-zelf-architecturen werden gebouwd met hem mee. Sommige bedrijven komen op het punt waarop ze bang zijn om iets te veranderen, omdat dit gemakkelijk kan resulteren in een downtime-incident waarvan het moeilijk is om hiervan te herstellen.

Automatisering: BIND heeft geen Application Programming Interface (API) en is niet gebouwd om enige vorm van automatisering te ondersteunen. DIY-architecturen zijn meestal niet gebouwd om standaard automatiseringsplatforms zoals Ansible of Terraform te ondersteunen. Het is bijna onmogelijk om doe-het-zelf-architecturen te orkestreren met behulp van tools van derden. Als je een doe-het-zelf-gezaghebbende DNS hebt, zit je waarschijnlijk vast aan handmatige wijzigingen die de inspanningen voor het ontwikkelen van applicaties tot een minimum vertragen.

Beheerde DNS is gewoon logisch

Als aanbieder van beheerde DNS-oplossingen, we zijn zeker bevooroordeeld. Vanuit ons perspectief wegen de nadelen van zelfgehoste, gezaghebbende DNS echter duidelijk op tegen de voordelen, zelfs (of vooral) voor grote ondernemingen die doorgaans hun eigen systemen bouwen. Wanneer je de langetermijnkosten van het onderhouden van een gezaghebbend DNS-systeem (zowel de CapEx-hardware als het OpEx-personeel) tegen elkaar afweegt, is een beheerde DNS-oplossing eenvoudigweg economisch zinvol.

Beheerde DNS-oplossingen helpt IT-teams ook meer te doen met minder. Als je kijkt naar de administratieve uren die nodig zijn om een ​​gezaghebbend DNS-netwerk op grote schaal te exploiteren, is het veel waardevoller om die middelen op andere strategische prioriteiten te richten. Omdat we zelf al tien jaar gezaghebbende DNS beheren namens een groot deel van het internet, weten we hoe duur en lastig een taak kan zijn.

Omgaan met DNS-migratierisico's

We begrijpen het. Het is moeilijk om te veranderen. Zelfs als grote ondernemingen klaar zijn om hun zelfgehoste, gezaghebbende DNS-architecturen achter zich te laten, zijn ze vaak bang voor de aanzienlijke risico's die gepaard gaan met de migratie naar een beheerde DNS-service. Wanneer bestaande DNS-tools ingebed raken in het technische DNA van een bedrijf, kan het moeilijk zijn om zelfs maar na te denken over het complexe web van afhankelijkheden dat zou moeten veranderen.

Dit is waar secundaire DNS een reddingslijn biedt. Elke beheerde DNS-service (zoals NS1) kan naast een zelfgehost, gezaghebbend DNS-systeem functioneren, hetzij als onafhankelijk platform, hetzij als failover-optie. Met een secundaire DNS-laag kunnen beheerders in de loop van de tijd applicatieworkloads migreren, de mogelijkheden van het beheerde systeem testen en complexe verbindingen met interne systemen geleidelijk afbouwen.

Het gebruik van een secundaire DNS als testomgeving vergroot ook het vertrouwen in de geavanceerde functies die een beheerde DNS-service biedt, bijvoorbeeld verkeersleiding, APIs, DNS-gegevensanalyse en andere elementen die duidelijke waarde opleveren, maar niet beschikbaar zijn in de meeste zelfgehoste services.

Klaar om over te stappen van zelfgehoste, gezaghebbende DNS?

Krijg DNS die meer doet: IBM NS1 Connect