Tillförlitlighet i Azure DNS offentliga zoner

Azure DNS ger namnmatchning med hjälp av Microsoft Azure infrastruktur. Den här artikeln fokuserar på offentliga DNS-zoner som du vanligtvis skapar för domäner som du äger och använder för att publicera poster för program och tjänster som är tillgängliga på Internet. De värdnamn som du löser är offentligt tillgängliga DNS-namn, och de lösta IP-adresserna är vanligtvis offentliga IP-adresser som kan nås från Internet.

Azure DNS är en icke-regional tjänst som inte är bunden till en specifik tillgänglighetszon eller Azure region.

När du använder Azure är tillförlitlighet ett delat ansvar. Microsoft tillhandahåller en rad funktioner för att stödja återhämtning och återställning. Du ansvarar för att förstå hur dessa funktioner fungerar inom alla tjänster som du använder och välja de funktioner du behöver för att uppfylla dina affärsmål och drifttidsmål.

Den här artikeln beskriver hur Azure DNS offentliga zoner svarar på tillfälliga fel, fel i tillgänglighetszonen, regionomfattande fel, tjänstfel, säkerhetshot och felkonfiguration, avbrott i portal- och hanteringsverktyget och serviceunderhåll. Den beskriver också hur du skyddar och återställer din zonkonfiguration och förklarar viktiga serviceavtalskrav (SLA).

Rekommendationer för produktionsdistribution för tillförlitlighet

För produktionsdistributioner av Azure DNS offentliga zoner följer du dessa rekommendationer för att förbättra tillförlitligheten:

Översikt över tillförlitlighetsarkitektur

I det här avsnittet beskrivs några av de viktiga aspekterna av hur tjänsten fungerar som är mest relevant ur ett tillförlitlighetsperspektiv. I avsnittet beskrivs den logiska arkitekturen, som innehåller några av de resurser och funktioner som du distribuerar och använder. Den diskuterar också den fysiska arkitekturen, som innehåller information om hur tjänsten fungerar under täcket.

Logisk arkitektur

Den primära resursen som du distribuerar är en zon som innehåller DNS-postuppsättningarna för en domän. En postuppsättning associerar ett DNS-namn med ett värde, till exempel en IP-adress eller slutpunkt. Namnen som en offentlig DNS-zon matchar är tillgängliga via Internet.

Om du vill göra Azure DNS auktoritativ för din domän delegerar du domänen till de namnservrar som Azure tilldelar när du skapar zonen. När delegeringen är på plats skapar du postuppsättningar för de DNS-posttyper som stöds av Azure DNS. Du kan också skapa aliasposter som refererar till Azure resurser som offentliga IP-adresser, Traffic Manager-profiler och Azure Front Door slutpunkter, så att DNS-posten förblir synkroniserad med målresursen.

Under DNS-namnmatchning följer rekursiva DNS-resolver DNS-hierarkin för att nå Azure DNS:s auktoritativa namnservrar för din zon.

Fysisk arkitektur

Azure DNS fungerar som en icke-regional tjänst och distribuerar sin infrastruktur över flera tillgänglighetszoner i flera Azure regioner över hela världen. Den här designen gör det möjligt för Azure DNS att förbli motståndskraftiga under ett avbrott i tillgänglighetszonen eller regionen eftersom infrastrukturen i en annan zon eller region fortsätter att svara på resolutionsförfrågningar.

Globala Internetprotokoll som Anycast, DNS och BGP dirigerar automatiskt inkommande DNS-matchningsbegäranden till närmaste felfria Azure DNS infrastruktur.

Azure DNS-tjänstlagret körs i en aktiv-aktiv-konfiguration i två oberoende tjänststackar: den ena körs på Linux och den andra på Windows. Dessa staplar delar ingen kod och ingen underliggande maskinvara. Eftersom de är oberoende påverkar inte en bugg, sårbarhet eller ett fel som påverkar den ena stacken den andra. Detta oberoende minskar risken för ett fullständigt tjänstavbrott som orsakas av en enskild felpunkt och skyddar mot vissa klasser av nolldagars säkerhetsrisker.

Motståndskraft mot tillfälliga fel

