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

115

Dans nos bureaux, nous disposons d’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 vers lequel migrer ces machines virtuelles, qui seront accessibles depuis le réseau local. Par conséquent, nous essayons de régler sur une convention pour le suffixe de domaine / TLD nous appliquons aux clients sur ce nouveau réseau , nous mettons en place, mais nous ne pouvons pas trouver une bonne, étant donné que .vm, .localet .lantous ont des connotations existantes dans notre environnement.

Alors, quelle est la meilleure pratique dans cette situation? Existe-t-il une liste de noms de domaine ou de TLD pouvant être utilisés en toute sécurité sur un réseau purement interne?

— Otto
source

2

Ne pas utiliser .local. Surtout si vous avez des clients Apple.

— RainyRat

2

.test est réservé pour cette raison: secure.wikimedia.org/wikipedia/fr/wiki/.test

— CWSpear

1

@CWSpear Ce n'est pas la raison réelle qui.test est réservée, bien que cela en fasse un domaine sûr à utiliser pour les réseaux de test qui ne seront pas connectés à Internet.

— voretaq7

10

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, enregistrer mydomain.com, déléguer internal.mydomain.comà un service de réseau interne et configurer correctement le DNS split horizon ( "views" dans BIND) afin de ne pas divulguer de noms / adresses internes sur Internet. Ce n'est pas aussi joli qu'un TLD / pseudo-TLD, mais il est moins sujet aux ruptures qu'il est sous votre contrôle.

— voretaq7

9

Cependant : n'utilisez pas un vrai nom de domaine que vous avez déjà utilisé pour des services de production destinés au public. Diverses interactions sont autorisées entre www.example.comet *.internal.example.cominterdites entre www.example.comet *.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

94

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.

La norme 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 si facile et peu coûteux d'obtenir un nom de domaine réel et unique qu'il n'y a aucune bonne raison d'utiliser un nom de domaine. mannequin.

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

— Bortzmeyer
source

53

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

4

+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

3

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 "c'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

8

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 de se faire acheter, 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

6

D'accord avec @Joel Coel, vous êtes locataire et rien de plus. Deux noms de TLD réservés, à usage interne uniquement , doivent être considérés comme invalides en public et inaccessibles par les réseaux publics. Un nom serait pour une utilisation interne à la maison, le second serait pour une utilisation professionnelle interne. Tous 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.xx 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

49

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 faisant face à 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 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, comme "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 votre schéma de numérotation de réseau. Ma société, par exemple, compte 37 emplacements, chacun avec son propre sous-réseau, mais tous utilisent le même nom de domaine (interne). Inversement, vous pouvez n'avoir qu'un ou quelques sous-réseaux, mais de nombreux domaines internes homologues ou niveaux de sous-domaines pour vous aider à organiser vos machines.

— Jay Michaud
source

32

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, 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 "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 tous les environnements.

— geewiz
source

2

C'est génial.

— Chris Magnuson

19

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

1

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), s’il s’agit de 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

15

Depuis que les réponses précédentes à cette question ont été écrites, plusieurs RFC ont quelque peu modifié les indications. La RFC 6761 traite des noms de domaine à usage spécial sans fournir de conseils spécifiques aux réseaux privés. La 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. Comme le fichier .local couramment utilisé est en conflit avec le multidiffusion DNS (le sujet principal du RFC), l' annexe G. Les espaces de noms DNS privés recommandent les TLD suivants:

intranet
interne
privé
corp
domicile
lan

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 quand même, utilisez l’un des noms ci-dessus.

— blihp
source

L'annexe G se trouve devant la liste que vous citez: "Nous ne recommandons pas du tout l'utilisation de domaines de premier niveau non enregistrés". C'est plus le point clé. Les noms donnés ne sont pas "recommandés", ils sont juste des noms observés qui fonctionneront mieux que .localce qui est en quelque sorte réservé au MulticastDNS, qui est

— présenté

2

Je ne suis pas d'accord. Le point essentiel est l’absurdité du conseil: "ne le faites pas ... mais quand vous le ferez ..." Il n’est pas réaliste de penser que les réseaux nationaux / de petites entreprises / non-publics doivent enregistrer un TLD. Les gens sont vont utiliser TLDs non enregistrés à ce jour mieux pour aider tout le monde et dire « OK, voici une liste des TLDs non enregistrés que vous pouvez utiliser en interne » plutôt que de faire semblant que tout le monde va suivre les conseils de la ligne dure.

— Blihp

Nous resterons en désaccord alors. Le fait que certaines personnes aient utilisé des TLD comme s'ils étaient internes (par exemple, .MAIL dans de nombreuses documentations) est exactement la raison pour laquelle ces TLD n'ont pas pu être délégués et sont maintenant indéfiniment morts. Par conséquent, continuer à recommander aux gens d'utiliser les TLD de cette manière nuit à la communauté Internet mondiale. Le conseil indique que puisque certains TLD sont déjà utilisés de la sorte, si les utilisateurs doivent abuser, ils doivent les réutiliser au lieu d’en abuser de nouveaux. La RFC2606 est claire pour que les TLD l'utilisent en interne, cela fonctionnera:.EXAMPLE .TEST .INVALID

— Patrick Mevzek

12

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

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

Les références indirectes à de telles adresses doivent être contenues dans l'entreprise. Les enregistrements de ressources DNS et autres informations faisant référence à des adresses privées internes sont des exemples remarquables de telles références. Votre serveur de noms doit donc également utiliser des vues pour empêcher la transmission des enregistrements privés sur Internet.

— Benoit
source

10

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 pris l'habitude d'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 ceux-ci (et utilisons une relation simple pour l'indiquer 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.

— Mike Fiedler
source

-4

Je ne suis pas sûr que cela vous aidera, mais pour le DNS interne de mon compte AWS, j'utilise .awsle tld, et cela semble parfaitement fonctionner.

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.

Je travaillais à quelques grandes entreprises, où ils utiliseraient la source d'authentification que le TLD, ce qui signifie si elle était un serveur MS / Windows, en utilisant Active Directory comme source auth, il serait .ad, et quelques autres seraient .ldap(Pourquoi ils weren N'utilisez 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

— Justin
source

2

Amazon s'est maintenant inscrit en .awstant que TLD et vous risquez de rencontrer des problèmes un peu plus tard: nic.aws

— Mark McKinstry le

1

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