Betrouwbaarheid in Azure DNS openbare zones

Azure DNS biedt naamomzetting met behulp van Microsoft Azure infrastructuur. Dit artikel richt zich op openbare DNS-zones, die u doorgaans maakt voor domeinen waarvan u eigenaar bent en die u gebruikt voor het publiceren van records voor toepassingen en services die beschikbaar zijn op internet. De hostnamen die u oplost, zijn openbaar toegankelijke DNS-namen en de opgeloste IP-adressen zijn meestal openbare IP-adressen die bereikbaar zijn vanaf internet.

Azure DNS is een niet-regionale service die niet is gebonden aan een specifieke beschikbaarheidszone of Azure 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 Azure DNS openbare zones reageren op tijdelijke fouten, storingen in beschikbaarheidszones, regiobrede storingen, servicestoringen, beveiligingsbedreigingen en onjuiste configuratie, portal- en beheerhulpprogrammastoringen en serviceonderhoud. Ook wordt beschreven hoe u uw zoneconfiguratie beveiligt en herstelt en wordt uitgelegd wat de belangrijkste SLA-vereisten (Service Level Agreement) zijn.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productie-implementaties van Azure DNS openbare zones volgt u deze aanbevelingen om de betrouwbaarheid te verbeteren:

  • Delegeren aan alle naamservers: Azure DNS wijst vier naamservers toe aan elke openbare DNS-zone. Configureer uw domeindelegering om alle vier de naamservers te gebruiken. Deze configuratie biedt foutisolatie en is vereist om in aanmerking te komen voor de AZURE DNS SLA.

  • Configureer de juiste TTL-waarden: Stel TTL-waarden (Time-to-Live) in waarmee het queryvolume wordt afgestemd op hoe snel clients recordwijzigingen ontvangen. Met lagere TTL-waarden kunnen clients sneller wijzigingen ontvangen, maar het queryvolume verhogen. Hogere TTL-waarden verminderen het queryvolume, maar kunnen failover vertragen nadat u een record hebt gewijzigd.

  • Aliasrecords gebruiken voor ondersteunde Azure resources:aliasrecords weerspiegelen automatisch wijzigingen in een onderliggende Azure-resource tijdens DNS-omzetting en voorkomen dat verouderde DNS-records verlopen.

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 de DNS-recordsets voor een domein bevat. Een recordset koppelt een DNS-naam aan een waarde, zoals een IP-adres of eindpunt. De namen die door een openbare DNS-zone worden omgezet, zijn toegankelijk via internet.

Als u Azure DNS gezaghebbend wilt maken voor uw domein, delegeert u het domein aan de naamservers die Azure toewijst wanneer u de zone maakt. Nadat delegering is ingesteld, maakt u recordsets voor de DNS-recordtypen die Azure DNS ondersteunt. U kunt ook aliasrecords maken die verwijzen naar Azure resources, zoals openbare IP-adressen, Traffic Manager-profielen en Azure Front Door eindpunten, zodat de DNS-record gesynchroniseerd blijft met de doelresource.

Tijdens dns-omzetting volgen recursieve DNS-resolvers de DNS-hiërarchie om de Azure DNS gezaghebbende naamservers voor uw zone te bereiken.

Important

Azure DNS lost namen op, maar bewaakt niet de gezondheid van eindpunten en routeert geen toepassingsverkeer. De betrouwbaarheid van uw algehele oplossing is afhankelijk van de configuratie van de resources waarnaar uw DNS-records verwijzen, zoals virtuele machines en load balancers.

In dit artikel worden deze resources niet behandeld, maar de beschikbaarheidsconfiguraties zijn rechtstreeks van invloed op de tolerantie van uw toepassing. Bekijk de betrouwbaarheidshandleidingen voor Azure-services in uw oplossing voor meer informatie over hoe elke service uw betrouwbaarheidsvereisten ondersteunt.

Fysieke architectuur

Azure DNS werkt als een niet-regionale service en 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 BGP routeren binnenkomende DNS-omzettingsaanvragen automatisch naar de dichtstbijzijnde gezonde Azure DNS infrastructuur.

