Technologies informatiques,
Recherche et développement

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
[[public:heberger_ses_services|< Retour à l'index]]

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 [[https://www.webandseo.fr/webmaster/registrar/|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 [[https://support.marcaria.com/hc/fr/articles/215527983-Que-sont-les-enregistrements-DNS-|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 seveurs
  * ''MX'': indique l'IP du ou des serveurs mails (cf [[doc:formations:hebergement:service:mailinabox#prerequis|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!)

<code>
$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"
</code>

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 [[doc:formations:hebergement:service:mailinabox|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 [[https://ns1.com/resources/dns-zones-explained|lues ici]] (anglais).
==== Outils ====

=== Diagnostics ===

Quelques outils de diagnostic en ligne:

  * [[https://intodns.com/tecrd.comp|IntoDNS]]
  * [[https://dnsdumpster.com/|DnsDumpster]] pour une carte complète de vos serveurs publics
  * [[https://mxtoolbox.com/SuperTool.aspx?action=dns%3atecrd.com&run=toolpage|MXtoolbox]]
  * [[https://www.ssllabs.com/ssltest/analyze.html|SSL labs]] note votre protection SSL/HTTPS (A+)
  * [[https://www.hardenize.com|Hardenize]] très complet et pour améliorer la robustesse du serveur

{{:doc:formations:hebergement:serveur:dns_issue.png}}

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 [[https://linuxize.com/post/how-to-use-dig-command-to-query-dns-in-linux/|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. 

([[https://www.p3ter.fr/gestion-du-dyndns-sous-linux-avec-ovh.html|source partielle]])

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'':

<code>
# 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
</code>

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 [[https://en.wikipedia.org/wiki/Reserved_IP_addresses|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: [[https://www.oz4.us/2015/10/linux-restricted-tunneling-handling.html|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!