Betrouwbaarheid in Azure DNS privézones

Azure DNS privézones bieden veilige naamomzetting binnen Azure virtuele netwerken. U kunt privé-DNS-zones instellen op een of meer virtuele netwerken en organisaties gebruiken deze doorgaans voor interne toepassingen. De hostnamen die u oplost, zijn lokale DNS-namen die niet openbaar toegankelijk zijn via internet. De opgeloste IP-adressen zijn vaak privé-IP-adressen die niet toegankelijk zijn vanaf internet. Azure DNS is een globale service die niet is gebonden aan een specifieke beschikbaarheidszone of één regio.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure DNS privézones tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten en regiobrede fouten. Het biedt ook belangrijke informatie over de Azure DNS service level agreement (SLA) voor privézones.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productieworkloads raden we u aan deze aanbevelingen te volgen:

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

De primaire resource die u implementeert, is een zone die een set DNS-records vertegenwoordigt die hostnamen (domeinnamen) toewijzen aan IP-adressen. De hostnamen die door de zone worden omgezet, zijn meestal lokale DNS-namen die niet openbaar toegankelijk zijn via internet.

U maakt privé-DNS-zones als zelfstandige resources en koppelt deze aan specifieke virtuele netwerken door virtuele netwerkkoppelingen te maken. Wanneer DNS-aanvragen afkomstig zijn van clients binnen die virtuele netwerken, nemen de privé-DNS-zones deel aan het omzettingsproces. U kunt handmatig vermeldingen maken in een DNS-zone of automatische registratie van VM's configureren op virtuele netwerkkoppelingen. Azure DNS privézones ondersteunen DNS-omzetting tussen virtuele netwerken in Azure regio's, zelfs zonder expliciet peering van de virtuele netwerken. Alle virtuele netwerken moeten echter worden gekoppeld aan de privé-DNS-zone.

Het PROCES voor DNS-naamomzetting omvat meerdere onderdelen, waaronder DNS-resolvers en tussenliggende lagen die aanvragen verwerken voordat de gezaghebbende DNS-servers worden bereikt. Privézones maken gebruik van dezelfde DNS-protocollen en hetzelfde gedrag als openbare zones, waaronder TTL-waarden en cachemechanismen.

Fysieke architectuur

Azure DNS is een niet-regionale dienst. Microsoft implementeert de infrastructuur in meerdere beschikbaarheidszones in meerdere Azure regio's wereldwijd. Met dit ontwerp kan Azure DNS tolerant blijven tijdens een storing in een beschikbaarheidszone of regio, omdat de infrastructuur in een andere zone of regio blijft reageren op oplossingsaanvragen.

Wereldwijde internetprotocollen zoals Anycast, DNS en Border Gateway Protocol (BGP) routeren automatisch binnenkomende DNS-omzettingsaanvragen naar de dichtstbijzijnde goede Azure DNS-infrastructuur.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke fouten voor meer informatie.

Azure DNS tijdelijke fouten verwerkt via de globale DNS-infrastructuur.

Als er een tijdelijke fout optreedt tijdens dns-omzetting, moet de client of tussenliggende resolver de aanvraag opnieuw proberen. Configureer time-outwaarden op de juiste manier. Een time-out van 2 tot 5 seconden is meestal voldoende voor een DNS-client.

De time-to-live (TTL) van elke DNS-record is ook van invloed op de manier waarop uw oplossing fouten verwerkt. Als de TTL zeer laag is, maken clients meer aanvragen voor Azure DNS, waardoor er meer mogelijkheden voor tijdelijke fouten ontstaan. Als de TTL erg hoog is, kunnen clients in het geval van een echte fout in een back-endserver waarvoor u moet worden omgeleid naar een ander IP-adres, vertraging in de failover ondervinden totdat de TTL verloopt. Configureer TTLs zorgvuldig om de beschikbaarheid, latentie en reactiesnelheid te verdelen.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure DNS werkt als een niet-regionale dienst. Microsoft verdeelt de infrastructuur over meerdere beschikbaarheidszones in meerdere Azure regio's en repliceert wijzigingen in uw privé-DNS-zones in die infrastructuur. U selecteert geen beschikbaarheidszones of configureert zoneredundantie. Tijdens een storing in de beschikbaarheidszone blijft de infrastructuur in een andere zone of regio reageren op oplossingsaanvragen.

Als een resource die u implementeert in één beschikbaarheidszone, zoals een virtuele machine (VM), niet meer beschikbaar is tijdens een zonefout, blijft Azure DNS het geconfigureerde IP-adres van de resource retourneren omdat de eindpuntstatus niet wordt bewaakt. Als u overschakelt naar een resource in een gezonde zone, bent u verantwoordelijk voor het bijwerken van het DNS-record, zodat clients de gezonde resource gebruiken. U kunt de resources ook achter een zone-redundante load balancer plaatsen die verkeer naar VM's in gezonde zones stuurt.

Tolerantie voor storingen in de hele regio

Azure DNS privézones bestand zijn tegen storingen in regio's, omdat zonegegevens wereldwijd beschikbaar zijn. Als er een storing is in een regio, zijn de virtuele netwerken en resources zoals VM's mogelijk niet beschikbaar, maar blijft naamresolutie werken.

