Cette récursivité est un point que j'avais totalement oublié... Comme expliqué dans mon précédent message je voulais en mettre un maximum dans la zone publique pour être le plus carré possible et gérer des les appareils qui n'utilisent pas nos resolveurs internes.
J'utilise 2 serveurs DNS différents pour l'autorité et la résolution donc un petit forward vers l'autorité sur le résolveur résous bien le problème. Merci pour les explications. -- DUVERGIER Claude Le 06/09/2021 à 21:32, [email protected] a écrit : > Bonjour, > > La requête de recursion 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 resolveur 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 resolveurs et serveurs faisant autorité > - créer une règle de forward depuis les resolveurs vers les serveurs > faisant autorité sur interne.mas-societe.com. > > Et là, on rentre dans le débat : peut-on se permettre de mixer les > fonctions resolveur et serveur faisant autorité ou bien y-a-t-il des > exceptions dans les cas simple ? Je ne sais pas. > > Cordialement, > > > On Monday, September 06, 2021 19:19 CEST, François Goudal via frnog > <[email protected]> wrote: > >> 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 >> <[email protected]> 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/
