Bonjour,
Je voudrais savoir quel est la bonne pratique de gestion des nom interne à une entreprise.
Actuellement l'entreprise dans laquelle je travail dispose d'un NDD en maboite.tld du classique en somme.
actuellement maboite.tld pointe et www.maboite.tld pointe vers le site web de l'entreprise hébergé en data.
tout les autres sous domaines pointent vers une page poubelle.
Mon soucis, j'ai besoin d'avoir des nom de domaines pour les services internes. quel est le mieux : xxx.domaineMS.local. en gérant ça pas forcément de façon évidente sur le service dns de ms xxx.lan|whatever.maboite.tld mais comment gérer au niveau de l'enregistrement racine ? autre solution ?
cordialement Alexis Lameire
Salut
Le 10/12/2014 11:36, Alexis Lameire a écrit :
xxx.domaineMS.local. en gérant ça pas forcément de façon évidente sur le service dns de ms xxx.lan|whatever.maboite.tld mais comment gérer au niveau de l'enregistrement racine ? autre solution
Je ne suis pas sûr de bien comprendre le pb de la racine.
C'est pas une bonne pratique, mais mon humble expérience : ici j'ai plusieurs domaines.
- blahblah.fr pour les choses publics (genre www. ou webmail. etc) - blahblah.net pour les noms de serveurs/services disponible lan/wan (exemple mx.blahblah.net ou smtp.) - blahblah.lan pour les services uniquement en interne. (genre nas.blahblah.lan)
les serveurs dns interne (bind en l'occurence) sont master sur les zones blahblah.lan et les reverse.
On 10/12/2014 11:52, Manu wrote:
Salut
Le 10/12/2014 11:36, Alexis Lameire a écrit :
xxx.domaineMS.local. en gérant ça pas forcément de façon évidente sur le service dns de ms xxx.lan|whatever.maboite.tld mais comment gérer au niveau de l'enregistrement racine ? autre solution
Je ne suis pas sûr de bien comprendre le pb de la racine.
C'est pas une bonne pratique, mais mon humble expérience : ici j'ai plusieurs domaines.
- blahblah.fr pour les choses publics (genre www. ou webmail. etc)
- blahblah.net pour les noms de serveurs/services disponible lan/wan
(exemple mx.blahblah.net ou smtp.)
- blahblah.lan pour les services uniquement en interne. (genre
nas.blahblah.lan)
les serveurs dns interne (bind en l'occurence) sont master sur les zones blahblah.lan et les reverse.
Pourquoi le .local (ou .lan, ou autre, ...) n'est pas une bonne idée : Il y a un Bortz pour ça ! http://www.bortzmeyer.org/pourquoi-le-tld-local-n-est-pas-une-bonne-idee.htm...
Sinon, chez nous, on a notre $corp.tld et une zone priv.$corp.tld dont les NS sont privés et sans délégation dans la zone $corp.tld. Les NS de la zone priv.$corp.tld sont déclarés statiquement sur les resolvers internes. Comme ça, on a un "domaine qui n'existe pas", vue de l'extérieur (comme .lan) mais dans un espace de nommage que l'on maîtrise.
Le 10/12/2014 13:31, Simon Morvan a écrit :
Pourquoi le .local (ou .lan, ou autre, ...) n'est pas une bonne idée : Il y a un Bortz pour ça ! http://www.bortzmeyer.org/pourquoi-le-tld-local-n-est-pas-une-bonne-idee.htm...
Ah merci pour cette "Minute de Monsieur Bortz" :-) Son argumentation tourne autour du .local en fait. Mais ok, la solution que tu décris semble être une meilleure pratique que la mienne.
M
Sinon, chez nous, on a notre $corp.tld et une zone priv.$corp.tld dont les NS sont privés et sans délégation dans la zone $corp.tld. Les NS de la zone priv.$corp.tld sont déclarés statiquement sur les resolvers internes. Comme ça, on a un "domaine qui n'existe pas", vue de l'extérieur (comme .lan) mais dans un espace de nommage que l'on maîtrise.
Le 10/12/2014 14:12, Simon Morvan a écrit :
et tu penses qu'elle ne s'applique pas au .lan ?
Je comprend que le .local est utilisé par Microsoft ou Apple, ce qui peut finalement générer peut être des effets de bord. Le .lan ne l'est pas (utilisé), donc ça devrait moins générer de problème en pratique.
Mais maintenant, je comprend le fond, concernant l'unicité d'une ressource, et concrètement c'est exactement le même boulot en terme de dns de créer un mondomaine.lan ou un local.mondomaine.fr. Donc, autant être propre.
On 10/12/2014 14:39, Manu wrote:
Je comprend que le .local est utilisé par Microsoft ou Apple, ce qui peut finalement générer peut être des effets de bord. Le .lan ne l'est pas (utilisé), donc ça devrait moins générer de problème en pratique.
Si, justement il est potentiellement utilisé chez la crèmerie d'en face (fusions-acquisitions, tout ça...) et .lan pourrait aussi un jour être un vrai TLD avec l'ouverture galopante (et le besoin d'argent de l'ICANN). Dans les deux cas, tu rigoles bien quand ça arrive...
Mais maintenant, je comprend le fond, concernant l'unicité d'une ressource, et concrètement c'est exactement le même boulot en terme de dns de créer un mondomaine.lan ou un local.mondomaine.fr. Donc, autant être propre.
Exactement.
j'ai un peut écouté tous vos avis,
je vais donc rester sur du xxxx.lan.maboite.tld ;)
Cordialement Alexis Lameire
Le 10 décembre 2014 15:04, Simon Morvan garphy@zone84.net a écrit :
On 10/12/2014 14:39, Manu wrote:
Je comprend que le .local est utilisé par Microsoft ou Apple, ce qui peut finalement générer peut être des effets de bord. Le .lan ne l'est pas (utilisé), donc ça devrait moins générer de problème en pratique.
Si, justement il est potentiellement utilisé chez la crèmerie d'en face (fusions-acquisitions, tout ça...) et .lan pourrait aussi un jour être un vrai TLD avec l'ouverture galopante (et le besoin d'argent de l'ICANN). Dans les deux cas, tu rigoles bien quand ça arrive...
Mais maintenant, je comprend le fond, concernant l'unicité d'une ressource, et concrètement c'est exactement le même boulot en terme de dns de créer un mondomaine.lan ou un local.mondomaine.fr. Donc, autant être propre.
Exactement.
Liste de diffusion du FRsAG http://www.frsag.org/
-
Alexis Lameire -
Manu -
Simon Morvan