Mettre le site sur domain.com ou www.domain.com ?

C’est une question qu’on peut légitimement se poser lorsqu’on crée ou déploie un site.

Historiquement

D’après l’article de Wikipedia sur www (en), www est apparu très tôt dans l’histoire du World Wide Web

The use of www is not required by any technical or policy standard and many web sites do not use it; indeed, the first ever web server was called nxoc01.cern.ch.[34] According to Paolo Palazzi,[35] who worked at CERN along with Tim Berners-Lee, the popular use of www as subdomain was accidental; the World Wide Web project page was intended to be published at www.cern.ch while info.cern.ch was intended to be the CERN home page, however the DNS records were never switched, and the practice of prepending www to an institution’s website domain name was subsequently copied.

Il semblerait que, par la suite, l’usage fut que le sous-domaine corresponde au service afin de pouvoir les répartir sur plusieurs serveurs.

  • www.domain.com -> pour le web
  • ftp.domain.com -> pour le ftp
  • pop.domain.com -> pour la récupération des mails etc …

On a ensuite inventé les enregistrement SRV pour ça, mais bon hormis pour SIP et XMPP ce n’est guerre usité.

Le www fût également, pour le grand public le signe d’une _adresse internet. Beaucoup plus mémorable que le préfixe du protocole http:// (pénible et complexe sur certain claviers).

On l’a donc vu fleurir sur les différents supports de communications (notamment papier).

Aujourd’hui

Depuis, le web est devenu un objet du quotidien et les domaines de premier niveau - TLD sont compris par la plus part des gens comme marqueur d’une adresse web.

Et technologiquement, du côté serveur, sur la grande majorité des sites avec ou sans www on arrive au contenu (moyennant parfois une redirection transparente pour l’utilisateur).

Et de l’autre, côté client, les navigateurs rajoutent tout seuls le www si besoin.

Et puis, c’est bien connu, nos chers internautes n’utilisent plus la barre d’adresse et passent par le moteur de recherche par défaut de leur navigateur pour trouver les sites (quitte à chercher “domain.com” sur google !).

Ne pas mettre de www.

Il n’y a pas si longtemps, j’aurai eu tendance à dire qu’on devait tout mettre sur le naked domain (comme le disent les américains ); donc supprimer les préfixes www., ftp., etc. :-)

Car cette redondance non standardisée est inutile.

Mettre les wwww.

Mais, j’ai quelques arguments en faveur du préfixe www.

Enfin surtout 1 et il est de taille.

Si on héberge notre site chez un fournisseur de nuage (comme ce blog !), ce dernier ne nous offre pas d’adresse ip à mettre dans nos enregistrements A ou AAAA.

La technique suggérée, par exemple chez Google App Engine, est de créer un enregistrement CNAME en direction du point d’entrée du nuage.

Pas de problème, me diriez-vous, je peut faire un CNAME de mon nom de domaine et j’enlève les enregistrements (non obligatoires) A et AAAA pour éviter toute confusion.

Oui mais non ! Les CNAME ont le gros inconvénient de rendre caduque les enregistrements MX

An alias defined in a CNAME record must have no other resource records of other types (MX, A, etc.). (RFC 1034 section 3.6.2, RFC 1912 section 2.4)
(http://en.wikipedia.org/wiki/CNAME#Restrictions)

Donc si je veux quand même bénéficier d’une adresse e-mail en @domain.com, je ne peux pas mettre de CNAME sur domain.com.

Alternative 1

  • CNAME sur www.domain.com vers domain.cloud-provider.com
  • A (et AAAA) sur un serveur http qui renvoi 301 Moved Permanently vers www.domain.com
  • MX normal (domain.com)

Inconvénient : il faut avoir un serveur avec une ip.

Alternative 2

  • CNAME sur domain.com vers domain.cloud-provider.com
  • MX sur domain.net

Inconvénient : l’adresse email utilise un autre nom de domaine; c’est dommage.

Alternative 3 - idéal

Le fournisseur de nuage nous offre une IP (6 ou 4)

  • A (et AAAA) vers l’ip du fournisseur de nuage
  • MX normal (domain.com)

Pour ce blog, j’ai implémenté la technique N°1, j’ai donc un serveur nginx (à maintenir) avec la conf minimaliste suivante :

server {
  server_name hpar.fr;
  return 301 $scheme://blog.hpar.fr$request_uri;
}

EDIT

Quelques pointeurs :