In het volgende voorbeeld ziet u hoe gegevens in de privézone beschikbaar blijven in meerdere regio's. De privézone azure.contoso.com is gekoppeld aan virtuele netwerken in drie regio's: regio A, regio B en regio C. Automatische registratie is ingeschakeld in regio A en B. In het diagram ziet u regio A met een storing:

Stel dat er een tijdelijke storing optreedt in regio A. VM's in regio B en C kunnen nog steeds query's uitvoeren op DNS-namen in de privézone, inclusief namen die automatisch zijn geregistreerd vanuit regio A. Ze kunnen het IP-adres van VM1 in regio A blijven oplossen, ook al is VM1 niet beschikbaar. Serviceonderbreking in regio A heeft geen invloed op naamresolutie in de andere regio's.

In het voorgaande voorbeeld wordt geen scenario voor herstel na noodgevallen weergegeven waarin uw oplossing een failover uitvoert naar een vervanging voor VM1 in een andere regio. Omdat privézones echter globaal zijn, kunt u VM1 opnieuw maken in het virtuele netwerk van een andere regio om de workload over te nemen.

Als u virtuele netwerken en netwerkresources in meerdere regio's maakt, moet u uw strategie voor meerdere regio's plannen en implementeren voor toepassingen waarvoor failover tussen regio's is vereist.

Tolerantie voor beveiligingsrisico's en onjuiste configuratie

Beveiligingsaanvallen en configuratiefouten zijn twee van de belangrijkste betrouwbaarheidsrisico's voor DNS-zones. Verschillende soorten aanvallen richten zich specifiek op DNS-resolutie, en een onbedoelde misconfiguratie kan uw workloads net zo ernstig verstoren.

Zie Privé-DNS-zones en -records beveiligen voor uitgebreide beveiligingsrichtlijnen die specifiek zijn voor privé-DNS-zones.

Tolerantie voor servicestoringen

Azure DNS is een zeer flexibele service, met een SLA van 100% beschikbaarheid wanneer uw toepassing aan bepaalde voorwaarden voldoet. Servicestoringen zijn zeer ongebruikelijk, maar netwerk- of andere infrastructuurproblemen kunnen de connectiviteit met de Azure DNS-service verstoren.

Controleren op servicestoringen

Microsoft informeert u niet automatisch wanneer een regio niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

Testen op servicestoringen

Azure Chaos Studio biedt een set fouten om problemen met DNS-omzetting te simuleren. De Chaos Studio-agent biedt bijvoorbeeld het fouttype DNS-fout en Azure Kubernetes Service (AKS) Chaos Mesh biedt de DNS Chaos-functionaliteit. U kunt deze fouttypen gebruiken om te testen hoe uw toepassingen en infrastructuur reageren wanneer DNS-omzettingsaanvragen mislukken, wat kan optreden tijdens een gedeeltelijke netwerkfout.

Tolerantie voor onderbrekingen van portal- en beheerhulpprogramma's

Als u uw DNS-zone beheert in de Azure-portal, moet u zich voorbereiden op scenario's waarin u deze niet kunt openen, met name als u uw DNS-zone opnieuw moet configureren tijdens een platformstoring.

U kunt verschillende hulpprogramma's gebruiken om Azure DNS privézones te implementeren en te beheren. Meer informatie over het gebruik van Azure CLI of Azure PowerShell voor het beheren van uw privézone. U kunt ook infrastructuur als code (IaC), zoals Bicep of Terraform, gebruiken om uw privézone te implementeren en te configureren. Deze hulpprogramma's blijven operationeel, zelfs als de Azure-portal wordt gedegradeerd.

Back-up maken en terugzetten

Azure DNS is een staatloze service. Het biedt geen beheerde back-ups of herstel naar een bepaald tijdstip voor privé-DNS-zones.

Als u de volledige Azure resourceconfiguratie wilt behouden, definieert u uw privé-DNS-zones met behulp van IaC, zoals Bicep of Terraform, en slaat u de definities op in broncodebeheer. Test regelmatig de definities zodat u deze kunt gebruiken om uw configuratie opnieuw te implementeren.

Tolerantie voor serviceonderhoud

Microsoft past regelmatig service-updates toe en voert ander onderhoud uit. Het Azure platform verwerkt deze activiteiten automatisch en zorgt ervoor dat onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsgebeurtenissen, tenzij u op de hoogte bent gesteld via Azure Service Health gepland onderhoud.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Azure DNS biedt een SLA voor 100% beschikbaarheid voor geldige DNS-queryreacties wanneer u aan bepaalde voorwaarden voldoet. Deze voorwaarden omvatten het opnieuw proberen van mislukte aanvragen gedurende ten minste 60 opeenvolgende seconden. Bekijk het SLA-document voor de gedetailleerde voorwaarden.

Verwante onderwerpen

• Documentatie voor Azure DNS Private Zones
• Veelgestelde vragen over Azure DNS
• Privé-DNS-zones en -records beveiligen - Azure DNS
• Betrouwbaarheid van openbare Azure DNS-zones