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

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
0
9
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  . É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)

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 1.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: interne, externe, vues

        Posté par  . É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  . É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  (site web personnel) . É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.