Restriction d'un serveur DNS personnel

a marqué ce sujet comme résolu.

Bonjour à tous !

Je me pose une question par rapport à la génération de certificats avec Let’s Encrypt. Supposons que je dispose d’un serveur Web sur lequel j’héberge mon site monsite.com, auquel j’aimerais fournir la possibilité d’être accédé en HTTPS. Je décide pour cela d’utiliser Let’s Encrypt. Tout se passe bien, mon site est accessible en HTTPS, tout va pour le mieux dans le meilleur des mondes.

Maintenant, supposons que quelqu’un d’autre (même moi avec un deuxième serveur Web) souhaite générer des certificats pour monsite.com. Il va alors en faire la demande à Let’s Encrypt qui va lui soumettre des défis pour s’assurer qu’il est bien propriétaire de ce nom de domaine. Pour les citer :

Pour lancer le processus, l’agent demande à l’AC Let’s Encrypt ce qu’elle doit faire pour prouver qu’elle contrôle example.com. L’AC Let’s Encrypt examinera le nom de domaine demandé et émettra un ou plusieurs ensembles de défis. Ce sont différentes manières que l’agent peut utiliser pour prouver le contrôle du domaine. Par exemple, l’autorité de certification peut donner à l’agent le choix entre:

  1. Provisionner un enregistrement DNS sous example.com, ou
  2. Provisionner une ressource HTTP sous l’URI .well-known sur https://example.com/

En plus des défis, l’AC de chiffrement de Let fournit également un nonce que l’agent doit signer avec sa paire de clés privée pour prouver qu’il contrôle la paire de clés.

https://letsencrypt.org/fr/how-it-works/

Je comprends bien le deuxième défi : si je suis propriétaire du site, alors je peux créer un tel chemin, ce que ne peut pas faire quelqu’un qui n’a pas accès aux fichiers de mon site. Je comprends également le premier, mais ne m’était jamais posé la question : qui authentifie un serveur DNS ? Pourquoi puis-je indiquer l’IP de mon serveur quand on demande monsite.com mais pas quand on demande google.com ? Qu’est-ce qui authentifie, donne le droit d’avoir une entrée DNS dans un serveur ?

Merci d’avance :)

En fait, DNS c’est un système hiérarchique, le caractère séparant plusieurs niveaux hiérarchiques, c’est le point. C’est important à comprendre, parce que chaque niveau hiérarchique est géré par une entité différente.

Prenons par exemple un site qui s’appellerait monsite.fr. Il y a deux niveaux hiérarchiques :

  • monsite, qui s’appelle le domaine.
  • fr, qui s’appelle l’extension ou le top level domain (TLD).

Quand tu tapes une adresse dans ton navigateur, le but du jeu pour lui c’est de transformer cette adresse en adresse IP qu’il peut contacter. Pour cela, il va procéder à une résolution de nom de domaine. Cette résolution commence systématiquement par la droite (donc le TLD).

Ton navigateur va tout d’abord contacter un serveur DNS primaire (il en existe 13 gérés par diverses organisation : la liste, certains d’entre eux exploitent la technologie anycast qui permet de répartir le trafic sur plusieurs machines physiques). Ce sont les serveurs qui sont à la racine du système : ils contiennent la liste de tous les TLD et des organismes chargés de les administrer. Leur ip est configurée de base dans ton système (ce n’est pas tout à fait vrai, il y a des serveurs dits miroirs qui recopient les informations des serveurs primaires et c’est eux qu’on contacte, on ne contacte jamais un serveur primaire directement, mais peu importe) et tu peux la changer assez facilement dans ton centre réseau et partage si tu préfères utiliser un autre serveur DNS. Dans notre cas, le TLD fr est géré par l’AFNIC. Le serveur primaire (enfin en réalité, le serveur miroir du primaire) contacté va donc retourner l’adresse du serveur de l’AFNIC.

Ensuite, notre navigateur va contacter le serveur de l’AFNIC et lui demander l’adresse du serveur qui gère le domaine monsite enregistré avec le TLD fr. monsite a été enregistré sur le serveur de l’AFNIC par un registar, une entreprise à qui l’AFNIC a donné l’autorisation d’enregistrer des noms de domaine (genre Gandi, OVH…). Une fois qu’il a récupéré la bonne adresse, il peut contacter le serveur qui est derrière le nom de domaine.

Pour répondre à ta question : le nom de domaine est donc authentifié par l’organisme qui se charge de gérer le TLD (l’AFNIC pour fr) qui autorise un certain nombre d’entreprises à enregistrer des noms de domaines. Quant au TLD, il est authentifié par un certain nombre de serveurs primaires (et de serveurs miroirs) auprès desquels l’ensemble des gestionnaires de TLD sont déclarés. Enfin, les serveurs primaires ce sont des serveurs dont l’ip est fixe, connue par tous les systèmes et codée en dur dans tous les systèmes.

J’espère avoir répondu à ta question. :)

+2 -0

je comprends bien le deuxième défi : si je suis propriétaire du site, alors je peux créer un tel chemin, ce que ne peut pas faire quelqu’un qui n’a pas accès aux fichiers de mon site.

Merci d’avance :)

BunshinKage

En réqlité, on se fiche de savoir qui a la main sur le site en soi, ou le serveur sur lequel il est. La seule chose qui importe, pour obtenir un certificat, c’est de savoir qui a la main sur la zone DNS.

La vérification par le site web marche quand même parce que si elle réussit, alors cela implique que la vérification sur le DNS réussit aussi : en effet, pour faire pointer l’enregistrement DNS vers un site qui contient le fichier challenge, cela implique d’avoir la main sur la zone DNS.

Comme l’extrait de doc le dit, Let’s Encrypt peut tout à fait aussi ne vérifier que ce qui compte réellement, à savoir la partie DNS, ce qui est la 1re méthode.

La validation par challenge sur le site Web (méthode 2) s’avère tout de même bien plus pratique à automatiser pour beaucoup d’administrateurs. Je suppose que c’est pour cette raison qu’elle a été mise en place.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte