Bonjour, La requête de récursion s'adresse aux serveurs resolveurs de Google (8.8.8.8). Les enregistrements A correspondant aux NS interne-ns[1,2] dans la zone ma_societe.com sont une glue record, elle permet de poursuivre la recursion mais par définition ma_societe.com ne fait pas autorité sur interne.ma_societe.com. Le résolveur Google poursuit la recursion en continuant vers les NS de interne.ma_societe.com qui est en adressage privé et ça ne marche pas.
La solution est dans le message précédent. Aucun paramétrage nécessaire sur la zone OVH, il faut soit : - déclarer la zone sur les DNS internes de l'entreprise. Les serveurs seront alors résolveur et serveur faisant autorité - créer une règle de forward depuis les resolveurs vers les serveurs faisant autorité sur interne.ma_societe.com. Et là, on rentre dans le débat : peut-on se permettre de mixer les fonctions resolveur et serveur faisant autorité... Cordialement, Le 6 septembre 2021 19:19:34 GMT+02:00, "François Goudal via frnog" <frnog@frnog.org> a écrit : >Bonjour, > >Si vos DNS bind9 sont déjà les serveurs DNS qui répondent aux machines sur >votre réseau local, alors vous n’avez strictement rien a faire du côté OVH. > >Il faut simplement déclarer une zone interne.ma_societe.com ><http://interne.ma_societe.com/> sur vos serveurs bind. Ainsi, lorsque vos >machines sur le réseau vont interroger vos bind pour résoudre >something.interne.ma_societe.com <http://something.interne.ma_societe.com/> >ils vont pouvoir répondre directement avec une adresse locale. Et si ils >veulent répondre a www.ma_societe.com <http://www.ma_societe.com/> ils vont >faire une récursion comme pour n’importe quel autre domaine, et remonter >jusqu’aux root servers si besoin. > >Par ailleurs, l’utilisation du .local est vraiment à bannir car il est réservé >pour la résolution de noms multicast (mDNS/Bonjour/RFC6762). Si vous avez des >équipements sur le réseau qui supportent mDNS et qui cherchent à résoudre des >trucs en .local, ils ne vont pas faire une requête DNS classique vers les >serveurs DNS qu’ils sont censé interroger, mais au lieu de cela, balancer une >requête en multicast sur le réseau et écouter voir si quelqu’un répond. >Autrement dit, c’est une source de problème, en particulier si vous avez du >matériel Apple entre autres car ils supportent nativement le mDNS depuis très >longtemps (puisque c’est eux qui en sont à l’origine, en fait). > >Autre point important: DNSSEC. Si vous avez DNSSEC d’activé sur votre domaine >ma_societe.com <http://ma_societe.com/> alors ce que vous cherchez à faire ne >pourra pas fonctionner, à moins de faire le nécessaire en mettant en place les >clés qui vont bien. Donc au moins dans un premier temps, pensez a désactiver >DNSSEC si ce n’est pas déjà le cas. > > >> On 6 Sep 2021, at 18:30, DUVERGIER Claude <frnog...@claude.duvergier.fr> >> wrote: >> >> TL;DR: J'ai déclaré une sous-zone DNS chez OVH pour la gérer en interne >> et `dig` me réponds "not found" / "no more" >> >> >> Bonjour la liste, >> >> Après avoir utilisé le nom de domaine "ma_societe.local" en LAN/interne >> (via un bind9 hébergé en local et utilisés par les postes du LAN) >> pendant des années, vient le temps de corriger cette erreur de jeunesse... >> >> J'aimerais donc utiliser le nom de domaine "ma_societe.com", avec une >> sous-zone pour les résolutions de nom d'appareils internes : >> "interne.ma_societe.com" >> Elle serait gérée par mes serveurs DNS bind9 en local (d'IP 10.0.0.1 et >> 10.0.0.2). >> >> Ainsi j'utiliserai un vrai nom de domaine valide tout en conservant la >> main sur les enregistrements internes qui n'ont pas vocation à être >> connus du public. >> >> Bien entendu, une résolution de foo.interne.ma_societe.com ne devrait >> fonctionner que depuis le réseau local (ou via VPN). >> >> Ma première question est donc : ais-je bien choisit la bonne solution >> technique pour éviter d'avoir un .local (ou .lan, etc.) à l'avenir peu >> certain tout en ayant une zone bien à moi. >> >> Il me semblait avoir vu passer une discussion similaire mais je ne >> trouve rien dans les archives de la liste. >> >> Ensuite, pour la mise en œuvre, j'ai fait comme suit : >> >> Le nom de domaine "ma_societe.com" étant enregistré chez OVH j'ai ajouté >> les 4 enregistrements suivants dans la zone "ma_societe.com" via le >> Manager d'OVH : >> >> ``` >> interne IN NS interne-ns1 >> interne IN NS interne-ns2 >> interne-ns1 IN A 10.0.0.1 >> interne-ns2 IN A 10.0.0.2 >> ``` >> >> Et j'ai rajouté un fichier de zone pour "interne.ma_societe.com" sur mes >> serveurs DNS internes : >> >> ``` >> zone "interne.ma_societe.com." { >> notify no; >> type master; >> file "/var/lib/bind/db.interne.ma_societe.com"; >> forwarders { 10.0.0.3; }; >> } >> ``` >> >> ``` >> $TTL 604800 >> @ IN SOA interne-ns1.ma_societe.com. root.ma_societe.com. ( >> 2 >> 604800 >> 86400 >> 2419200 >> 604800 ) >> ; >> IN NS interne-ns1.ma_societe.com. >> IN NS interne-ns2.ma_societe.com. >> routeur-4 IN A 10.0.1.4 >> app-5 IN A 10.0.1.5 >> ``` >> >> Après propagation, un : >> >> ``` >> dig @8.8.8.8 A interne-ns1.ma_societe.com >> ``` >> >> me retourne bien "10.0.0.1", ça c'est donc OK. >> >> Mais la couche d'après ne fonctionne pas, car des : >> >> ``` >> dig @8.8.8.8 +trace NS interne.ma_societe.com >> dig @8.8.8.8 +trace A app-5.interne.ma_societe.com >> ``` >> >> échouent par un : >> >> ``` >> couldn't get address for 'interne-ns1.ma_societe.com': not found >> dig: couldn't get address for 'interne-ns1.ma_societe.com': no more >> ``` >> >> (enlever `+trace` ne permet pas d'avoir une meilleure réponse) >> >> Je ne vois rien dans le `dig +trace` qui montre qu'il essaie de >> contacter mes serveurs DNS (et leurs logs le confirme). >> >> Et interroger directement le serveur DNS interne fonctionne : >> >> ``` >> dig @10.0.0.1 NS interne.ma_societe.com >> dig @10.0.0.1 A app-5.interne.ma_societe.com >> ``` >> ``` >> >> Qu'ais-je oublié de faire côté OVH ? >> >> -- >> DUVERGIER Claude >> >> >> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > >--------------------------- >Liste de diffusion du FRnOG >http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
