Forum général.général DNS et sous-domaine

Posté par Philippe M (site web personnel) le 09 juin 2022 à 14:37. Licence CC By‑SA.

Étiquettes : aucune

juin

2022

Bonjour à tous,

Je suis en pleine ré-organisation de DNS et je me pose une question de configuration et d'attribution de sous-domaine (lié aussi à un domaine AD).

J'ai un nom de domaine example.com qui est géré par OVH (ils hébergent notre site et notre messagerie). En interne je souhaite mettre en place un sous-domaine (dans le futur il est possible qu'il y en ai d'autres) à example.com, qui serait par exemple : marue205 (cela serait aussi le domaine AD).

Pour le moment, sur une plateforme de test, j'ai une zone qui s'occupe de marue205 et de la résolution des machines internes, lorsque bind ne connait pas le domaine il transmet au serveur DNS externe de notre opérateur.

Est-ce que j'aurai un intérêt à gérer sur mon bind local la zone example.com ? Et si c'est le cas est-ce le nom DNS de mes machines locales resterait marue205 ou bien marue205.exemple.com ?

C'est un peu confus pour moi cette partie et je n'arrive pas à trouver un site qui explique clairement.

# interne, externe, vues

Posté par cg le 09 juin 2022 à 21:50. Évalué à 3.
Salut,
j'ai peut-être pas tout saisi, mais voici ce qui me semblerait possible avec Bind.

Est-ce que j'aurai un intérêt à gérer sur mon bind local la zone example.com ?

Oui, sans doute. En tout cas ce n'est pas gênant.

Tu as une zone example.com, une zone marue205.example.com, des zones reverse par exemple 0.168.168.in-addr.arpa). Ce qui est dans marue205.example.com n'existe qu'en interne.

Un intérêt de gérer aussi example.com en interne, c'est que tu peux dire à Bind de renvoyer des IPs différentes selon que le demandeur provient d'un réseau ou un autre. Ça s'appelle une vue.

Par exemple, pour mail.example.com, tu renvoies 192.168.1.12 si la requête vient de dedans, et 83.x.y.z si elle vient d'Internet. En pratique, ce sont des zones différentes, qui sont servies en fonction de l'origine de la requête.

(Sous réserve des offres OVH) Et pour enfoncer le clou, cette zone "publique", tu peux sans doute l'envoyer depuis ton serveur primaire sur un serveur public d'OVH qui sert de secondaire (ou de primaire public). Ainsi, tu gères tes zones (internes et publiques) en interne, et OVH s'occupe de rendre accessible tes enregistrements publics.

Et si c'est le cas est-ce le nom DNS de mes machines locales resterait marue205 ou bien marue205.exemple.com ?

Ça dépend de la configuration du résolveur.

