Domini con carattere jolly in Frontdoor di Azure

Importante

Frontdoor di Azure (versione classica) non supporta la creazione del profilo, il nuovo onboarding del dominio o i certificati gestiti e verrà ritirato il 31 marzo 2027. Per evitare interruzioni del servizio, migrate per Frontdoor di Azure Standard o Premium. Per altre informazioni, vedere ⁠Ritiro di Frontdoor di Azure (versione classica).

I domini wildcard permettono ad Frontdoor di Azure di ricevere traffico per qualsiasi sottodominio di un dominio principale. Un dominio wildcard di esempio è *.contoso.com.

Usando domini con carattere jolly, è possibile semplificare la configurazione del profilo di Frontdoor di Azure. Non è necessario modificare la configurazione per aggiungere o specificare ogni sottodominio separatamente. Ad esempio, è possibile definire il routing per customer1.contoso.com, customer2.contoso.com, e customerN.contoso.com, usando la stessa route e aggiungendo il dominio wildcard *.contoso.com.

I domini wildcard offrono diversi vantaggi, tra cui:

  • Non è necessario eseguire l'onboarding di ogni sottodominio nel profilo di Frontdoor di Azure. Si supponga, ad esempio, di creare nuovi sottodomini ogni cliente e indirizzare tutte le richieste dei clienti a un singolo gruppo di origine. Ogni volta che si aggiunge un nuovo cliente, Frontdoor di Azure riconosce come instradare il traffico al gruppo di origine anche se il sottodominio non è configurato in modo esplicito.
  • Non è necessario generare un nuovo certificato TLS (Transport Layer Security) o gestire impostazioni HTTPS specifiche del sottodominio per associare un certificato per ogni sottodominio.
  • È possibile usare una singola policy del web application firewall (WAF) per tutti i sottodomini.

In genere, i domini con carattere jolly vengono usati per supportare soluzioni SaaS (Software as a Service) e altre applicazioni multi-tenant. Quando si compilano questi tipi di applicazione, è necessario prestare particolare attenzione a come instradare il traffico ai server di origine. Per altre informazioni, vedere Usare Frontdoor di Azure in una soluzione multitenant.

Nota

Quando si usa DNS di Azure per gestire i record DNS del dominio, è necessario configurare i domini con carattere jolly usando l'API di Azure Resource Manager, Bicep, PowerShell e l'interfaccia della riga di comando di Azure. Il supporto per l'aggiunta e la gestione dei domini con carattere jolly di DNS di Azure nel portale di Azure non è disponibile.

Aggiungere un dominio con carattere jolly e un'associazione di un certificato

È possibile aggiungere un dominio con carattere jolly seguendo passaggi simili a quelli per i sottodomini. Per altre informazioni sull'aggiunta di un sottodominio a Frontdoor di Azure, vedere Configurare un dominio personalizzato in Frontdoor di Azure usando il portale di Azure.

Nota

  • Il DNS di Azure supporta i record wildcard.
  • Non è possibile ripulire la cache di Frontdoor di Azure per un dominio con carattere jolly. È necessario specificare un sottodominio quando si elimina la cache.

Per accettare il traffico HTTPS sul dominio wildcard, è necessario abilitare HTTPS sul dominio wildcard. L'associazione del certificato per un dominio con carattere jolly richiede un certificato con carattere jolly. Ovvero, il nome soggetto del certificato deve avere anche il dominio wildcard.

Nota

  • È possibile scegliere di utilizzare lo stesso certificato wildcard da Azure Key Vault o da certificati gestiti da Frontdoor di Azure per i sottodomini.
  • Se desideri aggiungere un sottodominio di un dominio wildcard già convalidato nel profilo Frontdoor di Azure Standard o Premium, la convalida del dominio viene approvata automaticamente. Questo è applicabile a Bring Your Own Certificate. La proprietà del dominio è necessaria per il certificato gestito per i sottodomini.
  • Se un dominio con carattere jolly è convalidato e già aggiunto a un profilo, un sottodominio a livello singolo può comunque essere aggiunto a un altro profilo purché venga convalidato.

