Re: [FRnOG] [TECH] smtp Orange OFR_999

2021-09-07 Par sujet k...@ik.me via frnog 
> Le 07/09/2021 à 17:43, k...@ik.me via frnog a écrit :
>>  Est-il possible de contacter le postmaster d'Orange.fr ? Nos
>>  mails
>>  
>>   sont rejetés avec OFR_999 [999] sur les adresses @orange.fr,
>>  
>>   @wanadoo.fr ( le trafic mail est déjà en slow vers les domaines
>>  
>>   orange.).
> 
> Le 2021-09-07T20:37:19.000+02:00, Yohan Prod'homme
>  a écrit :
> 
> Bonjour,
> 
> Tu peux tenter de contacter ab...@orange.fr, ils ont la main sur les 
> 
> blocages et sont généralement très réactif.
> 
> Bonne soirée

Bonsoir,

Je vais tenter, merci.

Kevin



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

Re: [FRnOG] [TECH] smtp Orange OFR_999

2021-09-07 Par sujet Yohan Prod homme via frnog 

Le 07/09/2021 à 17:43, k...@ik.me via frnog a écrit :

Est-il possible de contacter le postmaster d'Orange.fr ? Nos mails
sont rejetés avec OFR_999 [999] sur les adresses @orange.fr,
@wanadoo.fr ( le trafic mail est déjà en slow vers les domaines
orange.).


Bonjour,

Tu peux tenter de contacter ab...@orange.fr, ils ont la main sur les 
blocages et sont généralement très réactif.


Bonne soirée




OpenPGP_signature
Description: OpenPGP digital signature

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

2021-09-07 Par sujet DUVERGIER Claude 


Le 07/09/2021 à 15:36, David Ponzone a écrit :
> Je crois qu’il manque des éléments pour pouvoir répondre exhaustivement.
> La zone privée doit pouvoir être interrogée par des gens à l’extérieur
> (ça a peu de sens puisqu’ils ne pourront pas atteindre la cible) ?
> -> solution simple en mettant une IP publique à ston DNS interne
> autoritaire sur interne.masociete.com 
> 
> Si c’est purement à usage interne, tu maitrises le résolveur utilisé par
> les clients ?
> -> si oui, alors la méthode du forward vers ton DNS interne pour
> interne.masociete.com , ainsi c’est une
> zone purement interne