Tillfälliga fel är kortvariga, intermittenta fel i komponenter. De förekommer ofta i en distribuerad miljö som molnet, och de är en normal del av åtgärderna. Tillfälliga fel korrigerar sig själva efter en kort tidsperiod. Det är viktigt att dina program kan hantera tillfälliga fel, vanligtvis genom att försöka igen.

Alla molnbaserade program bör följa vägledningen för tillfälliga felhantering i Azure när de kommunicerar med molnbaserade API:er, databaser och andra komponenter. Mer information finns i Rekommendationer för hantering av övergående fel.

Azure DNS hanterar tillfälliga fel via sin globala DNS-infrastruktur.

Om ett tillfälligt fel inträffar under DNS-matchningen bör klienten eller den mellanliggande matcharen försöka igen enligt dess konfigurerade DNS-återförsöksbeteende. Mellan 2 och 5 sekunder är vanligtvis en tillräcklig tidsgräns för en DNS-klient.

TTL-värdet för varje DNS-post påverkar också hur din lösning hanterar fel. Om TTL är mycket låg måste klienter göra fler förfrågningar till Azure DNS och det finns fler potentiella möjligheter för tillfälliga fel att uppstå. Om TTL-värdet är mycket högt kan klienter, vid ett verkligt fel i en backendserver som kräver att du omdirigerar till en annan IP-adress, uppleva fördröjningar i redundansväxlingen tills TTL-värdet löper ut. Konfigurera TTL:er omsorgsfullt för att balansera tillgänglighet, latens och svarstid.

Motståndskraft mot fel i tillgänglighetszonen

Tillgänglighetszoner är fysiskt separata grupper av datacenter i en Azure-region. När en zon misslyckas kan tjänsterna redundansväxla till en av de återstående zonerna.

Azure DNS fungerar som en icke-regional tjänst. Microsoft distribuerar sin infrastruktur över flera tillgänglighetszoner i flera Azure regioner och replikerar ändringar till dina offentliga DNS-zoner i infrastrukturen. Du väljer inte tillgänglighetszoner eller konfigurerar zonredundans. Under ett avbrott i tillgänglighetszonen fortsätter infrastrukturen i en annan zon eller region att svara på lösningsbegäranden.

Om en resurs som du distribuerar till en enda tillgänglighetszon, till exempel en virtuell dator (VM), blir otillgänglig under ett zonfel, fortsätter Azure DNS att returnera resursens konfigurerade IP-adress eftersom den inte övervakar slutpunktshälsan. Om du växlar över till en resurs i en fungerande zon ansvarar du för att uppdatera DNS-posten så att klienterna använder den fungerande resursen. Du kan också placera resurserna bakom en zonredundant lastbalanserare som dirigerar trafik till virtuella datorer i felfria zoner.

Motståndskraft mot regionomfattande fel

DNS-zoner är motståndskraftiga mot regionfel eftersom zondata är globalt tillgängliga och distribuerade till flera Azure regioner. Om en region har ett avbrott kan resurser som du har distribuerat i den regionen, till exempel virtuella nätverk och virtuella datorer, vara otillgängliga, men Azure DNS fortsätter att matcha poster i din zon.

Om du har en lösning som behöver växla mellan flera regioner, till exempel i haveriberedskapssyfte, bör du överväga att använda Azure Traffic Manager eller Azure Front Door. De här tjänsterna tillhandahåller automatiserade redundansfunktioner som du kan använda om en region inte är felfri.

Motståndskraft mot säkerhetshot och felkonfiguration

Säkerhetsattacker och konfigurationsfel är två av de mest betydande tillförlitlighetsriskerna för DNS-zoner. Flera klasser av attacker riktar sig specifikt mot DNS-matchning, och oavsiktlig felkonfiguration kan störa dina arbetsbelastningar lika allvarligt.

Omfattande säkerhetsvägledning som är specifik för offentliga DNS-zoner finns i Skydda din Azure DNS distribution och Skydda DNS-zoner och -poster.

Motståndskraft mot avbrott i tjänsten

Azure DNS är en mycket elastisk tjänst med ett serviceavtal med 100% tillgänglighet när ditt program uppfyller vissa villkor. Tjänstavbrott är mycket ovanliga, men nätverksproblem eller problem med annan infrastruktur kan störa anslutningen till Azure DNS-tjänsten.

Azure DNS motståndskraft beror delvis på dess globalt distribuerade, aktiva serveringsplanarkitektur.

Använda flera namnservrar

Azure DNS tilldelar fyra namnservrar till varje offentlig DNS-zon. När du delegerar domänen konfigurerar du alla fyra namnservrarna. Om en resolver inte kan nå en namnserver kan den fråga en annan namnserver.

Övervaka avbrott i tjänsten

Använd Azure Service Health för att övervaka hälsotillståndet för Azure DNS. Konfigurera Service Health-aviseringar för att meddela dig om tjänstincidenter.

Test för avbrott i tjänsten

Azure Chaos Studio innehåller fel som simulerar DNS-matchningsfel från vissa typer av testarbetsbelastningar. Dessa fel utlöser inte ett avbrott i Azure DNS. Chaos Studio-agenten tillhandahåller DNS-felfelet och AKS Chaos Mesh tillhandahåller dns-kaosfunktionen. Använd dessa fel för att testa hur dina program och infrastruktur svarar när DNS-matchningen misslyckas, till exempel under ett partiellt nätverksfel.

Motståndskraft mot avbrott i portalen och hanteringsverktyget

Om du hanterar din offentliga DNS-zon i Azure-portalen förbereder du en alternativ hanteringssökväg för scenarier där du inte kan komma åt portalen, särskilt om du kan behöva konfigurera om zonen under ett avbrott.

Om Azure portalen inte är tillgänglig använder du Azure CLI, Azure PowerShell eller infrastruktur som kod (IaC) som Bicep eller Terraform för att hantera din offentliga DNS-zon. Dessa verktyg fortsätter att fungera även om Azure portalen är degraderad.

Säkerhetskopiering och återställning

Azure DNS är en tillståndslös tjänst. Den tillhandahåller inte hanterade säkerhetskopior eller återställning till en viss tidpunkt för offentliga DNS-zoner.

För att bevara den fullständiga Azure resurskonfigurationen definierar du dina offentliga DNS-zoner med hjälp av IaC, till exempel Bicep eller Terraform, och lagrar definitionerna i källkontrollen. Testa definitionerna med jämna mellanrum så att du kan använda dem för att distribuera om konfigurationen.

Som ett ytterligare alternativ för återställning på postnivå kan du exportera en BIND-kompatibel zonfil. Zonfilimport har begränsningar och bevarar inte alla Azure specifika resursinställningar, så använd inte en exporterad zonfil som din enda återställningsartefakt. Granska de dokumenterade importbegränsningarna och kontrollera posterna efter att du har återställt en zon.

Motståndskraft mot serviceunderhåll

Microsoft tillämpar regelbundet tjänstuppdateringar och utför annat underhåll. Den Azure plattformen hanterar dessa aktiviteter automatiskt, vilket säkerställer att underhållet är sömlöst och transparent för dig. Ingen driftstopp förväntas under underhållshändelser om du inte har blivit informerad via Azure Service Health planerat underhåll.

Serviceavtal

Serviceavtal (SLA) för Azure-tjänster beskriver den förväntade tillgängligheten för varje tjänst och de villkor som din lösning måste uppfylla för att uppnå den tillgänglighetsförväntningen. Mer information finns i Serviceavtal för onlinetjänster.

Azure DNS tillhandahåller ett serviceavtal för 100% tillgänglighet för giltiga DNS-frågesvar, så länge vissa villkor uppfylls. Dessa villkor omfattar återförsök av misslyckade begäranden flera gånger i minst 60 sekunder i följd och användning av alla namnservrar som Azure DNS tilldelar till din zon. Granska SLA-dokumentet för detaljerade villkor.

Relaterat innehåll

• översikt över Azure DNS offentliga zoner
• Vanliga frågor och svar om Azure DNS
• Importera och exportera en Azure DNS zonfil
• Skydda din Azure DNS-implementering
• Skydda Azure DNS-zoner och -poster
• Azure Private DNS översikt