> 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.
C'est vrai, mais je voulais gérer l'éventuel cas où l'appareil
n'utiliserait pas mes serveurs DNS : il peut arriver qu'on change le
serveur DNS d'un appareil (pour 8.8.8.8, 9.9.9.9, etc. par exemple) pour
contourner un soucis temporaire et qu'on oublie de revenir à l'ancienne
adresse.
Mais j'avais oublié cette histoire de requête récursivement effectuée
par le résolveur comme l'a souligné jhadba...
Je doute qu'il n'y ait un moyen de dire « voici l'adresse du serveur qui
gère la zone "interne.ma_societe.com" mais n'essaie pas de le contacter,
retourne l'adresse au demandeur (et dit lui de se démerder) »...
Je vais donc faire sauter la configuration côté OVH (ou éventuellement
la laisser avec des valeurs bidon pour faire "placeholder").
> Par ailleurs, l’utilisation du .local est vraiment à
> bannir car il est réservé pour la résolution de noms
> multicast (mDNS/Bonjour/RFC6762) [...]
Oui c'est notamment pour ces raisons que je veux m'en débarrasser.
> Autre point important: DNSSEC. Si vous avez DNSSEC
> d’activé sur votre domaine 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.
C'est un point que j'avais noté de regarder car c'est effectivement le cas.
Merci pour les explications.
--
DUVERGIER Claude
Le 06/09/2021 à 19:19, François Goudal 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
>> <[email protected] <mailto:[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
>> <http://ma_societe.com>", avec une
>> sous-zone pour les résolutions de nom d'appareils internes :
>> "interne.ma_societe.com <http://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
>> <http://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 <http://ma_societe.com>" étant
>> enregistré chez OVH j'ai ajouté
>> les 4 enregistrements suivants dans la zone "ma_societe.com
>> <http://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
>> <http://interne.ma_societe.com>" sur mes
>> serveurs DNS internes :
>>
>> ```
>> zone "interne.ma_societe.com <http://interne.ma_societe.com>." {
>> notify no;
>> type master;
>> file "/var/lib/bind/db.interne.ma_societe.com
>> <http://db.interne.ma_societe.com>";
>> forwarders { 10.0.0.3; };
>> }
>> ```
>>
>> ```
>> $TTL 604800
>> @ IN SOA interne-ns1.ma_societe.com
>> <http://interne-ns1.ma_societe.com>. root.ma_societe.com
>> <http://root.ma_societe.com>. (
>> 2
>> 604800
>> 86400
>> 2419200
>> 604800 )
>> ;
>> IN NS interne-ns1.ma_societe.com
>> <http://interne-ns1.ma_societe.com>.
>> IN NS interne-ns2.ma_societe.com
>> <http://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
>> <http://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
>> <http://interne.ma_societe.com>
>> dig @8.8.8.8 +trace A app-5.interne.ma_societe.com
>> <http://app-5.interne.ma_societe.com>
>> ```
>>
>> échouent par un :
>>
>> ```
>> couldn't get address for 'interne-ns1.ma_societe.com
>> <http://interne-ns1.ma_societe.com>': not found
>> dig: couldn't get address for 'interne-ns1.ma_societe.com
>> <http://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 <http://interne.ma_societe.com>
>> dig @10.0.0.1 A app-5.interne.ma_societe.com
>> <http://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/ <http://www.frnog.org/>
>
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