Zone purement interne qui ne peut pas être interrogée par des clients
qui ne sont pas sur le LAN (en physique ou via un VPN).
Je maîtrise bien le résolveur configuré sur les clients (si je ne le
maîtrise pas ça serait pour un client type BYOD et le DHCP ferait quand
même le job d'indiquer le bon serveur résolveur).

Je compte donc mettre, sur mon résolveur, un forward de
"interne.ma_societe.com" vers mon serveur DNS interne.

Merci pour l'aide à la compréhension, le DNS c'est plutôt simple mais
quand on veut faire des trucs compliqué (hybride privé/public,
split-horizon, etc.) ça devient vite moins simple :P.

-- 
DUVERGIER Claude


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

[FRnOG] [TECH] smtp Orange OFR_999

2021-09-07 Par sujet k...@ik.me via frnog 
Bonjour la liste,

Est-il possible de contacter le postmaster d'Orange.fr ? Nos mails
sont rejetés avec OFR_999 [999] sur les adresses @orange.fr,
@wanadoo.fr ( le trafic mail est déjà en slow vers les domaines
orange.).

Merci d'avance,

Bonne soirée

Kevin



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

[FRnOG] [TECH] RFC 9099: Operational Security Considerations for IPv6 Networks

2021-09-07 Par sujet Stephane Bortzmeyer 
Tous les gens qui gèrent des réseaux IPv4 savent comment les sécuriser
(normalement…). Et pour IPv6 ? Si ce n'est pas un protocole
radicalement différent, il a quand même quelques particularités de
sécurité. Ce RFC donne des conseils pratiques et concrets sur la
sécurisation de réseaux IPv6. (Je le répète, mais c'est juste une
nouvelle version d'IP : l'essentiel du travail de sécurisation est le
même en v4 et en v6.)

https://www.bortzmeyer.org/9099.html


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

[FRnOG] [TECH] 118712

2021-09-07 Par sujet Francois Prems 
Bonjour à tous,

Bouteille à la mer...

un de mes clients (pro) se plaint que son numéro sur 118712.fr n'est pas le
bon. C'est un restaurant, le numéro de contact indiqué est celui d'un
salarié qui n'est pas la ligne directe du standard qui est une ligne fixe.

Sur 118712.fr, aucun contact possible, le client est renvoyé vers son
opérateur, nous, arguant que c'est nous qui déclarons ça auprès des
services d'annuaire.
A noter que sur les pages jaunes, l'info est bonne.
On ne fait rien de tout ça pour un numéro mobile, et je ne sais même pas
comment je ferais si je le voulais.

Ceci m'amène 2 questions :
- comment puis-je aider mon client ?
- qui centralise cette information ? Sur la CNIL
 :

"Ce sont les opérateurs de téléphonie qui communiquent vos coordonnées aux
éditeurs d’annuaires et services de renseignements, tels que les Pages
Blanches ou les 118 (article L.34 du code des postes et communications
électroniques). Le regroupement de ces listes d’abonnés constitue l'
"annuaire universel".

Et pour le mobile, ceci ne doit être fait qu'à la demande du client...

François

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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Tue, Sep 07, 2021 at 03:40:24PM +0200,
 DUVERGIER Claude  wrote 
 a message of 108 lines which said:

> > Parfait. Attention toutefois aux résolveurs qui, par défaut, ne
> > renvoient pas les adresses privées (RFC 1918) pour éviter les
> > attaques par changement. Si le journal de BIND contient des
> > "client 127.0.0.1#47583: RFC 1918 response from Internet", le
> > problème est là.
> 
> J'ai du mal à comprendre l'intérêt de ces enregistrements (présents
> sur les serveurs DNS d'OVH) s'ils mènent à des adresses que les
> résolveurs ne renverront pas

C'est configurable. Mais le comportement par défaut de beaucoup de
résolveurs est de ne pas transmettres les réponses ayant des adresses
privées. (C'est contrôlé par l'option private-address: dans Unbound.)

> À moins qu'il ne faille en plus ajouter une configuration
> particulière sur mes résolveurs privés/LAN ? Comme par exemple pour
> intercepter les requêtes vers "interne.ma_societe.com" ?

Pourquoi pas (c'est ce que suggérait David Ponzone). Mais, dans ce
cas, cela impose que tout le monde en interne utilise les mêmes
résolveurs.


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

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

2021-09-07 Par sujet DUVERGIER Claude 


Le 07/09/2021 à 11:46, Stephane Bortzmeyer a écrit :
> Je voudrais bien la réponse complète, notamment pour savoir quel
> serveur il a interrogé.

Voici la réponse (j'ai rajouté le "+nodnssec" pour éviter d'éventuel
bruit) :


; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 +nodnssec +trace A
app-5.interne.ma_societe.com
; (1 server found)
;; global options: +cmd
.   85962   IN  NS  c.root-servers.net.
.   85962   IN  NS  b.root-servers.net.
.   85962   IN  NS  f.root-servers.net.
.   85962   IN  NS  a.root-servers.net.
.   85962   IN  NS  h.root-servers.net.
.   85962   IN  NS  j.root-servers.net.
.   85962   IN  NS  i.root-servers.net.
.   85962   IN  NS  e.root-servers.net.
.   85962   IN  NS  k.root-servers.net.
.   85962   IN  NS  d.root-servers.net.
.   85962   IN  NS  g.root-servers.net.
.   85962   IN  NS  l.root-servers.net.
.   85962   IN  NS  m.root-servers.net.
.   85962   IN  RRSIG   NS 8 0 518400 2021092005 
2021090704 26838 .
Wma8PsBb+TVD/g7oEnlMMzPocz2w8jHMNs0VqrxQ7wVRNd5gLPvu0O4w
GrGDZrXUAQp59aCHTA1/KhdzukL/CQvia5cJCxDGL57zLW4ZnbUPCl9U
RTb6+eQUZjvki5ZveGhh5BVqCfjjDdNH9gV5aWusoS4dso2Tqi9NEiFQ
mERd9KqUMEEM8KJNlnwkwme/oN2OsuW0KJ3XbPUC2+qLVBkapt8MLz+b
9F6w8RDRijaY7rYxIsx6YH/k0Q0h+pyuWv+IRdjf71arSix9FNaamup7
5fK6ptYfhi7Lhpb3tjehbyfpDbqGm0jd9tDxj+62SmcgRMM0JbVLxikX w+qU8Q==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 20 ms

net.172800  IN  NS  l.gtld-servers.net.
net.172800  IN  NS  b.gtld-servers.net.
net.172800  IN  NS  c.gtld-servers.net.
net.172800  IN  NS  d.gtld-servers.net.
net.172800  IN  NS  e.gtld-servers.net.
net.172800  IN  NS  f.gtld-servers.net.
net.172800  IN  NS  g.gtld-servers.net.
net.172800  IN  NS  a.gtld-servers.net.
net.172800  IN  NS  h.gtld-servers.net.
net.172800  IN  NS  i.gtld-servers.net.
net.172800  IN  NS  j.gtld-servers.net.
net.172800  IN  NS  k.gtld-servers.net.
net.172800  IN  NS  m.gtld-servers.net.
net.86400   IN  DS  35886 8 2
7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
net.86400   IN  RRSIG   DS 8 1 86400 2021092005 
2021090704 26838 .
WUIHSl2P0zQb5BvolvoRt6aI7u+rZQ82kKePYXhcYrfASwuhPvO5kOwl
HPpKbz7e+kO4naWPlxDUujEV3KnPLo4MnI21s8frdkoUROQcTOSI0lv8
KyuIFO0agMepU8/JOGlq1fBuc9tknROJHokpKH2VLmgqQC6+XQmxey7C
gxmsl5anKaSnloBU6FNt4ao/Edvf0SDdgcYEblFbK+68IaPUYjhd4w0E
Bnzyg/+oL3A2q4bU7YInYLvQBC3vAIucDKHGAPeQa46mC0EJJe+L9R8/
sTdFx+tWHSBh9ZR3RFd2DxNukKM17eJT61EcSyxPQiI0glWqMIskF+Mq TISraQ==
;; Received 1186 bytes from 192.5.5.241#53(f.root-servers.net) in 20 ms

ma_societe.com. 172800  IN  NS  dns11.ovh.net.
ma_societe.com. 172800  IN  NS  ns11.ovh.net.
ma_societe.com. 86400   IN  DS  58983 7 2
8025A664C84288738EC92DAAFB0B367B9EA188591270919279008C6C 9AF82CE6
ma_societe.com. 86400   IN  RRSIG   DS 8 2 86400 20210911054001
20210904043001 65378 net.
QtGmAv2Mj1QEF+4SBZpfkt0z2h6/ej4ynO1uZ0Xxbd7yR6hC6oH12qHH
RRohEgaFf+8eh7DYRpu5HvvX2IF+X8OSyct4mRbpg37DZriE8tO1IiSW
q674BJneaM4PkFNH2Tu8waY37h5Pb/VFRaDkQno6cpErN+kNZSD0YBrB
aPkas0WQOsQ/HAbsfatNL5gBhYeSphQLF6hLVUGXVkRYNA==
;; Received 432 bytes from 192.52.178.30#53(k.gtld-servers.net) in 24 ms

interne.ma_societe.com. 43200   IN  NS  interne-ns1.ma_societe.com.
LJ6U97P1DE71RRSESP3FM3JBGVCQ4SB3.ma_societe.com.300 IN NSEC3 1 0 8
4FD70F486CEE3125 LUUGBENECP5ORU1JVRCGDBLS9A2V23VH NS
LJ6U97P1DE71RRSESP3FM3JBGVCQ4SB3.ma_societe.com.300 IN RRSIG NSEC3 7 3
300 20210929152158 20210830152158 52202 ma_societe.com.
guQUGTqPakiKFLT3mVmRVABikEkw0DN5cOoRx/8ks6ncyJavRGzWzEAb
ZbodyKZwssTZtr74SOs/+FVlTB+mj3XqYWCeErcDRNQMYC7Ni2QnAc+t
gOYJdLYPYa9wtHf1PgIE6nB0bbmMZEStHMmAa1Ni41YrSFwP4Tm/yFX0 txc=
couldn't get address for 'interne-ns1.ma_societe.com': not found



>> 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
> 
> Parfait. Attention toutefois aux résolveurs qui, par défaut, ne
>

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

2021-09-07 Par sujet David Ponzone 
Je crois qu’il manque des éléments pour pouvoir répondre exhaustivement.
La zone privée doit pouvoir être interrogée par des gens à l’extérieur (ça a 
peu de sens puisqu’ils ne pourront pas atteindre la cible) ?
-> solution simple en mettant une IP publique à ston DNS interne autoritaire 
sur interne.masociete.com 

Si c’est purement à usage interne, tu maitrises le résolveur utilisé par les 
clients ?
-> si oui, alors la méthode du forward vers ton DNS interne pour 
interne.masociete.com , ainsi c’est une zone 
purement interne


> Le 7 sept. 2021 à 15:27, DUVERGIER Claude  a 
> écrit :
> 
> 
> Le 07/09/2021 à 11:53, Stephane Bortzmeyer a écrit :
>> On Mon, Sep 06, 2021 at 10:00:23PM +0200,
>> l...@jhadba.eu  wrote 
>> a message of 196 lines which said:
>> 
>>> La solution est dans le message précédent. Aucun paramétrage
>>> nécessaire sur la zone OVH,
>> 
>> Au contraire, c'était la bonne solution. Après, je ne vois rien
>> d'étonnant à ce que Google n'arrive pas à résoudre les noms internes,
>> c'était un peu le but, non ?
> 
> Effectivement, j'ai mal choisi mon test, j'employais le
> 
> dig @8.8.8.8 +trace A app-5.interne.ma_societe.com
> 
> comme un moyen de vérifier que, depuis le LAN j'avais bien la bonne
> réponse et que depuis l’extérieur je n'avais bien aucun résultat. Mais à
> cause de la récursivité de le requête côté Google le test s'avère inadapté.
> 
> 
> Le 07/09/2021 à 12:05, Stephane Bortzmeyer a écrit :
>> On Tue, Sep 07, 2021 at 11:57:39AM +0200,
>> David Ponzone  wrote
>> a message of 28 lines which said:
>> 
>>> Yep, mais je crois que justement l’idée était d’utiliser
>>> l’infra DNS publique pour opérer un service de
>>> résolution DNS sur une zone privée.
>> 
>> J'avais compris le contraire : avoir des noms privés qui
>> ne soient PAS résolvables publiquement.
> 
> Ce que je souhaite à avoir c'est bien de laisser à OVH la gestion des
> noms "publics" du domaine enregistré et connu (eg. www.ma_societe.com,
> mail.ma_societe.com, etc.) et d'avoir, sur mes serveurs DNS, des noms
> "privés" qui ne seraient donc pas connus des serveurs DNS d'OVH : je ne
> veux pas avoir à aller sur le Manager d'OVH pour rajouter un
> "toto.interne.ma_societe.com".
> 
> Serveur DNS d'OVH :
> * www.ma_societe.com => record A vers un serveur public
> * foo.ma_societe.com => record A vers un serveur public
> * interne.ma_societe.com => délégation à mon serveur DNS privé/LAN en
> indiquant son IP privée au sens RFC 1918 (bien que non-joignable de
> l'extérieur -logique-, l'IP peut être connue publiquement ça n'est pas
> un réel problème).
> 
> Serveur DNS privé/de mon LAN :
> * routeur-4.interne.ma_societe.com
> * app-5.interne.ma_societe.com
> 
> 
> -- 
> DUVERGIER Claude


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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Tue, Sep 07, 2021 at 03:27:59PM +0200,
 DUVERGIER Claude  wrote 
 a message of 56 lines which said:

> Ce que je souhaite à avoir c'est bien de laisser à OVH la gestion des
> noms "publics" du domaine enregistré et connu (eg. www.ma_societe.com,
> mail.ma_societe.com, etc.) et d'avoir, sur mes serveurs DNS, des noms
> "privés" qui ne seraient donc pas connus des serveurs DNS d'OVH : je ne
> veux pas avoir à aller sur le Manager d'OVH pour rajouter un
> "toto.interne.ma_societe.com".

OK, donc la meilleure solution, AMHA, est bien de déléguer
interne.ma_societe.com (mais .fr, c'est mieux) à des serveurs
internes, avec adresses privées.




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

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

2021-09-07 Par sujet DUVERGIER Claude 


Le 07/09/2021 à 11:53, Stephane Bortzmeyer a écrit :
> On Mon, Sep 06, 2021 at 10:00:23PM +0200,
>  l...@jhadba.eu  wrote 
>  a message of 196 lines which said:
> 
>> La solution est dans le message précédent. Aucun paramétrage
>> nécessaire sur la zone OVH,
> 
> Au contraire, c'était la bonne solution. Après, je ne vois rien
> d'étonnant à ce que Google n'arrive pas à résoudre les noms internes,
> c'était un peu le but, non ?

Effectivement, j'ai mal choisi mon test, j'employais le

dig @8.8.8.8 +trace A app-5.interne.ma_societe.com

comme un moyen de vérifier que, depuis le LAN j'avais bien la bonne
réponse et que depuis l’extérieur je n'avais bien aucun résultat. Mais à
cause de la récursivité de le requête côté Google le test s'avère inadapté.


Le 07/09/2021 à 12:05, Stephane Bortzmeyer a écrit :
> On Tue, Sep 07, 2021 at 11:57:39AM +0200,
>  David Ponzone  wrote
>  a message of 28 lines which said:
>
>> Yep, mais je crois que justement l’idée était d’utiliser
>> l’infra DNS publique pour opérer un service de
>> résolution DNS sur une zone privée.
>
> J'avais compris le contraire : avoir des noms privés qui
> ne soient PAS résolvables publiquement.

Ce que je souhaite à avoir c'est bien de laisser à OVH la gestion des
noms "publics" du domaine enregistré et connu (eg. www.ma_societe.com,
mail.ma_societe.com, etc.) et d'avoir, sur mes serveurs DNS, des noms
"privés" qui ne seraient donc pas connus des serveurs DNS d'OVH : je ne
veux pas avoir à aller sur le Manager d'OVH pour rajouter un
"toto.interne.ma_societe.com".

Serveur DNS d'OVH :
* www.ma_societe.com => record A vers un serveur public
* foo.ma_societe.com => record A vers un serveur public
* interne.ma_societe.com => délégation à mon serveur DNS privé/LAN en
indiquant son IP privée au sens RFC 1918 (bien que non-joignable de
l'extérieur -logique-, l'IP peut être connue publiquement ça n'est pas
un réel problème).

Serveur DNS privé/de mon LAN :
* routeur-4.interne.ma_societe.com
* app-5.interne.ma_societe.com


-- 
DUVERGIER Claude


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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Tue, Sep 07, 2021 at 11:57:39AM +0200,
 David Ponzone  wrote 
 a message of 28 lines which said:

> Yep, mais je crois que justement l’idée était d’utiliser l’infra DNS
> publique pour opérer un service de résolution DNS sur une zone
> privée.

J'avais compris le contraire : avoir des noms privés qui ne soient PAS
résolvables publiquement.

> La bonne démarche dans ce cas, c’est pas d’avoir un résolveur en
> interne qui forward vers un autoritaire pour  la zone privée ?

Ça marche aussi mais ça oblige tout le monde en interne à utiliser les
mêmes résolveurs (ou au moins à forwarder vers eux), ce qui peut être
contraignant.



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

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

2021-09-07 Par sujet David Ponzone 
Yep, mais je crois que justement l’idée était d’utiliser l’infra DNS publique 
pour opérer un service de résolution DNS sur une zone privée.
La bonne démarche dans ce cas, c’est pas d’avoir un résolveur en interne qui 
forward vers un autoritaire pour  la zone privée ?

> Le 7 sept. 2021 à 11:53, Stephane Bortzmeyer  a écrit :
> 
> On Mon, Sep 06, 2021 at 10:00:23PM +0200,
> l...@jhadba.eu  wrote 
> a message of 196 lines which said:
> 
>> La solution est dans le message précédent. Aucun paramétrage
>> nécessaire sur la zone OVH,
> 
> Au contraire, c'était la bonne solution. Après, je ne vois rien
> d'étonnant à ce que Google n'arrive pas à résoudre les noms internes,
> c'était un peu le but, non ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Tue, Sep 07, 2021 at 11:28:29AM +0200,
 DUVERGIER Claude  wrote 
 a message of 219 lines which said:

> 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) »...

Le protocole DNS ne permet pas de savoir si le client est un résolveur
complet (et donc capable de suivre une éventuelle délégation) ou un
bête client sans intelligence qui veut une réponse finale. Donc,
Google Public DNS n'a pas le choix. (Bon, il y a le bit RD, mais il
est « tout ou rien ».)



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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Mon, Sep 06, 2021 at 10:00:23PM +0200,
 l...@jhadba.eu  wrote 
 a message of 196 lines which said:

> La solution est dans le message précédent. Aucun paramétrage
> nécessaire sur la zone OVH,

Au contraire, c'était la bonne solution. Après, je ne vois rien
d'étonnant à ce que Google n'arrive pas à résoudre les noms internes,
c'était un peu le but, non ?


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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Mon, Sep 06, 2021 at 07:19:34PM +0200,
 François Goudal via frnog  wrote 
 a message of 166 lines which said:

> 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.

Ce qui serait une mauvaise pratique. Il ne faut pas mixer résolveurs
et serveurs faisant autorité
.

> 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.

Mauvais conseil. Débrayer la sécurité parce qu'elle vous protège n'est
pas une bonne idée. Et c'est inutile ici, puisqu'il y a une délégation
non sécurisée donc DNSSEC ne fera pas d'histoire.


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

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

2021-09-07 Par sujet Stephane Bortzmeyer 
On Mon, Sep 06, 2021 at 06:30:34PM +0200,
 DUVERGIER Claude  wrote 
 a message of 114 lines which said:

> et `dig` me réponds "not found" / "no more"

Je voudrais bien la réponse complète, notamment pour savoir quel
serveur il a interrogé.

> 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.

Oui, c'est la bonne pratique.

> 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

Parfait. Attention toutefois aux résolveurs qui, par défaut, ne
renvoient pas les adresses privées (RFC 1918) pour éviter les attaques
par changement. Si le journal de BIND contient des "client
127.0.0.1#47583: RFC 1918 response from Internet", le problème est là.

> Après propagation, un :

Le DNS, ce n'est pas BGP, Il n'y a pas de propagation
.



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

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

2021-09-07 Par sujet Daniel via frnog 

Bonjour,

bind est capable de gérer des vues locales pour un domaine

view "local" {
    match-clients { !key external; local; slavesv4; slavesv6; };
    recursion yes;
    allow-recursion { local; ipv4; ipv6; };

    zone "mondomaine.tld" {
    type master;
    file "mondomaine.local";
    allow-transfer { slavesv6; } ;
    };
};

view "external" {
    recursion no;

    match-clients { key external; any; };
    

Le 07/09/2021 à 11:28, DUVERGIER Claude a écrit :



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.


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

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

2021-09-07 Par sujet DUVERGIER Claude 
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, jha...@jhadba.eu 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
>  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
>>  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_societecom", 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.00.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

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

2021-09-07 Par sujet DUVERGIER Claude 



> 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
>  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
>> mailto: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