Definire un sottodominio in modo esplicito

È possibile aggiungere tutti i sottodomini a livello singolo del carattere jolly desiderati. Ad esempio, per il dominio con carattere jolly *.contoso.com, è anche possibile aggiungere sottodomini al profilo di Frontdoor di Azure per image.contoso.com, cart.contoso.com e così via. La configurazione specificata in modo esplicito per il sottodominio ha la precedenza sulla configurazione del dominio con carattere jolly.

Potrebbe essere necessario aggiungere in modo esplicito sottodomini in queste situazioni:

  • È necessario definire un percorso diverso per un sottodominio rispetto al resto dei domini (dal dominio wildcard). Ad esempio, i clienti potrebbero usare sottodomini come customer1.contoso.com, customer2.contoso.come così via e questi sottodomini devono essere indirizzati ai server applicazioni principali. Tuttavia, potresti anche voler indirizzare images.contoso.com a un contenitore blob di Archiviazione di Azure.
  • È necessario usare un criterio WAF diverso per un sottodominio specifico.

I sottodomini come www.image.contoso.com non sono un sottodominio a livello singolo di *.contoso.com.

Aggiunta di domini con caratteri jolly

È possibile aggiungere un dominio wildcard nella sezione per host o domini del front-end. Analogamente ai sottodomini, Frontdoor di Azure (versione classica) verifica che sia presente il mapping del record CNAME per il dominio con carattere jolly. Questo mapping di Domain Name System (DNS) può essere un mapping del record CNAME diretto, come *.contoso.com mappato a endpoint.azurefd.net. In alternativa, è possibile usare afdverify temporary mapping. Ad esempio, afdverify.contoso.com mappato a afdverify.endpoint.azurefd.net convalida il mapping dei record CNAME per il carattere jolly.

Nota

Il DNS di Azure supporta i record wildcard.

È possibile aggiungere quanti più sottodomini di primo livello del dominio wildcard negli host front-end, fino al raggiungimento del limite degli host front-end. Questa funzionalità potrebbe essere necessaria per:

  • Definire un percorso diverso per un sottodominio rispetto agli altri domini (dal dominio con carattere jolly).

  • Avere un criterio WAF diverso per un sottodominio specifico. Ad esempio, *.contoso.com consente di aggiungere foo.contoso.com senza dover di nuovo dimostrare la proprietà del dominio. Ma non consente foo.bar.contoso.com perché non è un sottodominio a livello singolo di *.contoso.com. Per aggiungere foo.bar.contoso.com senza convalida aggiuntiva della proprietà del dominio, *.bar.contoso.com è necessario aggiungere .

È possibile aggiungere i domini wildcard e i relativi sottodomini con determinate limitazioni.

  • Se un dominio con carattere jolly viene aggiunto a un profilo di Frontdoor di Azure (versione classica):
    • Il dominio con carattere jolly non può essere aggiunto ad altri profili di Frontdoor di Azure (versione classica).
    • I sottodomini di primo livello del dominio wildcard non possono essere aggiunti ad un altro profilo Frontdoor di Azure (versione classica) o ad un profilo Rete di distribuzione dei contenuti di Azure.
  • Se un sottodominio di un dominio con carattere jolly è già stato aggiunto a un profilo di Frontdoor di Azure (versione classica) o a un profilo di Rete di distribuzione dei contenuti di Azure, il dominio con carattere jolly non può essere usato per altri profili di Frontdoor di Azure (versione classica).
  • Se due profili (Frontdoor di Azure o Rete di distribuzione dei contenuti di Azure) hanno vari sottodomini di un dominio radice, i domini wildcard non possono essere aggiunti a nessuno dei profili.

Associazione di certificato

Per accettare il traffico HTTPS sul dominio wildcard, è necessario abilitare HTTPS sul dominio wildcard. L'associazione del certificato per un dominio con carattere jolly richiede un certificato con carattere jolly. Ovvero, il nome soggetto del certificato deve avere anche il dominio wildcard.

Nota

Attualmente, l'unica opzione disponibile per abilitare HTTPS per i domini con carattere jolly è l’uso del proprio certificato SSL. I certificati gestiti di Frontdoor di Azure non possono essere usati per i domini wildcard.

È possibile scegliere di utilizzare lo stesso certificato wildcard da Azure Key Vault o da certificati gestiti da Frontdoor di Azure per i sottodomini.

Se si aggiunge un sottodominio a un dominio wildcard cui è già associato un certificato, non è possibile disabilitare HTTPS per il sottodominio. Il sottodominio usa l'associazione del certificati per il dominio con carattere jolly, a meno che un Key Vault diverso o un certificato gestito di Frontdoor di Azure non ne esegua l'override.

Criteri WAF

I criteri WAF possono essere associati a domini con carattere jolly, analogamente agli altri domini. Una politica WAF diversa può essere applicata a un sottodominio di un dominio wildcard. I sottodomini ereditano automaticamente il criterio WAF dal dominio wildcard se non esiste un criterio WAF esplicito associato al sottodominio. Tuttavia, se il sottodominio viene aggiunto a un profilo diverso dal profilo di dominio wildcard, il sottodominio non può ereditare la policy WAF associata al dominio wildcard.

I criteri WAF possono essere associati a domini con carattere jolly, analogamente agli altri domini. Una politica WAF diversa può essere applicata a un sottodominio di un dominio wildcard. Per i sottodomini, è necessario specificare le policy WAF da usare anche se si tratta della stessa policy del dominio wildcard. I sottodomini non ereditano automaticamente la politica WAF dal dominio wildcard.

Se non si vuole che un criterio WAF venga eseguito per un sottodominio, è possibile creare un criterio WAF vuoto senza set di regole gestiti o personalizzati.

Percorsi

Quando si configura un percorso, è possibile selezionare un wildcard domain come origine. È anche possibile avere un comportamento di route diverso per domini wildcard e sottodomini. Frontdoor di Azure sceglie la corrispondenza più specifica per il dominio tra route diverse. Per altre informazioni, vedere Modalità di corrispondenza delle richieste con una regola di routing.

Importante

È necessario avere schemi di percorso corrispondenti tra le route, altrimenti i client riscontreranno errori.

Si supponga, ad esempio, di avere due regole di routing:

  • Route 1 (*.foo.com/* mappata al gruppo di origine A)
  • Route 2 (bar.foo.com/somePath/* mappata al gruppo di origine B) Se arriva una richiesta per bar.foo.com/anotherPath/*, Frontdoor di Azure seleziona la route 2 in base a una corrispondenza di dominio più specifica, solo per non trovare modelli di percorso corrispondenti tra le route.

Regole di instradamento

Quando si configura una regola di routing, è possibile selezionare un dominio wildcard come host front-end. È anche possibile avere un comportamento di route diverso per domini wildcard e sottodomini. Frontdoor di Azure sceglie la corrispondenza più specifica per il dominio tra route diverse. Per altre informazioni, vedere Modalità di corrispondenza delle richieste con una regola di routing.

Importante

È necessario avere schemi di percorso corrispondenti tra le route, altrimenti i client riscontreranno errori.

Si supponga, ad esempio, di avere due regole di routing:

  • Route 1 (*.foo.com/* mappato al pool back-end A)
  • Route 2 (bar.foo.com/somePath/* mappata al pool back-end B) Se arriva una richiesta per bar.foo.com/anotherPath/*, Frontdoor di Azure seleziona la route 2 in base a una corrispondenza di dominio più specifica, solo per scoprire che non ci sono modelli di percorso corrispondenti tra le route.

Passaggi successivi

  • Last updated on