Att tänka på när du använder domännamn i en lösning för flera olika domänkontrollanter

I många webbprogram med flera klienter kan ett domännamn användas som ett sätt att identifiera en klientorganisation, för att hjälpa till med routningsbegäranden och för att ge kunderna en varumärkesupplevelse. Två vanliga metoder är att använda underdomäner och anpassade domännamn. På den här sidan ger vi vägledning till tekniska beslutsfattare om de metoder som du kan överväga och deras kompromisser.

Underdomäner

Varje klientorganisation kan få en unik underdomän under ett gemensamt delat domännamn. Låt oss ta ett exempel på en lösning för flera användare som skapats av Contoso. Kunder köper Contosos produkt för att hantera sin fakturagenerering. Alla Contosos klienter kan tilldelas en egen underdomän under contoso.com domännamnet. Om du använder regionala distributioner kan du även tilldela underdomäner under domänerna us.contoso.com och eu.contoso.com . I den här artikeln refererar vi till dessa som stamdomäner. Varje kund får sin egen underdomän under din stamdomän. Tailwind Toys kan till exempel tilldelas tailwind.contoso.com och Adventure Works kan tilldelas adventureworks.contoso.com .

Hantera ditt domännamnsutrymme

När du skapar underdomäner under ditt eget domännamn måste du tänka på att du kan ha flera kunder med liknande namn. Eftersom de delar en enda stamdomän får den första kunden för att få en viss domän sitt önskade namn, och efterföljande kunder måste använda alternativa underdomännamn, eftersom fullständiga domännamn måste vara globalt unika.

DNS med jokertecken

Överväg att använda DNS-poster med jokertecken för att förenkla hanteringen av underdomäner. I stället för att skapa DNS-poster för , och så vidare kan du i stället skapa en jokerpost för och dirigera alla underdomäner till en enda IP-adress (A-post) eller kanoniskt tailwind.contoso.comadventureworks.contoso.com namn *.contoso.com (CNAME-post).

Underdomäner med flerpartsstamsdomäner

Många lösningar för flera användare är utspridda över flera fysiska distributioner. Detta är vanligt när du behöver uppfylla kraven på datahemhemlighet eller när du vill ge bättre prestanda genom att distribuera resurser geografiskt närmare användarna. Även inom en enda region kan du också behöva sprida dina klienter över oberoende distributioner, som en del av din skalningsstrategi. Om du planerar att använda underdomäner för varje klient kan du överväga en underdomänstruktur med flera delar.

Här är ett exempel: Contoso publicerar ett program för flera användare för sina fyra kunder. Adventure Works och Tailwind Traders finns i USA och deras data lagras på en delad amerikansk instans av Contoso-plattformen. Fabrikam och Worldwide Importers finns i Europa och deras data lagras på en europeisk instans.

Om Contoso väljer att använda en enda stamdomän, contoso.com, för alla sina kunder kan detta se ut så här:

DNS-posterna (som krävs för att stödja den här konfigurationen) kan se ut så här:

Varje ny kund som publiceras kräver en ny underdomän och antalet underdomäner växer med varje kund.

Contoso kan också använda distributions- eller regionspecifika stamdomäner, så här:

DNS-posterna för den här distributionen kan se ut så här:

Contoso behöver inte skapa underdomänposter för varje kund. I stället har de en enda DNS-post med jokertecken för varje geografis distribution, och alla nya kunder som läggs till under den här stammen ärver automatiskt CNAME-posten.

Det finns fördelar och nackdelar med varje metod. När du använder en enda stamdomän kräver varje klientorganisation som du registrerar att en ny DNS-post skapas, vilket medför mer driftkostnader. Du har dock större flexibilitet om du behöver flytta klienter mellan distributioner, eftersom du kan ändra CNAME-posten för att dirigera trafiken till en annan distribution. Detta påverkar inte andra klienter. När du använder flera stamdomäner får du lägre hanteringskostnader och du kan återanvända kundnamn över flera regionala stamdomäner, eftersom var och en effektivt representerar sin egen namnrymd.

