Table des matières
C'est bien beau d'avoir des services sur son serveur, mais il vient un moment où l'on veut les exposer avec un nom de domaine parlant, comme https://wiki.tecrd.com ou https://demo.tecrd.com
Nb: https://domainr.com est l'un des outils les plus efficace pour trouver un nom de domaine rapidement, et qui soit disponible.
Une fois celui ci-disponible et enregistré, il faudra l'insérer dans son DNS (Domain Name Server), ou recourir à une configuration dynamique du DNS si votre serveur n'a pas d'adresse IP fixe. Et jongler un peu plus encore si votre serveur se trouve dans un réseau local (LAN), fondamentalement invisible à l'internet public.
Registrar
Il faut distinguer:
- le registrar, qui gère vos noms de domaine
- l'hébergeur, qui gère les serveurs (physiques ou virtuels), c'est-à-dire les contenus et services
- et éventuellement des services de stockage "cloud" tiers, comme Amazon S3
Techniquement, c'est le registrar qui gère les noms de domaines, et surtout les associations et redirection entre noms de domaines et adresses IP des serveurs.
Par exemple, Scaleway ne fait qu'hébergeur. Certes, vous aurez une adresse IP publique pour accéder à votre serveur, mais vous voudrez généralement l'associer à un nom de domaine. Pour ce faire vous devez donc avoir un "registrar" !
OVH ou Gandi, de leur côté, font à la fois hébergeur et registrar (éventuellement sous-traitée. L'hébergeur Online utilisait de façon semi-transparente le registrar BookMyName.
Le registrar est indépendant de l'hébergeur
On peut très bien avoir déposé son nom de domaine chez OVH, mais avoir son serveur chez Scaleway alors mêmes qu'ils sont concurrent sur l'hébergement. A noter enfin OVH vous "offre" généralement un espace mutualisé de 10MO lorsque vous déposez un nom de domaine, mais il ne peut pas accueilir autre chose qu'une page web statique: ni PHP ni service évolué comme discutés ici.
Ainsi, si vous hébergez chez Scaleway vous n'avez pas besoin de l'encombrement d'OVH (de plus en plus lourd et de moins en moins sympathique). C'est aussi parfois un peu moins cher (ex. 8€ au lieu de 9€/an pour un .com chez un "pur registrar"). Voyez cette liste comparative pour faire votre choix.
En pratique, la majorité de mes sites sont hébergés chez Scaleway (Online) et leurs DNS chez Ovh pour des raisons historiques, et tous deux français. Maintenant, OVH devient de plus en plus irrespectueuse.
DNS
La "zone DNS" est un tableau qui fait correspondre un nom de domaine ou de sous-domaine à une adresse IP ou un champ texte. Ce tableau est stocké chez un Registrar (cf. ci-avant), qui le diffuse ensuite sur d'innombrables noeuds sur l'internet.
Les informations qu'il contient sont très précises, strictes et essentielles. Elles relèvent du routage des communications internet ainsi que de la sécurité (pour le mail notamment): il convient donc de ne pas les modifier à la légère au risque de bloquer un service.
attention aussi au temps de propagation: généralement quelques dizaines de minutes, mais théoriquement jusqu'à 48h. Il faudra donc éviter les changements et hésitations intempestives au risque de n'y plus rien comprendre: prévoyez, réfléchissez et laissez reposer!
Champs DNS
Une liste des principaux champs DNS
NS: nom de domaine des serveurs DNS (généralement préremplis par votre hébergeur)A: les correspondances de nom de domaines (ou sous-domaines) et les IP de vos seveursMX: indique l'IP du ou des serveurs mails (cf mail-in-a-box)CNAME: simple "alias" vers un nom de domaine (équivaut à un A avec la même IP)TXT: utilisé comme fourre-tout (généralement pour des besoins de sécurité)
Un exemple pour mon domaine tecrd.com (ces données sont de toute façon publiques!)
$TTL 86400
@ IN SOA dns17.ovh.net. tech.ovh.net. (2021020400 7200 3600 3600000 86400)
120 IN NS dns17.ovh.net.
120 IN NS ns17.ovh.net.
IN MX 10 mx.tecrd.com.
IN A 51.15.247.53
IN TXT "v=spf1 mx -all"
IN TXT "1|www.tecrd.com"
* IN CNAME tecrd.com.
_caldavs._tcp IN SRV 0 0 443 mx.tecrd.com.
_carddavs._tcp IN SRV 0 0 443 mx.tecrd.com.
_dmarc IN TXT "v=DMARC1; p=quarantine"
_dmarc.ns1.mx IN TXT "v=DMARC1; p=reject"
_dmarc.ns2 IN TXT "v=DMARC1; p=reject"
_dmarc.www IN TXT "v=DMARC1; p=reject"
_token._dnswl IN TXT "8ftq3gxa61agn4r32hloz48z3ijjxd76"
demo IN A 51.15.247.53
iot IN A 51.15.247.53
mail IN A 51.15.247.53
mail._domainkey IN TXT ( "v=DKIM1; k=rsa; s=email; h=sha256; p=MIIBIjANBgkqhkiGF...FfcQ4wIDAQAB" )
mx IN MX 10 mx.tecrd.com.
mx IN A 163.172.183.26
ns1.mx IN A 163.172.183.26
ns1.mx IN TXT "v=spf1 -all"
ns2.mx IN A 163.172.183.26
ns2.mx IN TXT "v=spf1 -all"
pk IN A 51.15.247.53
prv IN A 51.15.247.53
share IN A 51.15.247.53
tmp IN A 163.172.180.200
visio IN A 51.15.247.53
www IN A 51.15.247.53
www IN TXT "3|welcome"
www IN TXT "l|fr"
www IN TXT "v=spf1 -all"
Notez que je n'ai pas utilisé d'ALIAS ici. J'ai aussi un serveur mail (champs MX) qui a son propre serveur de nom de domaines nsN.mx.tecrd.com et qui se trouve sur un serveur différent du serveur principal. Attention au "points" très significatifs! Le format d'une zone DNS est très strict.
L'entrée * IN CNAME tecrd.com. est un joker: si aucune des autres lignes de la zone DNS ne correspond à la demande, elle va être utilisée par défaut et donc rediriger n'importe quel sous-domaine vers mon serveur principal. C'est une façon simple de pouvoir "ouvrir" des sous-domaines web sans devoir toucher à la zone DNS.
DNS avancé
La gestion basique d'un DNS peut etre assez simple, telle que documentée ici.
Elle deviendra vite très compliquée pour de grosses installations, telles que la gestion d'hyperviseurs pour des parcs de serveurs virtuels (ce que fait Scaleway pour le compte de vos serveurs hébergés chez eux et mutualisés sur de gros serveurs). Les sont clairement hors sujet ici!
Entre les deux se trouve la gestion du DNS pour un serveur mail, et c'est bien l'une des raison d'utiliser mailinabox qui vous mache tout le travail! Plusieurs champs TXT, tel que le champ DKIM ci-dessus sont en effet nécessaires pour "faire bonne figure". Ils permettent de mieux identifier et de sécuriser votre serveur mail aux yeux du monde entier. Sans ces champs additionnels, votre serveur mail finir vite mal classé, et potentiellement serveur de SPAM: vous ne voulez absolument pas ça! Attention aussi, les normes évoluent et se durcissent en la matière et il ne faut pas trop trainer à les suivre pour cette même raison.
Davantage d'explications assez détaillées peuvent être lues ici (anglais).
Outils
Diagnostics
Quelques outils de diagnostic en ligne:
- DnsDumpster pour une carte complète de vos serveurs publics
- SSL labs note votre protection SSL/HTTPS (A+)
- Hardenize très complet et pour améliorer la robustesse du serveur
Ci desuss une recommendation: le SOA indique la période en seconde de l'expiration du cache, au delà de laquelle les serveurs DNS vont devoir réactualiser leurs tables relatives à vos serveurs. Lorsque l'on est en train d'y toucher on se doute qu'une période courte est utile. Une fois stabilisé, c'est une bonne pratique de l'allonger sensiblement pour réduire la charge des serveurs DNS à travers le monde!
Services
On peut aussi restreindre l'organisme chargé de faire ou renouveler le certificat via un "Certification Authority Authorization" (il existe des [https://sslmate.com/caa/|outils] en ligne qui vous aident pour cela).
Cela génère deux lignes de plus à mettre dans la zone DNS, par exemple:
tecrd.com. IN CAA 0 issue "letsencrypt.org" tecrd.com. IN CAA 0 iodef "mailto:admin@tecrd.com"
Propagation
Sous Linux, l'utilitaire principal est dig.
Pour étudier la propagation d'un changement DNS, on peut lui indiquer un "nameserver" spécifique proche du "registrar" (l'entreprise qui gère votre nom de domaine, indépendant des serveurs et hébergements). Ou inversement, on peut savoir si les changements ont été propagés au lointain: par exemple avec dig tecrd.com @8.8.8.8, la demande se fait auprès d'un serveur DNS distant de google.
Une liste plus complète d'outils linux (en anglais): https://linuxhint.com/common_dns_tools/
DynDNS
[en cours]
C'est un mécanisme utile lorsque l'on ne dispose pas d'une IP fixe pour son serveur. Cela provient généralement de la configuration de la box ADSL de son fournisseur internet.
Créez un identifiant et mot de passe chez OVH, puis un sous-domaine qui servira de cible.
Installez ces paquets:
apt-get install ddclient libio-socket-ssl-perl
Créez ensuite le fichier suivant /etc/ddclient.conf:
# Configuration file for ddclient ssl=yes protocol=dyndns2 use=web, web=checkip.dyndns.com server=www.ovh.com login=monsite.com-identifiantcree password='lemotdepassequevousavezcree' soudomainecréé.monsite.com
Relancez le service avec service ddclient restart.
L'état de votre affectation IP-nom de sous domaine dans le DNS de OVH est visible avec ddclient -query, et vous pouvez vérifier plus en profondeur le mécanisme avec la commande ddclient -daemon=0 -debug -verbose -noquiet
Vous pouvez enfin vouloir forcer une mise à jour en créant le fichier /etc/cron.weekly/ddclient avec ce contenu:
#!/bin/sh /usr/sbin/ddclient -force
A noter: si vous voulez avoir un site racine vers votre serveur, ajoutez un alias dans la zone DNS chez OVH. DynDNS ne marche qu'avec un sous-domaine!
Réseau externe sur une IP locale?
Notez qu'un accès à l'internet via un Modem 3G/4G peut vous donner une adresse IP apparamment dans le réseau local de l'opérateur téléphonique. Ces adresses, de type 192.168.X.Y ou 10.X.Y.Z sont spéciales: elles ne peuvent être rendues directement visibles avec une entrée dans un DNS, quel qu'il soit: même le mécanisme de dyndns ne pourra pas vous aider.
Dans ce cas il vous faudra relayer vos services via un serveur public standard, qui servira de "proxy" pour vous "redescendre" la communication (NAT: network address translation).
J'ai rédigé en détail mais en anglais une procédure similaire pour sonner un accès SSH à un PC portable qui se trouve dans un réseau quelconque et inconnu: reverse tunneling SSH.
Le mécanisme assez subtil et très puissant reprend l'idée
- d'un premier accès montant du serveur local vers le serveur publique (généralement en SSH très restreint),
- l'établissement sur le serveur public d'un tunnel "descendant" ers le serveur local (à traverse la communication SSH établie par celui-ci)
- et enfin un "port forwarding" du serveur public vers la connexion locale établie par le serveur local.
Ce type de tunnel SSH permet donc de:
- faire apparaitre des services locaux sur un serveur public (comme s'ils étaient fournis par le serveur au vu de l'extérieur).
- assurer un cryptage systématique des communications entre les deux serveurs (ex. un serveur HTTP local se retrouve "sécurisé" par le tunnel SSH, et peut bénéficier du certificat HTTPS du serveur public via un mécanisme de proxy web!).
- contourner des restrictions qui seraient imposées par le routeur local: tant qu'il est possible de se connecter en SSH depuis le serveur local sur le serveur public… et donc d'exposer potentiellement tout son LAN à des attaques externes!