Si tu as dans le resolv.conf :
```
search marue205.example.com
```
alors tu peux faire ping totor, ce sera complété en totor.marue205.example.com. (voir le manuel de resolv.conf)
- [^] # Re: interne, externe, vues
  
  Posté par AncalagonTotof le 10 juin 2022 à 09:24. Évalué à 1.
  
  Sympa tout ça.
  
  Bon, je suis une ouiche en DNS. J'ai quand même réussi une config à peu près carrée chez OVH pour mon domaine, en particulier pour le mail auto hébergé, avec du SPF, DKIM, DMARC et je ne sais plus trop quoi là tout de suite.
  
  Il reste un inconvénient pour que mes mails ne soient pas considérés comme spam par les MTA destinataires, ce qui arrive très souvent : le reverse DNS.
  
  Un ping <mon.domaine> fonctionne très bien, c'est le B-A-BA.
  
  Mais quand un MTA fait du reverse sur mon IP, il tombe sur le "nom à la con du fournisseur d'accès" (Free en l’occurrence) et non pas sur <mon.domaine>.
  C'est plutôt normal, mais c'est hyper pénible.
  D'autant plus que chez Free, le reverse DNS perso ne fonctionne que dans de rares cas, en fonction de la plage d'IPv4 à laquelle on appartient. Et en plus, ils prévoient de supprimer totalement cette option.
  
  Du coup, ça fait un moment que je me demande si ce serait :
  1) possible
  2) autorisé, voire légal
  de gérer ça sur mon propre serveur à la maison, je ne sais pas, avec un bind peut-être ? Ce bind serait-il capable/autorisé à publier/pousser (terme correct ?) l'information "cette adresse IP, c'est ce <mon.domaine> et pas un autre".
  J'imagine que si c'est possible, ça va entrer en conflit avec Free d'une manière ou d'une autre.
  
  J'ai l'impression que ce bricolage est mon dernier espoir d'apparaître "propre" vis à vis des autres.
  Avant de passer à la solution ultime : louer un "vrai" serveur chez un hébergeur
  - [^] # Re: interne, externe, vues
    
    Posté par NeoX le 10 juin 2022 à 10:20. Évalué à 3.
    
    Mais quand un MTA fait du reverse sur mon IP, il tombe sur le "nom à la con du fournisseur d'accès" (Free en l’occurrence) et non pas sur .
    C'est plutôt normal, mais c'est hyper pénible.
    
    vu que c'est OVH qui gere tes emails, autant que tes machines envoient leurs emails par OVH
    la bonne ligne dans le SPF autorisera le SMTP de OVH à envoyer de la part de ton domaine,
    
    et lui est normalement autorisé par les principaux services d'emails
    - [^] # Re: interne, externe, vues
      
      Posté par AncalagonTotof le 10 juin 2022 à 10:30. Évalué à 1.
      
      Nan nan, je me suis peut-être mal exprimé, c'est mon serveur chez moi qui envoi et reçoit les mails en direct.
      D'où le problème de reverse DNS.
      Je n'ai pour le moment aucune solution externe pour faire relay, à par repasser par smtp.free.fr en relay dans ma config postfix, mais bof bof.
  - [^] # Re: interne, externe, vues
    
    Posté par cg le 10 juin 2022 à 19:41. Évalué à 4.
    Hello, alors non, ça ne marchera pas :(.
    
    Les zones DNS reverse sont des zones "normales". Quand une requête DNS a lieu, le resolveur va demander "qui est le NS pour bbb.aaa.196.78.in-addr.arpa, de la même manière que pour un nom comme www.perdu.com.
    
    Concrètement :
```
$ dig ns bbb.aaa.196.78.in-addr.arpa

; <<>> DiG 9.18.3 <<>> ns bbb.aaa.196.78.in-addr.arpa
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;bbb.aaa.196.78.in-addr.arpa.   IN      NS
;; AUTHORITY SECTION:
197.196.78.in-addr.arpa. 900    IN      SOA     ns2-rev.proxad.net. hostmaster.proxad.net. 2003061901 21600 3600 1209600 86400
```
    et en version courte :
```
$ dig ns 197.196.78.in-addr.arpa +short
ns2-rev.proxad.net.
ns3-rev.proxad.net.
```
    Et tu n'as pas la main pour dire d'utiliser ton serveur DNS au lieu de celui de ns2-rev.proxad.net.
    
    Pour pouvoir le faire, il faudrait que Proxad accepte de faire une délégation d'une zone reverse en a.b.c.d/32 (seulement ton IP publique quoi). Bonne chance ;). S'ils acceptaient, tu pourrais alors être autoritaire sur la réponse.
    
    Bref, c'est pas gagné !
    
    J'ai l'impression que ce bricolage est mon dernier espoir d'apparaître "propre" vis à vis des autres.
    
    Même si tu avais un reverse propre, rien que le fait d'arriver d'un bloc d'IP de connexions résidentielles suffit à passer pour un spammeur. Il y a pas mal de retours d'expériences là-dessus sur linuxfr.
    - [^] # Re: interne, externe, vues
      
      Posté par AncalagonTotof le 11 juin 2022 à 00:34. Évalué à 1.
      
      Merci, c'est plus clair.
      Pour les block list, a priori, je n'apparais que dans l'un d'entre eux. De temps en temps dans un second, qui me permet de me délister seul (spamhaus de mémoire).
      L'utilise MX Toolbox et mail-tester de temps en temps pour faire des vérifications.
      Ah, j'ai refais un test, et on dirait que j'ai plein de problème que je n'avais pas avant. Bon, j'vous laisse, j'ai du boulot !
- [^] # Re: interne, externe, vues
  
  Posté par Philippe M (site web personnel) le 14 juin 2022 à 14:28. Évalué à 2.
  Salut, désolé de répondre si tardivement.
  
  Merci pour tes infos, je comprends un peu mieux la logique. A la relecture de ma question il y a un sujet que je n'ai pas abordé : docker, traefik et les certificats Let's. Actuellement traefik est configuré pour faire une demande de création de certificats à Let's sur le domaine example.com et il utilise l'API d'OVH pour faire en sorte de Let's retrouve tout ce qu'il faut pour valider le certificats. Ces containers sont accessible uniquement en interne et ils le resteront. Par exemple pour le container en charge de GLPI j'y accède par glpi.example.com, sur mon bind actuel j'ai cette config pour la zone example.com
```
$ORIGIN example.com.
$TTL 86400      ; 1 day
@       IN      SOA     dns11.ovh.net. admin.example.com. (
                                 3667417071 ; serial
                                 21600      ; refresh (6 hours)
                                 3600       ; retry (1 hour)
                                 604800     ; expire (1 week)
                                 86400      ; minimum (1 day)
                                 )
@       IN              NS      ns11.ovh.net.
@       IN              NS      dns11.ovh.net.
localhost               A       127.0.0.1
@       IN              A       213.186.33.2
www                     A       213.186.33.2
galerie                 CNAME   www
share                   CNAME   www
galerie                 CNAME   www
mail                    CNAME   www
smtp                    CNAME   www
imap                    CNAME   www
pop                     CNAME   www
ftp                     CNAME   www
pim                     CNAME   www
mdm                     A       192.168.xxx.xxx
; Serveur docker
*.example.com.           A       192.168.xxx.xxx
```
  Du coups il me parait logique que je conserve la gestion local du domaine example.com pour les machines locales et si j'ai bien compris je vais avoir trois cas :
  - une zone pour *.marue205.example.com : accessible uniquement par mes machines locales, chargé de résoudre les ip locales et non accessible depuis l'extérieur;
  - une zone pour *.example.com : accessible uniquement par mes machines locales, chargé de faire la correspondance pour cette zone qui renvoie soit sur une IP locale (docker par exemple) soit sur une IP externe;
  - les requêtes pour les autres domaines qui seront redirigés par mon bind vers le DNS de mon opérateur.
  
  Demain si j'ajoute un domaine, monautrerue90, j'ai juste a ajouter une zone monautrerue90.example.com à mon DNS en charge de résoudre les correspondances des ip/machines de cette zone.
  
  J'ai bon ? ;)
  
  Born to Kill EndUser !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.