Egna domännamn

Du kanske vill göra det möjligt för dina kunder att ta med sina egna domännamn. Vissa kunder ser detta som en viktig aspekt av sin varumärkesyttning. Det kan också krävas för att uppfylla kundernas säkerhetskrav, särskilt om de behöver ange sina egna TLS-certifikat. Även om det kan verka trivialt att låta kunderna ta med sina egna domännamn, finns det vissa dolda komplexiteter i den här metoden och det kräver noggranna överväganden.

Namnmatchning

Slutligen måste varje domännamn matchas mot en IP-adress. Som du har sett kan metoden för detta bero på om du distribuerar en enda instans eller flera instanser av din lösning.

Nu ska vi gå tillbaka till vårt exempel. En av Contosos kunder, Fabrikam, har bett att använda som anpassat domännamn för att få åtkomst invoices.fabrikam.com till Contosos tjänst. Eftersom Contoso har flera distributioner av sin plattform bestämmer de sig för att använda underdomäner och CNAME-poster för att uppnå sina routningskrav. Contoso och Fabrikam konfigurerar följande DNS-poster:

Ur ett namnmatchningsperspektiv löser den här postkedjan begäranden för till IP-adressen för invoices.fabrikam.com Contosos europeiska distribution.

Upplösning för värdhuvud

Namnmatchning är bara hälften av problemet. Alla webbkomponenter (i Contosos europeiska distribution) måste vara medvetna om hur begäranden som tas emot med Fabrikams domännamn hanteras Host i begärandehuvudet. Beroende på de specifika webbtekniker som Contoso använder kan detta kräva ytterligare konfiguration för varje klients domännamn, vilket ger extra driftkostnader för registrering av klienter.

Du kan också överväga att skriva om värdhuvuden, så att webbservern ser ett konsekvent huvudvärde oavsett rubriken för den Host inkommande begäran. Till exempel Azure Front Door kan du skriva om huvuden, så att programservern får ett enda huvud oavsett HostHost begäran. Azure Front Door det ursprungliga värdhuvudet i -huvudet så att programmet kan granska det X-Forwarded-Host för att lösa klientorganisationen.

Domänvalidering

Det är viktigt att verifiera ägarskapet för anpassade domäner innan du börjar registrera dem. Annars riskerar du att en kund råkar ut för en oavsiktlig eller skadlig bil av ett domännamn.

Nu ska vi titta på Contosos registreringsprocess för Adventure Works, som har bett att använda invoices.adventureworks.com som sitt anpassade domännamn. Tyvärr gjorde någon ett stavfel när de försökte registrera det anpassade domännamnet, och de missade s. Därför konfigurerade de det som invoices.adventurework.com . Trafiken flödar inte bara som den ska, utan även när ett annat företag som heter Adventure Work försöker lägga till sin anpassade domän på Contosos plattform, får de ett svar om att domännamnet redan används.

När du arbetar med anpassade domäner, särskilt inom en självbetjäning eller automatiserad process, är det vanligt att kräva ett domänverifieringssteg. Detta kan kräva att CNAME-posterna konfigureras innan domänen kan läggas till. Contoso kan också generera en slumpmässig sträng och be Adventure Works att lägga till en DNS TXT-post med strängvärdet. Det skulle förhindra att domännamnet läggs till förrän verifieringen har slutförts.

Dinglande DNS- och underdomän-övertagandeattacker

När du arbetar med anpassade domännamn är du potentiellt sårbar för en attackklass som kallas dinglande DNS eller övertagande av underdomäner. Den här attacken inträffar när kunder avassociera sina anpassade domännamn från din tjänst, men de inte tar bort posten från DNS-servern. Den här DNS-posten pekar sedan på en resurs som inte finns och är sårbar för ett övertagande.

Nu ska vi titta på hur Fabrikams relation med Contoso kan ändras:

1. Fabrikam har valt att inte längre arbeta med Contoso och därför har de avslutat sin affärsrelation.
2. Contoso har avanerat Fabrikam-klientorganisationen och begärde att fabrikam.contoso.com inte längre fungera. Fabrikam har dock glömt att ta bort CNAME-posten för invoices.fabrikam.com .
3. En illvillig aktör skapar ett nytt Contoso-konto och ger det namnet fabrikam .
4. Angriparen publicera det anpassade domännamnet invoices.fabrikam.com till sin nya klientorganisation. Eftersom Contoso utför CNAME-baserad domänvalidering kontrollerar de Fabrikams DNS-server. De ser att DNS-servern returnerar en CNAME-post invoices.fabrikam.com för , som pekar på fabrikam.contoso.com . Contoso anser att den anpassade domänverifieringen lyckas.
5. Om fabrikam-anställda försökte få åtkomst till webbplatsen verkar begäranden fungera. Om angriparen konfigurerar sin Contoso-klientorganisation med Fabrikams varumärke kan anställda luras att komma åt webbplatsen och tillhandahålla känsliga data som angriparen sedan kan komma åt.

En vanlig strategi för att skydda mot dinglande DNS-attacker är att kräva att CNAME-posten tas bort innan domännamnet kan tas bort från klientorganisationens konto. Du kan också överväga att förhindra återanvändning av klient-ID:n, och du kan sedan förstärka din anpassade domänregistreringsprocess genom att använda en slumpmässigt genererad TXT-post (som skiljer sig åt för varje onboarding-försök).

TLS/SSL-certifikat

Transport Layer Security (TLS) är en viktig komponent när du arbetar med moderna program. Det ger förtroende och säkerhet för dina webbprogram. Ägarskap och hantering av TLS-certifikat är något som behöver övervägas noggrant för program med flera olika program.

Vanligtvis ansvarar ägaren av ett domännamn för att utfärda och förnya sina certifikat. Contoso ansvarar till exempel för att utfärda och förnya TLS-certifikat för , samt us.contoso.com ett jokerteckencertifikat för *.contoso.com . På samma sätt skulle Fabrikam vanligtvis ansvara för att hantera alla poster för fabrikam.com domänen, inklusive invoices.fabrikam.com . DNS-posttypen CAA (Certifikatutfärdarens auktorisering) kan användas av en domänägare för att säkerställa att endast vissa myndigheter kan skapa certifikat för sin domän.

Om du planerar att tillåta kunder att ta med sina egna domäner bör du överväga om du planerar att utfärda certifikatet åt kunden eller om kunderna måste ta med sina egna certifikat. Varje alternativ har fördelar och nackdelar. Om du utfärdar ett certifikat för en kund kan du hantera förnyelsen av certifikatet så att kunden inte behöver komma ihåg att hålla det uppdaterat. Men om kunderna har CAA-poster på sina domännamn kan de behöva ge dig behörighet att utfärda certifikat åt dem. Om du förväntar dig att kunder ska utfärda och förse dig med sina egna certifikat ansvarar du för att ta emot och hantera de privata nycklarna på ett säkert sätt och du kan behöva påminna dina kunder om att förnya certifikatet innan det upphör att gälla för att undvika avbrott i tjänsten.

Flera Azure-tjänster stöder automatisk hantering av certifikat för anpassade domäner. Till exempel Azure Front Door och App Service certifikat för anpassade domäner, och de hanterar förnyelseprocessen automatiskt. Detta tar bort arbetet med att hantera certifikat från driftteamet. Du måste dock fortfarande överväga frågan om ägarskap och behörighet, till exempel om CAA-poster är i kraft och konfigurerade på rätt sätt. Du måste också se till att kundernas domäner är konfigurerade för att tillåta de certifikat som hanteras av plattformen.

Nästa steg

Gå tillbaka till översikten över arkitekturöverväganden. Du kan också granska Microsoft Azure Well-Architected Framework.