Question Domaine de premier niveau / suffixe de domaine pour réseau privé?


Dans notre bureau, nous avons un réseau local avec une configuration DNS purement interne, sur laquelle tous les clients sont nommés whatever.lan. J'ai également un environnement VMware et, sur le réseau composé uniquement de machines virtuelles, 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. volonté être accessible depuis le réseau local. En conséquence, nous essayons de nous entendre sur une convention pour le suffixe de domaine / TLD que nous appliquons aux invités de ce nouveau réseau que nous mettons en place, mais nous ne pouvons en proposer une bonne, étant donné que .vm, .local et .lan tous ont des connotations existantes 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é sur un réseau purement interne?


103
2018-06-01 21:47


origine


Ne pas utiliser .local. Surtout si vous avez des clients Apple. - RainyRat
.test est mis de côté pour cette raison: secure.wikimedia.org/wikipedia/fr/wiki/.test - CWSpear
@CWSpear Ce n'est pas la réalité raison  .test est réservé, bien que cela en fasse un domaine sûr à utiliser pour tester réseaux qui ne seront pas connectés à Internet. - voretaq7
Les meilleures pratiques de @Otto vous obligeraient à acquérir un "vrai" nom de domaine (sous un TLD reconnu par l'ICANN) et à en créer un sous-domaine pour votre matériel local (par exemple, un registre). mydomain.com, délégué internal.mydomain.com sur un système de stockage interne et configurez correctement le DNS à horizon divisé ("vues" dans BIND) afin de ne pas divulguer les noms / adresses internes sur Internet. Ce n'est pas aussi joli qu'un TLD / pseudo-TLD, mais il est moins sujet aux bris car il est sous votre contrôle. - voretaq7
toutefois: n'utilisez pas un vrai nom de domaine que vous avez déjà utilisé pour des services de production destinés au public. Il existe diverses interactions autorisées entre www.example.com et *.internal.example.com qui ne sont pas autorisés entre www.example.com et *.example.net, notamment le réglage des cookies entre sites. L'exécution de services internes et externes sur le même domaine augmente le risque qu'une compromission d'un service public entraîne une certaine pénétration des services internes, et inversement, un service interne non sécurisé pourrait provoquer une mauvaise utilisation interne d'un service externe. - bobince


Réponses:


Ne pas utiliser un TLD inventé. Si l'ICANN le déléguait, vous auriez de gros problèmes. Même chose si vous fusionnez avec une autre organisation qui utilise le même nom de domaine factice. C'est pourquoi les noms de domaine uniques au monde sont préférés.

Le standard, RFC 2606 réserve des noms pour des exemples, de la documentation, des tests, mais rien pour un usage général, et pour de bonnes raisons: aujourd'hui, il est tellement facile et peu coûteux d'obtenir un nom de domaine réel et unique qu'il n'y a aucune bonne raison d'en utiliser un factice.

Alors, achetez iamthebest.org et utilisez-le pour nommer vos appareils.


85
2018-06-02 07:39



Pour être totalement sécurisé, je mettrais tout sur un sous-domaine du nom de domaine de mon entreprise, tel que local.company.org, vm.company.org, etc. - drybjed
+1 ceci. Votre entreprise a probablement déjà un domaine. Créez simplement un sous-domaine à partir de cela. Il ne doit pas nécessairement être visible / résoluble en dehors de votre réseau local. - Dan Carley
Eh bien, même avec de très bons avocats, vous aurez du mal à revendiquer ".lan" ou ".local" en invoquant une marque. Et l'argument "il est uniquement interne" est extrêmement faible: les organisations fusionnent, établissent des réseaux privés virtuels avec des organisations partenaires et commettent simplement des erreurs telles que des noms "privés" fuient. - bortzmeyer
Mon seul bœuf avec ceci est que vous ne pouvez pas vraiment "acheter" un domaine: vous ne pouvez en louer qu'un. Certains bozo oublient de payer une facture (et cela s'est produit dans quelques cas très en vue) et une partie essentielle de votre configuration va à un squatter aléatoire. Vous utilisez donc le domaine de votre entreprise? Les cadres décident de changer de nom ou d'être rachetés, et vous êtes coincé avec un ancien nom. .Local fonctionnait assez bien, mais une certaine société l’a préempté d’une manière qui refuse de jouer gentiment. J'aimerais vraiment voir quelque chose comme .lan ou .internal réservé formellement à cet effet, mais jusque-là, c'est la meilleure option. - Joel Coel
D'accord avec @Joel Coel, vous êtes locataire et rien de plus. Il devrait y avoir deux noms de TLD réservés pour usage interne uniquement cela doit être considéré comme invalide en public et non accessible par les réseaux publics. Un nom serait pour une utilisation interne à la maison, le second serait pour une utilisation professionnelle interne. Les deux seraient considérés comme des "TLD privés" au sens où nous avons des "sous-réseaux privés" non routables (192.168.x.x et ilk). Cela permet aux utilisateurs à domicile de faire quelque chose en plus d'être forcé dans .local et mDNS. Idem pour les petites entreprises utilisant un réseau local interne derrière un NAT sans domaine. - Avery Payne


Utilisez un sous-domaine du domaine enregistré de votre entreprise pour les ordinateurs 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 société fictive Example Corporation.

Serveurs Internet:
www.example.com
mail.exemple.com
dns1.example.com

Machines internes:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

J'ai utilisé "corp" pour indiquer que ce sous-domaine décrit les machines du réseau interne de l'entreprise, mais vous pouvez utiliser tout ce que vous voulez ici, tel que "internal": client1.internal.example.com.

N'oubliez pas non plus que les zones et sous-domaines DNS ne doivent pas nécessairement s'aligner sur le schéma de numérotation de votre réseau. Ma société, par exemple, compte 37 sites, chacun avec son propre sous-réseau, mais tous les sites utilisent le même nom de domaine (interne). Inversement, vous pouvez n'avoir qu'un ou plusieurs sous-réseaux, mais de nombreux domaines internes homologues ou niveaux de sous-domaines pour vous aider à organiser vos machines.


46
2018-06-02 13:03





L'utilisation d'un sous-domaine interne présente un autre avantage: en utilisant habilement 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 assurance qualité 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 d'assurance qualité, vous définissez le suffixe de recherche sur "qa.exemple.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 "exemple.com" => serveur de base de données utilisé: dbserv1.example.com

De cette façon, vous pouvez utiliser les mêmes paramètres dans tous les environnements.


29
2018-06-04 12:00



C'est génial. - Chris Magnuson
Jusqu'à ce que quelqu'un confuse mal son poste de travail avec le suffixe de recherche de production pour tester un problème, puis met à jour par inadvertance de nombreux enregistrements de production. - Joel Coel
C’est assez grossier, les enregistrements SRV sont très simples à analyser et peuvent être placés dans n’importe quelle zone, de sorte que le même serveur de base de données dessert plusieurs zones. Dans ce cas, un peu de code renseignerait la valeur dans vos fichiers de configuration. Et vous pouvez utiliser le nom de la base de données comme clé SRV et la valeur pointant bien sûr vers le nom d'hôte. Je ne compterais jamais sur les suffixes de recherche. Vous pouvez également faire preuve de beaucoup de créativité avec les enregistrements TXT et les fourrer avec des valeurs chiffrées aes-256 (puis encodées en base64), si ce sont des secrets. Vous pouvez utiliser les enregistrements TXT pour toutes sortes de choses. - figtrap
voyez, mais ce que je veux, c'est exemple.com, exemple.dev et exemple.stg. Les 2 derniers sont uniquement sur un réseau privé, puis-je configurer un serveur DNS local pour un accès sans configuration? Toujours en utilisant une configuration similaire ici pour tous les sites, il suffit de déplacer les modifications jusqu'à tld. Facile pour .dev avec un fichier hosts, mais zéro config ... - DigitalDesignDj


Comme déjà dit, vous ne devriez pas utiliser un TLD non enregistré pour votre réseau privé. Surtout maintenant que l'ICANN permet à presque tout le monde d'enregistrer de nouveaux TLD. Vous devriez alors utiliser un vrai nom de domaine

De l'autre côté, le RFC 1918 est clair:

Références indirectes à ces adresses   devrait être contenu dans la   entreprise. Des exemples remarquables de telles   les références sont des enregistrements de ressources DNS   et d'autres informations faisant référence à   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.


10
2018-06-02 12:41





Nous avons tendance à ne considérer aucune différence dans la dénomination virtuelle des hôtes par rapport à la physique. En fait, nous avons commencé à extraire 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 ceux-ci (et utilisons une relation simple pour le montrer dans notre documentation).

Le but est que quand 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 à un autre - par exemple, une webapp peu performante n'a pas besoin de consommer des cycles de processeur coûteux - virtualisez-la et conserve son schéma de nommage, tout continue à fonctionner.


8
2018-06-01 21:52





Je ne suis pas sûr que cela vous aidera, mais pour les DNS internes de mon compte AWS, j'utilise .aws comme le tld, et il semble fonctionner parfaitement bien.

Je sais qu'il y a des TLD que vous devriez simplement ne pas utiliser, mais à part ceux-là, je ne pense pas que ce soit trop strict.

J'ai travaillé dans quelques grandes entreprises, où elles utilisaient la source d'authentification comme TLD, ce qui signifie que s'il s'agissait d'un serveur MS / Windows, en utilisant Active Directory comme source d'authentification, ce serait: .adet quelques autres seraient .ldap (Pourquoi n'utilisaient-ils pas simplement la même source? Ou des serveurs répliquant à partir du même service d'annuaire? Je ne sais pas, c'était comme ça quand je suis arrivé là-bas)

Bonne chance


-4
2018-02-29 14:28



Amazon s'est maintenant inscrit .aws en tant que TLD, vous pourriez donc commencer à voir des problèmes: nic.aws - Mark McKinstry
Pour information, le .aws est enregistré récemment le "25 mars 2016" => newgtlds.icann.org/fr/program-status/delegated-strings - Bruno Adelé
Bien que je ne pense pas que l’utilisation d’un TLD bidon soit un gros problème, du moins si le système complet est fermé et utilise un proxy pour communiquer avec Internet en général, ".aws" est un très mauvais choix, sauf si vous ne sont pas dans AWS! Il y a beaucoup trop de scénarios imaginables dans lesquels vous ne pourrez plus communiquer avec AWS. - figtrap