Loading

Configuration de domaines racine avec un eCDN

Date de publication: May 5, 2026
Description
Configuration/limitation de domaines racine B2C Commerce et Apex.
Résolution

Objectif : fournir des solutions alternatives quant à la manière de gérer le domaine racine/Apex du client avec un eCDN

Environnement : production et développement

REMARQUE :
  •         La mise en place d’alias racine/Apex n’est pas prise en charge sur les eCDN. Il se peut que la vérification TXT ne puisse pas être réalisée via les eCDN.
  •         Le client doit mettre en place cette configuration en externe auprès de son fournisseur DNS ou service de redirection, et transmettre le trafic HTTP et HTTPS à son nom d’hôte personnalisé. 
  •        Conformément aux meilleures pratiques, il convient d’éviter de faire pointer un domaine Apex/racine vers une adresse IP de nœud eCDN, car cela risque de générer des résultats inattendus.

TOUS les réseaux de diffusion de contenu fournissent des enregistrements CNAME dans le cadre du processus de configuration des DNS. Les CDN ne peuvent pas avoir d’adresses IP statiques pointant vers plusieurs nœuds d’un réseau distribué. 

Par exemple, l’utilisation de la configuration suivante n’est PAS recommandée :
mysite.com      A      104.28.26.118   
où 104.28.26.118 est une adresse IP de nœud CloudFlare, ou votre adresse IP Salesforce Commerce Cloud d’origine. 

Comment vais-je dorénavant gérer mes domaines Apex/racine ?

Problème : 
En raison d’une limitation de la spécification DNS, les domaines Apex/racine (exemple.com) ne peuvent pas transférer un enregistrement CNAME vers un nom d’hôte alias. Pour plus d’informations, consultez la ressource suivante :

        https://www.ietf.org/rfc/rfc1912.txt
2.4 Enregistrements CNAME

   Un enregistrement CNAME ne peut pas coexister avec d’autres données.  En
   d’autres termes, si suzy.podunk.xx est un alias pour sue.podunk.xx, vous
   ne pouvez pas avoir pour suzy.podunk.edu un enregistrement MX, ni un enregistrement A, ni
   même un enregistrement TXT.

Solution :
Le client doit utiliser un service externe pour mettre en place une redirection du domaine racine/Apex vers le sous-domaine. En outre, cette redirection doit être configurée à la fois pour HTTP et HTTPS.
Par exemple :
http://exemple.com redirige vers http://www.exemple.com
https://exemple.com redirige vers https://www.exemple.com
Selon vos besoins, vous pouvez également mettre en place la configuration suivante :
http://exemple.com redirige vers https://www.exemple.com

www.exemple.com restera associé au CNAME pointant vers CloudFlare.

La redirection externe peut être mise en œuvre de différentes manières :
a. En étant traitée par le fournisseur DNS.
b. Via .htaccess en employant Apache en tant que serveur Web.
c. En utilisant IIS sur un serveur Microsoft Windows.
d. Si vous utilisez NGINX, en réécrivant des règles par le biais ce canal.

-----------------------------

Que puis-je faire si je ne souhaite pas rediriger mon domaine Apex/racine vers un sous-domaine ?

Problème : 
Des clients ont l’intention de distribuer en permanence le trafic à partir du domaine Apex (exemple.com) au lieu de procéder à une redirection vers un sous-domaine (c’est-à-dire www.exemple.com).

Solution :
Les clients doivent utiliser une solution au niveau des DNS pour diriger les domaines Apex/racine vers un alias CNAME eCDN.
 
  • Fournisseurs connus prenant cette configuration en charge : (UltraDNS, DynDNS, DNSMadeEasy, DNSimple, CSC Advanced DNS, NS1).

Exemples :
Enregistrement ALIAS DynDNS 
Enregistrement ANAME DNS Made Easy
UltraDNS 
NSONE.NET

Informations supplémentaires :
  • Si vous souhaitez connaître la différence entre un CNAME, un ALIAS et une URL, veuillez consulter le site ci-dessous :
(https://support.dnsimple.com/articles/differences-between-a-cname-alias-url/)
Numéro d’article de la base de connaissances

000391603

 
Chargement
Salesforce Help | Article