Nom DNS privé ou simple IP ? Décidez avant de le partager

Deux questions se mélangent lorsqu'un service privé est ouvert à des utilisateurs distants. La première est quel nom les clients doivent utiliser ; la seconde, quelles sources le service doit admettre. Répondez-y dans cet ordre, car un nom correct derrière une règle d'accès erronée échoue quand même, et une règle correcte derrière un nom qui ne se résout pas n'est jamais testée.

Première condition : quel chemin de résolveur les clients ont-ils ?

Un nom privé ne fonctionne que si le résolveur du client peut y répondre. Cela signifie qu'un client distant autorisé doit joindre un serveur DNS qui détient la zone, soit par le tunnel, soit par un résolveur que l'organisation exploite déjà pour les utilisateurs distants. Le tunnel est un transport, pas un annuaire. Il donne au client un chemin vers un résolveur, et il ne lui dit pas quelle zone interroger.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Un résolveur public n'apprendra pas une zone privée parce que l'ordinateur portable s'est connecté à un VPN.

Le suffixe mérite la même attention. Utilisez un sous-domaine d'un domaine que l'organisation contrôle, afin que la propriété et la planification des certificats restent explicites. Évitez .local : la spécification multicast DNS lie ce suffixe à la résolution link-local, et un tunnel routé ne reproduit pas ce comportement pour vous.

Deuxième condition : quelle source le service reçoit-il ?

Les règles d'admission s'écrivent par rapport à des adresses, donc la question utile est quelle adresse le service voit après le routage et la traduction. Pour un service d'exemple à 10.20.30.40, les clients du bureau arrivent depuis 10.20.30.0/24 et les clients distants depuis un pool séparé comme 10.99.0.0/24.

Si une passerelle traduit le pool distant, le service voit le traducteur, et une règle écrite pour 10.99.0.0/24 ne correspondra pas.

Lisez ceci du côté du service plutôt que du côté du client. Un journal d'écoute ou une capture de paquets sur l'hôte du service montre la source réellement arrivée ; l'adresse du client lui-même n'est qu'une supposition sur ce qui a survécu au chemin.

Troisième condition : le nom est-il lié à un service ou à un hôte ?

Un nom qui pointe vers l'adresse d'une machine lie chaque client à cette machine. Un nom qui pointe vers un répartiteur de charge ou une adresse de service stable survit au remplacement de l'hôte derrière lui. Choisissez délibérément, car changer cela plus tard signifie changer les favoris de chaque client et le sujet de chaque certificat.

Pour un seul service interne, un enregistrement direct convient généralement et se raisonne plus simplement.

Pour tout ce qui sera remplacé, reconstruit ou mis à l'échelle, un frontal stable vaut la configuration supplémentaire. Le test est simple : si vous pouvez remplacer le backend sans prévenir les utilisateurs, le nom est lié au service ; sinon, il est lié à un hôte.

Testez les deux décisions séparément

Résolvez d'abord, connectez ensuite. Un test de résolution qui renvoie l'adresse attendue prouve le chemin du nom et ne dit rien de l'admission. Un test de connexion prouve le chemin et la règle ensemble, donc ne l'exécutez qu'après la réussite de la résolution.

curl -sv --max-time 5 https://files.corp.example/health

Testez ensuite une source interdite une fois, et consignez le résultat.

Gardez les deux enregistrements séparés dans votre documentation : le nom et sa zone, les sources admises et le propriétaire de la règle. Quand l'un change, l'autre n'a pas à changer.

Où la décision se trompe habituellement

La défaillance courante est un service publié sous un nom qui ne se résout que sur le réseau du bureau, avec une règle d'admission qui n'admet que la plage du bureau. Les utilisateurs distants signalent alors un service cassé qui est en fait deux omissions distinctes. La seconde défaillance courante est l'inverse : une règle d'admission large ajoutée pour faire disparaître un problème de nom laisse le service joignable depuis des sources que personne n'avait prévues. Les deux sont des omissions de configuration, et depuis la chaise de l'utilisateur elles se ressemblent.

Aucune des deux erreurs n'est visible depuis un seul test réussi. C'est pourquoi les deux décisions méritent des enregistrements séparés et des tests séparés, même lorsque la même personne prend les deux.

Écrivez les deux avant que le service entre en production, car le prochain changement sera plus facile à raisonner. L'enregistrement est court : une ligne pour le nom et sa zone, une ligne pour les sources admises et le propriétaire de la règle.