Het Azure DNS servervlak werkt in een actief-actieve configuratie in twee onafhankelijke serverstacks: één die wordt uitgevoerd op Linux en één die wordt uitgevoerd op Windows. Deze stacks delen geen code en geen onderliggende hardware. Omdat ze onafhankelijk zijn, een bug, beveiligingsprobleem of fout die van invloed is op de ene stack, heeft dit geen invloed op de andere. Deze onafhankelijkheid vermindert het risico op een volledige serviceonderbreking als gevolg van één enkel uitvalspunt en helpt beschermen tegen bepaalde categorieën zero-daykwetsbaarheden.

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 tijdens de DNS-naamomzetting een tijdelijke fout optreedt, moet de client of intermediaire resolver opnieuw proberen volgens het geconfigureerde DNS-herhalingsbeleid. Tussen 2 en 5 seconden is meestal een voldoende time-out 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, moeten clients meer aanvragen indienen voor Azure DNS en zijn er meer potentiële mogelijkheden voor tijdelijke fouten. 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 distribueert de infrastructuur over meerdere beschikbaarheidszones in meerdere Azure regio's en repliceert wijzigingen in uw openbare 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

DNS-zones zijn tolerant voor regiostoringen omdat zonegegevens wereldwijd beschikbaar zijn en zijn geïmplementeerd in meerdere Azure regio's. Als een regio een storing heeft, zijn resources die u in die regio hebt geïmplementeerd, zoals virtuele netwerken en VM's, mogelijk niet beschikbaar, maar Azure DNS blijft records in uw zone oplossen.

Als u een oplossing hebt die moet schakelen tussen meerdere regio's, zoals voor herstel na noodgevallen, kunt u overwegen om Azure Traffic Manager of Azure Front Door te gebruiken. Deze services bieden geautomatiseerde failovermogelijkheden, die u kunt gebruiken als een regio niet in orde is.

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 Uw Azure DNS-implementatie beveiligen en DNS-zones en -records beveiligen voor uitgebreide beveiligingsrichtlijnen die specifiek zijn voor openbare 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 netwerkproblemen of problemen met andere infrastructuur kunnen de connectiviteit met de Azure DNS-service verstoren.

De veerkracht van Azure DNS is deels te danken aan de wereldwijd gedistribueerde architectuur van het active-active serving plane.

Meerdere naamservers gebruiken

Azure DNS wijst vier naamservers toe aan elke openbare DNS-zone. Wanneer u uw domein delegeert, configureert u alle vier de naamservers. Als een resolver de ene naamserver niet kan bereiken, kan deze een query uitvoeren op een andere.

Controleren op servicestoringen

Gebruik Azure Service Health om de status van Azure DNS te controleren. Configureer Service Health-waarschuwingen om u op de hoogte te stellen van service-incidenten.

Testen op servicestoringen

Azure Chaos Studio biedt storingen waarmee binnen bepaalde typen testworkloads mislukte DNS-omzetting kan worden gesimuleerd. Deze fouten veroorzaken geen storing in Azure DNS. De Chaos Studio-agent biedt de DNS-fout en AKS Chaos Mesh biedt de DNS Chaos-functionaliteit. Gebruik deze fouten om te testen hoe uw toepassingen en infrastructuur reageren wanneer dns-omzetting mislukt, bijvoorbeeld tijdens een gedeeltelijke netwerkfout.

Tolerantie voor onderbrekingen van portal- en beheerhulpprogramma's

Als u uw openbare DNS-zone in de Azure-portal beheert, bereidt u een alternatief beheerpad voor scenario's voor waarin u geen toegang hebt tot de portal, met name als u de zone mogelijk opnieuw moet configureren tijdens een storing.

Als de Azure-portal niet beschikbaar is, gebruikt u de Azure CLI, Azure PowerShell of infrastructuur als code (IaC), zoals Bicep of Terraform om uw openbare DNS-zone te beheren. 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 openbare DNS-zones.

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

Als extra optie voor herstel op recordniveau exporteert u een zonebestand dat compatibel is met BIND. Het importeren van zonebestanden heeft beperkingen en behoudt niet elke Azure-specifieke resource-instelling, dus gebruik geen geëxporteerd zonebestand als uw enige herstelartefact. Controleer de gedocumenteerde importbeperkingen en controleer de records nadat u een zone hebt hersteld.

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, zolang aan bepaalde voorwaarden wordt voldaan. Deze voorwaarden omvatten het herhaaldelijk opnieuw proberen van mislukte aanvragen gedurende ten minste 60 opeenvolgende seconden en het gebruik van alle naamservers die Azure DNS aan uw zone toewijst. Bekijk het SLA-document voor de gedetailleerde voorwaarden.

Verwante onderwerpen

  • Last updated on