Bonjour à tous.
J'ai des problèmes avec une connexion Bouygues. Il semble que la résolution DNS ne fonctionne plus.
Symptôme : pas moyen de se connecter à un site, ou de pinger un serveur par son nom de domaine. Mais j'ai pu pinger 8.8.8.8 (seule adresse IP que je connaissais par coeur, c'est le serveur DNS de Google).
J'ai indiqué 8.8.8.8 comme serveur de DNS dans les propriétés de connexion (dans Network Manager). A partir de là, l'accès internet fonctionne correctement.
L'inconvénient c'est que je n'ai plus accès à l'interface de gestion de la Box (http://gestionbbox.lan) et peut-être plus aux machines du réseau local par leur petit nom (Ça, je suis pas sûr. Et je pourrais le résoudre en tripatouillant les /etc/hosts de mes machines, mais bof…).
En tapant "bouygues bbox problème résolution dns", je vois pas mal de gens qui se plaignent de problèmes similaires. Ça date parfois d'il y a longtemps… Ils se félicitent d'avoir mis les serveurs DNS de Google et comparent les temps de réponse…
Questions :
Ça parle à quelqu'un, ce problème ?
Comment résoudre le problème de l'accès à la config de la Box (qui m'est indispensable pour le routage depuis l'extérieur, notamment accès Raspberry Pi) ?
Vous utilisez les DNS fournis par votre hébergeur ? Des DNS à vous ? Une alternative à Google ? J'ai un dédié sur lequel je pourrais créer un serveur de DNS…
A noter que ça a commencé le jour ou le lendemain du jour où je suis passé en Wi-Fi (je suis loin de la Box et j'ai pas encore passé de câble dans les combles). Mais je vois pas le rapport.
Merci pour vos retours d'expérience.
# Avoir son résolveur local
Posté par Ellendhel (site web personnel) . Évalué à 4.
Je n'ai pas le même genre de problème (même si mon fournisseur d'accès est loin d'être un bon élève en ce qui concerne le service DNS) mais il me semble beaucoup plus intéressant à plusieurs points de vue d'avoir son propre résolveur DNS chez soi.
Dans le cas que tu cites, Unbound pourrait être une bonne solution : cela "répare l'accès à Internet" sans passer par les services de Google (ou autre prestataire de DNS public, qui se fait sûrement une joie de regarder tout ce qui passe) et il est possible de déclarer une liste d'adresses propre à ton réseau local (ce qui est gérable pour une liste assez courte, de manière basique). Cerise sur le gâteau, cela permet aussi de bénéficier de DNSSEC.
BIND permet aussi la même chose, mais est un peu plus complexe à mettre en œuvre. D'autres logiciels existent dans la même catégorie (dnsmasq par exemple, que je ne connais pas).
Un résolveur DNS local pourra être utilisé par tout autre machine sur le réseau local (avec les bonnes directives de configuration pour en autoriser l'accès). L'idéal étant d'avoir le service installé sur une machine disponible en permanence afin de pouvoir disposer d'un meilleur cache.
[^] # Re: Avoir son résolveur local
Posté par jihele . Évalué à 2.
Merci pour ces pistes. Pour l'instant je n'ai pas de machine allumée en permanence mais je l'envisage à terme pour des sauvegardes, donc je garde ça de côté.
(Mon RPi est connecté en Wi-Fi parce que la foudre a flingué une ancienne Box et le port Ethernet du RPi. La connexion Wi-Fi étant ce qu'elle est, je préfère éviter de m'en servir de solveur DNS. Je pourrais le mettre seulement en primaire. Mais même, niveau latence et tout…)
# un classique
Posté par Salk . Évalué à 2.
Normalement, les conseils donnés ici :
https://lafibre.info/bbox-tutoriels/les-dns-primaire-et-secondaire-de-la-bbox/
résolvent à peu près tous les problèmes
[^] # Re: un classique
Posté par jihele . Évalué à 2.
Oui, j'avais vu ce message.
Je pense opter pour la solution 1 (serveurs DNS officiels Bouygues, mais pas ceux de la Box).
Si je perds pas la possibilité d'appeler les machines par leur hostname, c'est cool.
La question que je me pose reste "mais comment peut-on en arriver là ?". Comment fait Mme Michu avec son internet ? Comment peut-on avoir encore des bugs du relais DNS de la BBox 4 ans après ce message ?! J'imagine qu'elle sait se mettre à jour toute seule via le réseau.
Et comment se fait-il que j'aie jamais eu le problème en 4 ans ? Est-ce consécutif au déménagement ? Au passage au Wifi sur une machine Linux (je vois pas pourquoi, mais les clés Wi-Fi sous Linux, chez moi, c'est le petit pont de bois, quand ça tient, on ose pas souffler dessus) ?
Et comment se fait-il que ça fonctionne au même moment avec le mobile Android branché en Wi-Fi ? Il utilise d'autres DNS ? Il se rabat sur les DNS de la connexion 3G ?
Ça en fait, des questions…
[^] # Re: un classique
Posté par jihele . Évalué à 2.
Bon apparemment, je peux plus appeler mes machines par leur hostname :
ping raspberrypi
ping 192.168.1.1
[^] # Re: un classique
Posté par Chris K. . Évalué à 1. Dernière modification le 30 septembre 2014 à 14:22.
Oui c'est normal ça n'est pas magique :)
Il faut permettre à la résolution de noms de faire la liaison entre un nom de machine et une adresse IP.
Grosso modo tu as le choix entre :
- Une déclaration dns fixe avec ip fixe (très facile)
- L'installation d'un daemon mdns (très facile aussi mais un peu moins fiable)
- Un DNS dynamique mis à jour par dhcp (doc : http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/ moins facile mais très efficace)
- Une résolution de nom Wins (ca marche pour les windows et machines équipées de samba, mais ce n'est pas le système le plus fiable non plus)
[^] # Re: un classique
Posté par jihele . Évalué à 2.
J'étais pas sûr que la résolution des hostnames soit faite au même niveau, mais c'était un défaut de compréhension de ma part. (Je me disais que dans un premier temps le routeur pourrait tenter de faire le lien hostname -> IP locale, et ensuite, si le nom n'existe pas localement, alors il est externe et le routeur fait la résolution DNS, mais ça tient pas vu que c'est sur le PC client qu'on appelle directement le serveur DNS. Bref. En y réfléchissant tranquillement, c'est logique que c'était pas possible, ce que je craignais.)
J'ai le sentiment que les solutions que tu proposes impliquent une machine branchée en permanence. Ou alors j'ai regardé trop vite.
A priori, tous les machines du réseau sont Linux, donc pas de solution Windows/Samba.
C'est possible que par simplicité je laisse les DNS de Bouygues et me contente d'ajouter les IP de chaque machine dans le /etc/hosts des autres. Et je vais configurer le routeur pour attribuer des IPs faciles à retenir :
*.*.*.1, *.*.*.2, etc.
[^] # Re: un classique
Posté par Chris K. . Évalué à 2.
Oui c'est une solution simple qui fonctionne bien.
Sans machine qui tourne en permanence la solution mdns peut faire l'affaire :)
[^] # Re: un classique
Posté par jihele . Évalué à 2.
Si je comprends bien, ça permettrait aux machines sur le réseau local de se reconnaître entre elles si elles font toutes tourner ce démon. Donc ça ne remplace pas la configuration de serveurs DNS pour parler au reste du monde, c'est complémentaire.
[^] # Re: un classique
Posté par Chris K. . Évalué à 2.
Toutafai :)
Si tu lis l'anglais la page en de wikipedia explique très bien cela.
http://en.wikipedia.org/wiki/Multicast_DNS
[^] # Re: un classique
Posté par jihele . Évalué à 2.
C'était là que j'avais regardé, en effet.
[^] # Re: un classique
Posté par benoar . Évalué à 3.
Toutes les distros modernent l'incluent par défaut, et configurent les machines avec le nom que tu leur donne lors de l'installation. Normalement, tu te connecte à « le_nom_de_ma_machine.local » (note le .local à la fin) et ça roule, pas la peine de faire plus.
[^] # Re: un classique
Posté par Chris K. . Évalué à 2. Dernière modification le 30 septembre 2014 à 16:54.
Comment ca TOUTES les distros modernes !? :D … Debian ne l'inclus pas dans l'installation minimale… et au passage tant mieux car ce genre de service qui multicast a tout va sur un réseau pro avec du monde dessus c'est pas forcément très adapté.
Sinon pour éviter d'avoir à mettre à chaque fois .local il peut aussi l'ajouter en suffixe de recherche dans resolv.conf et c'est réglé.
[^] # Re: un classique
Posté par benoar . Évalué à 2.
Bah, dans l'install « standard », il y est, en tous cas.
[^] # Re: un classique
Posté par Chris K. . Évalué à 1. Dernière modification le 30 septembre 2014 à 19:48.
Eh bien ça fait un petit moment que je n'ai pas utilisé l'installation standard pour être honnête mais je te crois.
Debian serait donc une distribution moderne ! \o/.
PS: Va falloir que je me note ça dans un coin pour penser à le virer le jour où :)
[^] # Re: un classique
Posté par benoar . Évalué à 2.
Pour préciser, je parle d'une install « bureau » standard. Il ne doit pas y être pour une install avec aucune tâche dans tasksel (genre pour un serveur). Même si perso, c'est un des premiers trucs que j'installe sur un serveur, pour faciliter l'accès au serveur en question.
Bien sûr !
Si tu n'aimes pas le multicast pour faire « pro », tu ne va pas beaucoup aimer les technologies « modernes » comme IPv6, par exemple…
[^] # Re: un classique
Posté par Chris K. . Évalué à 1.
Euh je n'ai rien contre la modernité ni contre IPv6.
Je t'invites à relire la première ligne de l'article wikipédia : "The purpose of the multicast Domain Name System (mDNS) is to resolve host names to IP addresses within small networks that do not include a local name server."
Avoir des services inutiles qui causent sur tous les postes vers tous les autres et qui pourraient entrer en conflit avec les vrais services - au hasard - le DNS de l'active directory vu que nos domaines finissent avec le tld .local… non je vois pas du tout l’intérêt. Maintenant chacun fait bien ce qu'il veut.
Et ça ne m'empêche pas de trouver ça bien pour un réseau domestique.
[^] # Re: un classique
Posté par benoar . Évalué à 2.
Tu parlais de ton inquiétude vis à vis des services qui « multicastent à tout va » : le NDP d'IPv6 est assez bavard, à juste titre.
Ah, ça y est, on sent le penchant despotique de l'admin qui sait mieux que tout le monde ce que les gens veulent.
Ah bah c'est dommage d'avoir choisi ce tld, qui est maintenant officiellement réservé pour mDNS. Je vois sur la page WP que ça a été recommandé à une époque par MS… beau cafouillage, comme d'hab pour eux. Mais tu peux configurer ton nsswitch pour qu'il interroge ton DNS avant de tester mDNS si tu veux.
Oui, mais pas que : ça permet d'être plus pratique aussi pour faire des choses que l'admin rechigne parfois à faire.
[^] # Re: un classique
Posté par Chris K. . Évalué à 1. Dernière modification le 05 octobre 2014 à 10:38.
Celui qui sait mieux que tout le monde… comment dire ce n'est pas moi qui suis en train de t'expliquer comment gérer ton réseau, ou quels sont les besoins de tes utilisateurs en ce moment.
Sinon tous les jours des gens se pendent devant mon bureau car il n'y a pas de mDNS, ce qui ne cesse de m'étonner vu qu'ils n'ont toujours aucune idée de ce que c'est.
Si j'avais que ça a faire ça pourrait m'amuser effectivement.
Et toi tu confonds tout : NDP n'est pas un service, il ne se situe pas du tout dans la même couche que mDNS et ce n'est pas une option. Autant disserter sur les véritables qualités d'ARP ca va bien nous avancer.
Oui c'est triste mais c'est la vie et il faut continuer a avancer malgré tout.
[^] # Re: un classique
Posté par benoar . Évalué à 3.
Autant le reste de ma critique était plutôt légère et pour troller, autant il y a un bout auquel je voudrais répondre sérieusement :
Je trouve que le manque de déploiement et de connaissance à propos de mDNS est un très gros handicap pour le réseau en général, et un des plus gros freins à IPv6 : les gens continuent, quand ils ont besoin d'accéder aux machines locales, à utiliser des IP(v4). Ou alors, quand ils ont Windows, le gestionnaire de nom de SMB (dont j'ai oublié le nom), qui a un fonctionnement encore pire que mDNS (d'ailleurs, tu ne t'en pleins pas ?). On aurait un mDNS qui marche partout et plus de vulgarisation de ce protocole, tout le monde pourrait utiliser des noms au lieu des adresses, et le monde irait mieux (ainsi qu'IPv6). C'est un problème que je trouve très sérieux. Et c'est pour ça entre autres que je continue à répondre à ce fil.
[^] # Re: un classique
Posté par Chris K. . Évalué à 2. Dernière modification le 07 octobre 2014 à 07:18.
En fait on utilise le module pour bind9 et non le service DNS intégré à samba.
Je n'ai pas de soucis particuliers avec l'association des ip avec les noms de machines, les postes s'intègrent bien dans le DNS (c'est d'ailleurs tout l'intérêt de ce module).
D'ailleurs, dans un contexte sans AD, tu peux configurer un serveur DHCP pour mettre à jour les IPs des machines dans bind automatiquement lorsqu'elle lui attribue une ip et ainsi avoir un lien constant et fiable entre le nom du poste et son IP. Ça reste plus contraignant qu'avec l'AD ou tout est automatique on est d'accord.
Maintenant vu la description que tu en fais je pense que tu parles de WINS qui est effectivement une grosse plaie pas fiable pour un sous.
Si tu restes sur un seul subnet ça fonctionne déjà pas très bien mais une fois que tu relies des sites distants par IPSEC c'est une vraie cata : même si tu configures les serveurs WINS dans DHCP et que tu les informes qu'ils doivent se mettre a jour mutuellement entre les subnets.
C'est clair que sans liaison nom d'hôte / ip fonctionnel on ne risque pas de vouloir passer sur IPv6. Je comprends mieux maintenant où tu voulais en venir ^^.
[^] # Re: un classique
Posté par benoar . Évalué à 2.
OK, donc ça c'est quand tu as une bonne gestion centralisée faite par un admin compétent. Malheureusement, ça n'est pas forcément disponible partout.
Tu parles du DDNS je suppose ; c'est effectivement une alternative faisable, et plus simple qu'un AD je trouve car c'est à peu près intérgré de base dans l'ISC DHCP je crois (genre une option à activer). Mais ça reste un truc central qu'il faut qu'un admin mette en place.
Oui, c'est ça, WINS, merci. L'avantage de WINS sur un AD ou un DHCP+DNS administré, c'est que c'est décentralisé : pas besoin d'un admin pour gérer tout ça. Après, le protocole laisse quand même à désirer, et mDNS est beaucoup mieux fait tout en restant décentralisé.
C'est l'avantage de mDNS (et DNS-SD) : localement ça marche sans rien faire, et il « suffit » d'un relai mDNS entre les deux pour étendre le service à des subnets différents. J'utilise ça à la maison sur un routeur vraiment cheap (avec OpenWrt), et ça marche du tonnerre (OK, ça n'est pas vraiment un déploiement immense…). C'est pas mal décentralisé, contrairement à un AD/DHCP, et ça marche sans administration (i.e. j'ai installé le truc sur la machine, sans configuration, et je n'y ai jamais touché ; il n'a aucun état à stocker, c'est juste un relai stateless de trames multicast).
Oui, c'est quelque chose qui est poussé mais de manière assez indirecte à l'IETF : pour faciliter la transition, il faudrait que les softs soient bien codés et utilisent getaddrinfo() afin de s'abstraire de la notation des noms/adressent, et que le service de DNS marche bien partout (et à la maison, endroit où il n'y a pas d'admin local en général, il faut que ça marche tout seul). D'où mDNS pour palier ce second problème.
[^] # Re: un classique
Posté par Chris K. . Évalué à 1. Dernière modification le 07 octobre 2014 à 14:13.
Oui malheureusement et je sais aussi que ça peut être frustrant quand tu as à faire avec d'autres personnes qui font de la merde.
Notre démarche quand on désactive quelque chose est d'essayer d'avoir la meilleure vision possible sur les sources potentielles de problèmes en n'ayant que le minimum de services redondants à maintenir.
Ce genre d'économies ne doit pas se faire au détriment des fonctionnalités, du confort ou de la qualité du service rendu à l'utilisateur, on est bien d'accord.
Je suis pas là pour jouer le BOFH, bien au contraire.
Oui tout à fait.
Maintenant avec samba 4 et ses outils de déploiement et d'admin très bien faits la configuration avec l'AD est hyper simple : quelques lignes dans la conf de bind pour appeler le module et ça roule tout seul.
D'ailleurs aujourd'hui tu es obligé de passer par là pour un contrôleur de domaine samba. Donc quand tu as un AD tu as la fonctionnalité avec :)
Bien entendu il faut avoir le besoin d'avoir un AD à la base et ce n'est pas le cas partout.
C'est clair que comparé à WINS ça fonctionne vraiment beaucoup mieux il n'y a même pas photo.
WINS est un dinosaure avec une logique un peu hybride : il procède a une élection d'un maître local pour désigner la machine qui va servir de serveur, c'est assez dégueulasse et il est courant de se retrouver avec des machines déconnecté visible ou l'inverse.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.