Re: [FRnOG] [TECH] Sous-zone DNS dédiée réseau interne via zone DNS gérée par tiers (eg. OVH)

2021-09-06 Par sujet list 
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" 
 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 
> sur vos serveurs bind. Ainsi, lorsque vos 
>machines sur le réseau vont interroger vos bind pour résoudre 
>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  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  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  
>> 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 :
>> 
>> ```
>> interneIN NS interne-ns1
>> interneIN NS interne-ns2
>> interne-ns1IN  A 10.0.0.1
>> interne-ns2IN  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; };
>> }
>> ```
>> 
>> ```
>> $TTL604800
>> @ IN SOA interne-ns1.ma_societe.com. root.ma_societe.com. (
>>  2
>> 604800
>>  86400
>>2419200
>> 604800 )
>> ;
>> IN NS

Re: [FRnOG] [TECH] Sous-zone DNS dédiée réseau interne via zone DNS gérée par tiers (eg. OVH)

2021-09-06 Par sujet François Goudal via frnog 
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 
 sur vos serveurs bind. Ainsi, lorsque vos 
machines sur le réseau vont interroger vos bind pour résoudre 
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  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  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  
> 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 :
> 
> ```
> interneIN NS interne-ns1
> interneIN NS interne-ns2
> interne-ns1IN  A 10.0.0.1
> interne-ns2IN  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; };
> }
> ```
> 
> ```
> $TTL604800
> @ IN SOA interne-ns1.ma_societe.com. root.ma_societe.com. (
>  2
> 604800
>  86400
>2419200
> 604800 )
> ;
> IN NSinterne-ns1.ma_societe.com.
> IN NSinterne-ns2.ma_societe.com.
> routeur-4IN  A10.0.1.4
> app-5IN  A10.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

[FRnOG] [TECH] Sous-zone DNS dédiée réseau interne via zone DNS gérée par tiers (eg. OVH)

2021-09-06 Par sujet DUVERGIER Claude 
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 :

```
interneIN NS interne-ns1
interneIN NS interne-ns2
interne-ns1IN  A 10.0.0.1
interne-ns2IN  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; };
}
```

```
$TTL604800
@ IN SOA interne-ns1.ma_societe.com. root.ma_societe.com. (
  2
 604800
  86400
2419200
 604800 )
;
 IN NSinterne-ns1.ma_societe.com.
 IN NSinterne-ns2.ma_societe.com.
routeur-4IN  A10.0.1.4
app-5IN  A10.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/

RE: [FRnOG] RE: [TECH] ATS + UPS = cdhsjkezlkezllksq

2021-09-06 Par sujet Michel Py via frnog 
> Vincent Duvernet a écrit :
> Ce qui laisserait supputer que c'est pour les entreprises plus petites mais 
> dans ces
> entreprises, personne (du moins dans nos clients) n'a 2 alimentations EDF 
> distinctes.

C'est clair, et même quand c'est le cas c'est extrêmement rare que ça soit deux 
sources de haute tension différentes.
A $job[-1] ou on était de très grands consommateurs d'électricité ($1M par 
mois) on avait deux "sub-stations" différentes, une de chaque coté du campus à 
plusieurs centaines de mètres l'une de l'autre, mais c'était la même source de 
haute tension donc au final la même alimentation,

> Alors que cela induit que l'ATS ne puisse être connecté qu'à 1 seul onduleur 
> sur une
> source et sur l'EDF normal sur l'autre source ou bien est "autant-pire" ?

C'est carrément pire, AMHA. J'ai expliqué récemment en détail pourquoi.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] RE: [TECH] ATS + UPS = cdhsjkezlkezllksq

2021-09-06 Par sujet Vincent Duvernet 
Yop,

Lorsqu'ils parlent de même circuit d'entrée, c'est jusqu'où ? Disjoncteur, 
différentiel, compteur d'abonné ?
Car en fonction de la réponse, on ne peut pas adresser le même type de client 
non ?
Parce que, en DC, je vois mal du monophasé 10A avec des prises C13/C14. Ce qui 
laisserait supputer que c'est pour les entreprises plus petites mais dans ces 
entreprises, personne (du moins dans nos clients) n'a 2 alimentations EDF 
distinctes.
Alors que cela induit que l'ATS ne puisse être connecté qu'à 1 seul onduleur 
sur une source et sur l'EDF normal sur l'autre source ou bien est "autant-pire" 
?

Je poserai bien la question à mon av-vente APC mais bon, c'est un commercial, 
du coup, l'objectivité ne sera pas au rdv, je préfère les feedbacks de ceux qui 
ont mis les mains dedans et même jusqu'au cou, c'est bizarrement plus fiable 
comme point de vue.

Vincent
 

De : Benoit Chesneau  
Envoyé : vendredi 3 septembre 2021 08:53
À : Michel Py ; Vincent Duvernet 
; frnog-t...@frnog.org
Objet : Re: [FRnOG] RE: [TECH] ATS + UPS = cdhsjkezlkezllksq

la faq d’APC fit la meme chose pour le choix de l’onduleur:

It is not recommended to use 2 UPS's on the same input circuit as the sources 
of an ATS. It is also not recommended to use Line-Interactive model UPS's - 
only Double Conversion-Online models should be used.


https://www.apc.com/us/en/faqs/FA156201/


Benoît Chesneau, Enki Multimedia


Le jeu., sept. 2, 2021 à 04:08, Michel Py via frnog  a 
écrit :
> Vincent Duvernet a écrit :
> - Un jour lors d'une discussion avec le support APC pour un de nos clients, 
> le tech m'indique qu'il est primordial que les
> onduleurs en amont de l'ATS soient forcément des on-line sinon lors de la 
> commutation, il y aura une micro-coupure qui pourra
> mettre les alimentations en défaut / dans un état à la con / reboot. Je 
> suppose que c'est applicable à tous les racks ATS ?

J'ai longtemps cru que c'était du bullshit, mais en simple-phase, force est de 
constater que c'est parfois vrai.

Voici le problème : avec un onduleur "bypass", si le courant qui fournit 
l'onduleur est le même que celui de la seconde source pour ton ATS, quand dite 
source tombe, tu perds les deux cotés de l'ATS jusqu'à ce que l'onduleur 
commute en mode batterie. Sans l'ATS ça aurait pu passer, mais avec l'ATS qui 
perd ses deux sources en même temps ça introduit un délai supplémentaire qui 
peut être fatal. Le coup typique c'est que, en l'absence de source valide, 
l'ATS commute "au pif" sur une des deux sources, ou sur aucune. Quand 
l'onduleur commute en mode batterie, il faut un certain temps avant que l'ATS 
comprenne que l'une des deux sources est revenue, et c'est ce qui te tue. L'ATS 
a besoin d'une certaine qualité de courant avant de commuter vers la source qui 
vient de revenir, et les millisecondes sont précieuses, car l'onduleur mets un 
certain temps à produire du courant "propre" quand il commute vers la batterie.

En fait, l'ATS est trop intelligent; le temps qu'il décide si, finalement oui, 
le courant est revenu sur le circuit de l'onduleur, t'es dans les choux.
Malheureusement, il n'y a pas de solution. En théorie, un ATS qui aurait un peu 
de capacité pour gérer cette situation ferait l'affaire, mais dans la pratique 
un onduleur on-line est ce qu'il te faut. Sans ça, des fois ça marche, des fois 
pas.

Les onduleurs modernes, c'est un batard entre le bypass et le online.
Perso, j'ai arrêté l'ATS. Dans la pratique, plus d'emmerdes que de problèmes 
résolus.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/