Domaine de premier niveau / suffixe de domaine pour le réseau privé?
Dans notre bureau, nous avons un réseau local avec une configuration DNS purement interne, sur lequel les clients sont tous appelés whatever.lan. J'ai également un environnement VMware, et sur le réseau de machines virtuelles uniquement, je nomme les machines virtuelles whatever.vm.
Actuellement, ce réseau pour les machines virtuelles n'est pas accessible à partir de notre réseau local, mais nous mettons en place un réseau de production pour migrer ces machines virtuelles vers lequel sera accessible depuis le LAN. En conséquence, nous essayons de nous arranger sur une convention pour le suffixe de domaine/TLD que nous appliquons aux invités sur ce nouveau réseau que nous mettons en place, mais nous ne pouvons pas en trouver un bon, étant donné que .vm, .local et .lan tous ont une connotation existante dans notre environnement.
Alors, quelle est la meilleure pratique dans cette situation? Existe-t-il une liste de TLD ou de noms de domaine pouvant être utilisés en toute sécurité pour un réseau purement interne?
N'utilisez pas un TLD inventé. Si l'ICANN le déléguait, vous auriez de gros ennuis. Même chose si vous fusionnez avec une autre organisation qui utilise le même TLD factice. C'est pourquoi les noms de domaine uniques au monde sont préférés.
La norme, RFC 2606 réserve des noms pour des exemples, de la documentation, des tests, mais rien pour une utilisation générale, et pour de bonnes raisons: aujourd'hui, il est si facile et bon marché d'obtenir un nom de domaine réel et unique qu'il existe n'est pas une bonne raison d'utiliser un mannequin.
Alors, achetez iamthebest.org et utilisez-le pour nommer vos appareils.
Utilisez un sous-domaine du domaine enregistré de votre entreprise pour les machines internes dont vous ne souhaitez pas que les noms soient disponibles sur Internet. (Ensuite, bien sûr, hébergez uniquement ces noms sur vos serveurs DNS internes.) Voici quelques exemples pour la fictive Example Corporation.
serveurs accessibles sur Internet:
www.example.com
mail.example.com
dns1.example.com
Machines internes:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com
J'ai utilisé "corp" pour signifier que ce sous-domaine décrivait des machines sur le réseau interne de l'entreprise, mais vous pouvez utiliser tout ce que vous voulez ici, comme "interne": client1.internal.example.com.
N'oubliez pas non plus que les zones et sous-domaines DNS n'ont pas à s'aligner sur votre schéma de numérotation réseau. Mon entreprise, par exemple, possède 37 emplacements, chacun avec son propre sous-réseau, mais tous les emplacements utilisent le même nom de domaine (interne). Inversement, vous ne pouvez avoir qu'un ou quelques sous-réseaux, mais plusieurs domaines internes homologues ou niveaux de sous-domaines pour vous aider à organiser vos machines.
Il y a un autre avantage à utiliser un sous-domaine interne: en utilisant intelligemment les suffixes de recherche et uniquement les noms d'hôte au lieu du nom de domaine complet, vous pouvez créer des fichiers de configuration qui fonctionnent à la fois en développement, en AQ et en production.
Par exemple, vous utilisez toujours "database = dbserv1" dans votre fichier de configuration.
Sur le serveur de développement, vous définissez le suffixe de recherche sur "dev.example.com" => serveur de base de données utilisé: dbserv1.dev.example.com
Sur le serveur QA, vous définissez le suffixe de recherche sur "qa.example.com" => serveur de base de données utilisé: dbserv1.qa.example.com
Et sur le serveur de production, vous définissez le suffixe de recherche sur "example.com" => serveur de base de données utilisé: dbserv1.example.com
De cette façon, vous pouvez utiliser les mêmes paramètres dans chaque environnement.
Depuis que les réponses précédentes à cette question ont été écrites, il y a eu quelques RFC qui modifient quelque peu les directives. RFC 6761 traite des noms de domaine à usage spécial sans fournir de conseils spécifiques pour les réseaux privés. RFC 6762 recommande toujours de ne pas utiliser de TLD non enregistrés, mais reconnaît également qu'il y a des cas où cela sera fait de toute façon. Étant donné que le système commun . Local est en conflit avec le DNS multidiffusion (le sujet principal de la RFC), Annexe G. Espaces de noms DNS privés recommande les TLD suivants:
- intranet
- interne
- privé
- corp
- maison
- lan
L'IANA semble reconnaître les deux RFC mais n'incorpore pas (actuellement) les noms énumérés à l'annexe G.
En d'autres termes: vous ne devriez pas le faire. Mais quand vous décidez de le faire de toute façon, utilisez l'un des noms ci-dessus.
Comme déjà dit, vous ne devez pas utiliser un TLD non enregistré pour votre réseau privé. Surtout maintenant que l'ICANN permet à presque n'importe qui d'enregistrer de nouveaux TLD. Vous devez ensuite utiliser un vrai nom de domaine.
De l'autre côté, le RFC 1918 est clair:
Les références indirectes à ces adresses doivent être contenues dans l'entreprise. Des exemples importants de telles références sont les enregistrements de ressources DNS et d'autres informations faisant référence à des adresses privées internes.
Votre serveur de noms doit donc également utiliser des vues pour empêcher la transmission des enregistrements privés sur Internet.
Nous avons tendance à ne considérer aucune différence dans la dénomination virtuelle des hôtes de la physique - en fait, nous avons pris pour abstraire la configuration de l'hôte (logiciel) de la couche physique.
Nous achetons donc des éléments matériels et créons des éléments hôtes par-dessus (et utilisons une relation simple pour le montrer dans notre documentation).
Le but est que lorsqu'un hôte existe, le DNS ne devrait pas être le facteur déterminant - car nous avons des machines qui se déplacent d'un espace à l'autre - par exemple, une webapp peu performante n'a pas besoin de consommer des cycles CPU coûteux - virtualisez-la , et il conserve son schéma de dénomination, tout continue de fonctionner.