Je pensais le savoir mais il me semble que je vais résorber quelques lacunes grâce à vous.
Pas encore beaucoup mais une fois le concept assimilé, je réfléchirais à améliorer les services proposé aux collaborateurs de mon entreprise.
Je ne connais pas du tout nis. Est ce que cela ne limite pas à l’utilisation sur un réseau UNIX?
La solution des fichiers hosts me semble un peu trop statique. Si un utilisateur doit changer de machine pendant mes vacances, je ne souhaite pas devoir faire l’aller retour.
Cela ne nous avance guère.
Dans le premier message
et maintenant
Faudrait savoir ! C’est bien d’apprendre, mais dans le cadre d’une entreprise il y a souvent déjà un mécanisme en place pour gérer le réseau. (DHCP, du ldap, Active Directory, que sais-je ) La version 3.11 du noyau, Linux for workgroups, c’était il y a quelque temps.
Il n’y a pas que nis comme solution.
aptitude search libnss | fgrep -v libnss3 | less
pas moins de 42 paquets dans stretch.
Au départ oui. Comme disait Coluche : c’était la zone, pas un troquet, pas une mobylette, rien.
Même dans le schéma LDAP de l’Active Directory, il y a une possibilité d’intégrer des tables nis.
Mon message était pour vous ouvrir les yeux et vous faire sortir de l’impasse : résolution de noms de machines == serveur DNS.
Je ne vois pas le rapport. Si l’administrateur réseau est incompétent au point de ne pas avoir prévu ce cas de figure si prévisible, c’est son problème.
Avant de passer tout de suite à des concepts branchés, 2.0 (auto-hébergement, …) (auxquels je ne connais rien de rien), il n’est pas inutile de revenir aux fondamentaux, comme le disait si bien Bernard Laporte (on ne passe pas directement à Ovalie 2.0 )
Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة
F. Petitjean
Ingénieur civil du Génie Maritime.
« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français
« Un ordinateur c’est comme un frigo : on le branche et ça marche. »
Laurent Serano Directeur informatique, réunion Délégués du Personnel 2010
C’est bien pour cela que je commence sur une petite structure. Il est important d’appréhender le système et essayer d’en dégager les points fort et les faiblesses. Ce n’est pas grave de commencer à zéro puisqu’il faut bien commencer de quelque part.
Autant se lancer dans un projet quitte a se prendre quelques baffes mais avancer. Ici, très peu de gens seront impacter par mes essais/erreurs. Et après, voir plus grand… une fois mes outils aiguisés…
L’installation d’un dns était la méthode qui me semblait la plus simple et la plus flexible. Restait a comprendre comment la configurer…
Maintenant, il me reste à étudier les concept que nous avons abordé et les comprendre afin de réévaluer mes choix.
Ça, c’est faux. Un domaine public est toujours servi par plusieurs serveurs DNS faisant autorité, pour la redondance et la répartition de charge. Exemple :
$ host -t ns debian-fr.org
debian-fr.org name server dns102.ovh.net.
debian-fr.org name server ns102.ovh.net.
Mais ça n’a rien à voir avec les serveurs DNS dont les adresses sont enregistrées dans resolv.conf. Ces serveurs-là ne sont généralement pas des serveurs faisant autorité mais des serveurs récursifs qui savent interroger d’autres serveurs récursifs ou faisant autorité pour trouver les réponses aux requêtes qu’ils reçoivent. Parfois le serveur peut faire autorité pour des domaines locaux (publics ou privés) et être récursif pour le reste. Si le premier serveur DNS interrogé (qui n’est pas forcément le premier de la liste, ça dépend des options) renvoie une réponse négative (distincte d’une erreur), alors le client considère cette réponse comme définitive et ne va pas interroger un autre serveur.
Je crois qu’on s’égare en parlant de split DNS ou de NIS. Si on reprenait au début ?
@Waldorf a acheté un domaine public. Il est servi par des serveurs DNS faisant autorité pour sa zone. Où et que sont ces serveurs ? Est-ce que ce sont ceux du bureau d’enregistrement (registrar) où le nom de domaine a été acheté, à savoir OVH ? Ou bien est-ce qu’un ou plusieurs des serveurs DNS du réseau local mentionné ici en font partie (pour cela ils doivent disposer d’une adresse IP publique fixe et être joignables de partout) ? Est-ce que l’objectif à terme est de changer cela ? Par exemple de transférer la délégation de la zone des serveurs d’OVH vers tes propres serveurs DNS ?
Et donc je repose ma question à laquelle @Waldorf n’a pas répondu :
L’un renvoie l’adresse IP publique, l’autre ne renvoie rien. Lequel est BIND, lequel est celui de la box ?
Il n’y a qu’un serveur faisant autorité pour ce domaine (abus de langage de ma part, certes). Les autres ne sont que des serveurs esclaves assurant la redondances des données.
Je reformule donc :
On ne peut pas avoir plusieurs serveur maîtres faisant autorité pour un domaine donné.
Non. Ce que tu décris n’est pas le un serveur d’autorité, mais un serveur maître.
Un serveur faisant autorité comme le dit pascal fait parti d’un groupe qui peut affirmer: je suis officiellement l’autorité pour te répondre concernant cette zone, je n’ai pas besoin de demander ailleurs.
Ce que tu décris en maitre/esclave, c’est ce qui se passe sous le capot pour synchroniser la gestion des zones entre les serveurs d’autorité (ou non). Je crois que tinydns/djbdns fonctionne en pair à pair, par exemple, pour synchroniser les serveurs, et qu’il n’y a pas un maître qui exporte toute une zone, mais des modifications sur la zone sur n’importe quel serveur qui se propagent sur les pairs. Mais je peux me tromper, je n’ai fait que survoler le principe en lisant wikipedia une fois.
Et c’est encore faux. Le fonctionnement en maître/esclave n’est qu’un mécanisme de synchronisation des serveurs faisant autorité pour une zone possible parmi d’autres.
Les serveurs peuvent être indépendants les uns des autres (et sont donc techniquement tous maîtres) et se baser sur une source de données commune (base de données ou simple fichier de zone déposé par un mécanisme externe au DNS par exemple). On peut aussi envisager un fonctionnement en pair à pair comme l’a décrit @mattotop, où tous les serveurs sont tous égaux, à la fois maîtres et esclaves, et se synchronisent sur celui qui a la version de la zone la plus récente.
@PascalHambourg: tu as raison. En voulant simplifier j’ai dit une ânerie.
Ceci dit quelque soit le mode de fonctionnement les serveurs doivent fournir des réponses cohérentes.
Ce que je voulais expliquer @Waldorf, c’est qu’il ne peut pas avoir un serveur faisant autorité sur example.com contenant des enregistrement avec des IP publiques (celui de son hébergeur) et un serveur local fournissant les mêmes enregistrements avec des IP privées, sauf à faire du split DNS.
Si, c’est possible, et pas besoin de split DNS pour cela. Par contre il faut que les machines du réseau local interrogent le serveur DNS local qui sert la version privée de la zone ou un serveur récursif qui fait suivre les requêtes pour la zone vers celui-ci. Donc pas le serveur DNS de la box ou du FAI.
Oui mais dans ce cas les noms seront uniquement résolus en adresses privées. À moins que le serveur local ne réplique la zone de l’autre serveur qui fournit les IP publiques (ce qui me paraît problématique).
Pourquoi uniquement ? Qu’est-ce qui empêche le serveur local de renvoyer des adresses publiques ?
Je n’ai pas dit que c’était pratique. Comme il n’y a pas de mécanisme de synchronisation automatique entre les deux serveurs, il faut faire évoluer leurs versions de la zone de façon concordante manuellement. Note que même avec du “split DNS” sur un même serveur, ce serait la même chose.
1000 excuses mais je n’ai pu lire votre reponse avant ce jour.
Je souhaiterais atteindre mon domaine de partout afin de profiter de service (notament un agenda partage avec ma compagne) je souhaiterais donc retrouver le chemin vers agenda.mondomaine.ext que je sois dans mon reseau local ou dans le reste du monde. Je n’imagine pas demander a ma compagne de devoir reflechir a l’endroit ou elle est pour se connecter a l’agenda.
Maintenant est ce que ma reflexion est bonne? Visiblement le fait de demander l’adresse: agenda.mondomaine.ext de partout me ramene vers ma box, et donc a suivre la deviation de port mis en place. Chose que vous m’avez affirme mais que je n’ai pas encore teste… Oui, je sais… Saint Thomas aurait pu etre mon deuxieme prenom…
Je vois que ta molette pour remonter lire semble en panne, donc voilà:
Oui, si tu fais une config qui marche de partout, elle fonctionera pareil pour les machines à l’intérieur de ton réseau.
Maintenant que l’on comprend un peu mieux ta préoccupation, je le répète:
tu n’as absolument aucun besoin de te préoccuper de ce que tu donnes aux machines internes de ton réseau comme résolution sur tes services extérieurs, ils utiliseront la même config qu’un client exterieur, à ceci pret que leur communications, même si elles ne vont pas direct d’eux au serveur, fera un rapide passage par ta box, mais sans passer par le net.
Attention, la redirection interne ne fonctionne pas (en tout cas n’a pas toujours fonctionné) avec toutes les box, toutes les versions de firmware… Le seul moyen de savoir, c’est d’essayer.
Ben si il “pinhole” l’un ou l’autre des services sur la box pour le rediriger le port externe sur le serveur (ou s’il met le serveur en dmz parce qu’il en a deux belles), quand ça marchera et que les machines internes voudront attaquer l’ip externe de la box pour atteindre le serveur, pourquoi veux tu qu’elles soient traitées différemment d’une machine extérieure et que la box refuse la redirection ?
Ca m’étonne, ce que tu dis.
Aprés, si tu veux dire que le pinhole ou la déclaration du serveur en dmz ne sont pas toujours possible sur un routeur/box, ça OK, mais c’est toute la solution pour mettre en place le serveur interne qui sera impossible, pas juste la connection des machines internes.
Je ne voudrais pas pignoler (mauvais jeu de mot), mais qu’entends-tu par “pinhole” ?
Pour deux raisons possibles : leur adresse source interne et leur interface d’entrée.
Si la règle de redirection de la box ne s’applique qu’aux paquets reçus par l’interface externe de celle-ci, les paquets envoyés par les postes du réseau interne ne seront pas redirigés. Pour que ça fonctionne, il faut que la box base sa redirection non pas sur l’interface d’entrée mais sur l’adresse de destination originelle (adresse externe de la box), ce qui est plus compliqué car la règle doit être dynamiquement gérée en fonction de l’adresse en question.
Si les paquets redirigés par la box arrivent au serveur avec l’adresse source originale du client local, le serveur va répondre directement au client sans repasser pas le routage de la box puisqu’ils sont dans le même réseau ; le client va voir arriver un paquet provenant de l’adresse interne du serveur alors qu’il a envoyé un paquet à l’adresse externe de la box et ne va pas l’accepter comme une réponse. Cas classique de routage asymétrique qui met le NAT symétrique en échec. Pour que ça fonctionne, la box doit donc, pour ces paquets, modifier aussi l’adresse source originelle (la remplacer par la sienne, NAT source, comme pour les connexions sortantes vers l’extérieur) avant de les renvoyer vers le serveur. Il ne faut pas le faire sur tous les paquets sinon l’adresse source réelle des paquets provenant de l’extérieur serait masquée au serveur.
J’aurais prefere que cela fut si simple mais malheureusement, si ma souris va bien, merci pour elle, mon cerveau fatigue ne semble pas bien voir la difference entre les deux…
OK. Je n’ai jamais rencontré le truc, ni 1 ni 2, et je pensais que le 1 n’était pas un problème, justement parce qu’en visant l’ip externe, ils atteignaient forcément l’interface externe, mais en fait, ils n’y entrent pas.
