Aller au contenu

[TUTO] DNS Server


Fenrir

Messages recommandés

ok j'ai donc modifié les choses à l'envers.

j'ai en type A : nas-1.ndd ; nas-2.ndd ; nas-3.ndd vers IP des NAS
et en cname : nas1.ndd vers nas-1.ndd ; nas2.ndd vers nas-1.ndd ; nas3.ndd vers nas-1.ndd

je n'ai rien touché au reverse proxy donc nas1.ndd renvoi bien vers 5001
et en wan, et joignable par cette même adresse.

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Il y a 5 heures, Jeff777 a dit :
Il y a 6 heures, .Shad. a dit :

Je pense que je vais créer un petit tutoriel / memento pour expliquer le système DNS dans les grandes lignes, ce sont toujours les mêmes questions qui reviennent (gros manque du tutoriel).

Ah oui...ça m'évitera de me faire des noeuds au  

Comme à beaucoup d'autres ici, Oui, ce TUTO serait bien utile ...👍

Cordialement

oracle7😉

Lien vers le commentaire
Partager sur d’autres sites

Il y a 7 heures, .Shad. a dit :

Pourquoi faire du HTTPS -> HTTPS ? d'autant que là tu restes sur la même machine.

Car si j'ouvre video station via dsm ça marche pas sans https (enfin je crois)

Il y a 7 heures, .Shad. a dit :

Au final ça fonctionne ou pas ?

Pour le moment impeccable 🙂 Merci

Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64

Bonjour,

Le 04/07/2021 à 08:48, GrOoT64 a dit :

ok j'ai donc modifié les choses à l'envers.

j'ai en type A : nas-1.ndd ; nas-2.ndd ; nas-3.ndd vers IP des NAS
et en cname : nas1.ndd vers nas-1.ndd ; nas2.ndd vers nas-1.ndd ; nas3.ndd vers nas-1.ndd

je n'ai rien touché au reverse proxy donc nas1.ndd renvoi bien vers 5001
et en wan, et joignable par cette même adresse.

C'est quand même étonnant que tu sois obligé de passer par une couche supplémentaire (CNAME : nas1.ndd vers nas-1.ndd) pour atteindre tes NAS. Je n'ai personnellement pas cela dans ma zone DNS et j'ai l'accès direct avec un simple nas-1.ndd (pour reprendre ta notation) par le reverse proxy.

Enfin tant mieux si cela marche, c'est quand même le principal ! Mais cela reste bizarre à mon humble avis ...🤔

Cordialement

oracle7😉

Modifié par oracle7
Lien vers le commentaire
Partager sur d’autres sites

il y a 1 minute, oracle7 a dit :

C'est quand même étonnant que tu sois obligé de passer par une couche supplémentaire (CNAME : nas1.ndd vers nas-1.ndd) pour atteindre tes NAS. Je n'ai personnellement pas cela dans ma zone DNS et j'ai l'accès est direct avec un simple nas-1.ndd (pour reprendre ta notation) par le reverse proxy.

Bonjour @oracle7, ça fonctionnait aussi très bien comme toi MAIS si j'utilise Secure SIgnIn avec mon tel (genre pour me loguer avec mon empreinte) ça marche plus, il faut que je me reconnecte en wan, puis en lan, puis en wan etc... avec les mêmes adresses/identifiants

et de plus, je ne passais pas par le reverse proxy en lan puisque je pointé sur l'ip d'un des nas direct.
donc mes adresses étaient suivies de :5001 ou :8001 pour le routeur

Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64

Bonjour,

Je peux comprendre que l'usage de "Secure Signin" puisse perturber, quoique ... Peut-être qu'un nouveau contrôle de ta zone DNS chez ton fournisseur de domaine, serait à faire ? Ton DDNS (donc ton domaine) renvoie bien sur ton @IP externe ?

Mais je ne comprends pas dans le cas du LAN pourquoi cela ne passait pas par le reverse proxy et qu'en plus il te fallait préciser le port à tes @IP. Il y a vraiment un truc bizarre ... Tes définitions de reverse proxy semblent bonnes à la vue de tes copies d'écran, alors peut-être aussi il te faudrait revoir du coté du serveur DNS que tout est correct ?

Cordialement

oracle7😉

Lien vers le commentaire
Partager sur d’autres sites

@oracle7 Dans mon serveur DNS en attribuant des vrais noms:

Pour les A (qui traduisent une adresse IP)
NAS-ARES.ndd.tld est en A vers 192.168.64.10 (sa propre IP)
NAS-ARTEMIS.ndd.tld est en A vers 192.168.64.11 (sa propre IP)
NAS-CHRONOS.ndd.tld est en A vers 192.168.64.12 (sa propre IP)
Si je ping ces 3 adresses, je tombe évidement sur leurs @IP correspondantes.

 

Pour les CNAME (qui traduisent vers un ndd) - C'est ces adresses que je tapent en WAN également
ARES.ndd.tld est en CNAME vers NAS-ARES.ndd.tld
ARTEMIS.ndd.tld est en CNAME vers NAS-ARES.ndd.tld
CHRONOS.ndd.tld est en CNAME vers NAS-ARES.ndd.tld

Si je ping ces 3 adresses, je tombe sur l'@IP de NAS-ARES.ndd.tld donc 192.168.64.10

Si j'utilises QUE les lignes vertes dans mon serveur DNS, je ne peux pas passer par le reverse proxy de ARES puisse que je pointe directement vers mes périphériques.

Modifié par GrOoT64
Lien vers le commentaire
Partager sur d’autres sites

il y a 27 minutes, oracle7 a dit :

Mais je ne comprends pas dans le cas du LAN pourquoi cela ne passait pas par le reverse proxy et qu'en plus il te fallait préciser le port à tes @IP.

Je ne précise rien, c'est les NAS ARTEMIS et CHRONOS qui les attribue  tout seuls

Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64

Bonjour,

Je te propose cette démarche toute simple, libre à toi de la suivre ou non (je fonctionne comme cela chez moi sans aucun problème) :

1 - Chez ton fournisseur de domaine (? OVH) :

  • Ton DynHost doit être :  ndd.tld --> ton @IP externe
  • Dans la zone DNS tu devrais avoir :

*.ndd.tld.   CNAME  ndd.tld.    --> qui couvre automatiquement ( NAS-ARES.ndd.tld, NAS-ARTEMIS.ndd.tld et NAS-CHRONOS.ndd.tld ainsi que toutes les autres applications et/ou services - par ex fichiers.ndd.tld pour FileStation, etc ...)

ou bien

NAS-ARES.ndd.tld.   CNAME  ndd.tld.

NAS-ARTEMIS.ndd.tld.   CNAME  ndd.tld.

NAS-CHRONOS.ndd.tld.   CNAME  ndd.tld.

fichier.ndd.tld.   CNAME  ndd.tld.

etc ...

2 - Dans DNS Serveur sur le routeur, ta zone DNS locale devrait être :

*.ndd.tld.   CNAME   ndd.tld.

ndd.tld.   A   @IP locale NAS-ARES (192.168.64.10) (qui supporte le reverse proxy)

ndd.tld.  NS  ns.ndd.tld.

ns.ndd.tld.  A  @IP locale Routeur (??? 192.168.64.1)(qui supporte le DNS Server)

NAS-ARTEMIS.ndd.tld.   A  192.168.64.11

NAS-CHRONOS.ndd.tld.   A    92.168.64.12

Par ailleurs sur le routeur les ports 80 et 443 sont transférés vers le NAS-ARES qui porte le reverse proxy et où ces deux ports sont ouverts dans le pare-feu.

Ainsi depuis le WAN, une URL du type https://xxx.ndd.tld (+ ":443" si émise depuis une application DSxxx) sera routée vers ton @IP externe (donc vers ta box et donc ensuite vers ton routeur puisqu'en DMZ). Ensuite, le routeur par défaut la redirigera vers ton NAS ARES et c'est lui qui écoute le port 443 via le reverse proxy qui redirigera vers l'application ou service "xxx" concerné(e). Pour les NAS-ARTEMIS et NAS-CHRONOS c'est directement le serveur DNS qui fourni l'@IP locale correspondante (enregistrement A) pour router la connexion.

Depuis le LAN, c'est le serveur DNS qui, selon, fourni directement l'@IP locale correspondante (pour les NAS-ARTEMIS et NAS-CHRONOS) ou qui renvoie sur le NAS-ARES avec son reverse proxy qui donne l'@IP locale + port pour les applications ou services "xxx".

Voilà, ma vision du traitement des URL issues du WAN ou du LAN. Ne pas hésiter à me reprendre si j'ai dit une c...ie. C'est comme cela que je l'ai compris.

Cordialement

oracle7😉

 

Lien vers le commentaire
Partager sur d’autres sites

@oracle7 Il n'y a aucune redondance dans la configuration de sa zone. Il essayait simplement d'atteindre DSM via le domaine qu'il avait attribué à son NAS, or les deux doivent être bien distincts. La seule différence entre ce que tu proposes et ce qu'il a c'est que tu utilises un enregistrement wildcard.

Lien vers le commentaire
Partager sur d’autres sites

@.Shad.

Bonjour,

il y a 11 minutes, .Shad. a dit :

Il essayait simplement d'atteindre DSM via le domaine qu'il avait attribué à son NAS, or les deux doivent être bien distincts.

Je ne l'avais pas compris comme cela mais tu dois avoir raison.

En tous cas ce qui est sûr c'est, d'expérience, que l'on ne peut pas utiliser le nom du NAS dans le domaine que l'on utilise pour l'atteindre via le reverse proxy. "nomDuNAS.ndd.tld" ne marche pas pour atteindre DSM il faut impérativement autre chose du style "dsm.ndd.tld".

Cordialement

oracle7😉

Lien vers le commentaire
Partager sur d’autres sites

Il y a 11 heures, oracle7 a dit :

En tous cas ce qui est sûr c'est, d'expérience, que l'on ne peut pas utiliser le nom du NAS dans le domaine que l'on utilise pour l'atteindre via le reverse proxy. "nomDuNAS.ndd.tld" ne marche pas pour atteindre DSM il faut impérativement autre chose du style "dsm.ndd.tld".

Bonjour @oracle7,
Il était peut-etre là mon probème...

le nom de mon NAS (netbios) est ARES et mon domaine est ARES.ndd.tld c'était peut-être ça le soucis.

Lien vers le commentaire
Partager sur d’autres sites

Il y a 13 heures, oracle7 a dit :

*.ndd.tld.    CNAME    ndd.tld.
ndd.tld.    A    @IP locale NAS-ARES (192.168.64.10) (qui supporte le reverse proxy)
ndd.tld.    NS    ns.ndd.tld.
ns.ndd.tld.    A    @IP locale Routeur (??? 192.168.64.1)(qui supporte le DNS Server)
NAS-ARTEMIS.ndd.tld.    A    192.168.64.11
NAS-CHRONOS.ndd.tld.    A    192.168.64.12

Cette config m'a l'air plus simple. Il faut que je test.

A default, je ne veux pas que ndd.tld renvoie vers ARES (NAS1) mais plus vers mon routeur (ZEUS)
Donc si j' adapte :

ROUTEUR-ZEUS.ndd.tld.   A    192.168.64.1
NAS-ARES.ndd.tld.       A    192.168.64.10
NAS-ARTEMIS.ndd.tld.    A    192.168.64.11
NAS-CHRONOS.ndd.tld.    A    192.168.64.12

*.ndd.tld.    CNAME    NAS-ARES.ndd.tld.

ndd.tld.          A    @IP locale ROUTEUR-ZEUS (192.168.64.1)
ndd.tld.         NS    ns.ndd.tld.
ns.ndd.tld.       A    @IP locale Routeur (192.168.64.1)(qui supporte le DNS Server)


Les NETBIOS des NAS et ROUTEUR sont : ARES,ARTEMIS,CHRONOS et ZEUS pour le routeur.

Une erreur la dedans ? Tu en penses quoi @oracle7 / @.Shad.

 

Modifié par GrOoT64
Lien vers le commentaire
Partager sur d’autres sites

@GrOoT64

Bonjour,

Il y a 8 heures, GrOoT64 a dit :

A default, je ne veux pas que ndd.tld renvoie vers ARES (NAS1) mais plus vers mon routeur (ZEUS)

Sauf que tu sembles oublier que c'est ton NAS ARES qui porte le reverse proxy et non pas ton routeur !

Donc, pour moi, même si cet enregistrement est fonctionnellement bon et possible :

ndd.tld.   A   @IP locale ROUTEUR-ZEUS (192.168.64.1), cela ne marchera tout de même pas pour la raison invoquée précédemment.

Maintenant ce que j'en dis ...

Cordialement

oracle7😉

Modifié par oracle7
Lien vers le commentaire
Partager sur d’autres sites

  • 2 mois après...
Le 28/02/2017 à 13:53, Mic13710 a dit :

Bref, j'ai voulu aller au bout de la démarche.

Possédant un nom de domaine chez OVH et une IP fixe (Free), j'avais les ingrédients nécessaires pour me lancer dans l'aventure. Mon objectif était de :

  1.          pouvoir utiliser les mêmes url côté WAN et côté LAN,
  2.          héberger mon propre serveur DNS,
  3.          par la suite pouvoir m'affranchir des contraintes de ports en utilisant le reverse proxy qui est dispo en natif sur nos NAS depuis DSM 6.0.

Bonjour @Mic13710

Beaucoup de points communs avec mon installation. Cela fait un moment que je voulais exploiter ton post de la page 2 de ce super tuto de @Fenrir.

Ce qui me titillait c'était cette histoire de "glue" que je n'avais pas employé lors de la mise en place de mon serveur DNS et pourtant il fonctionnait bien ! Mais que se passerait-il si je mettait en place l'option glue ? J'ai fini par le faire ça fonctionne toujours bien ..sinon mieux mais c'est subjectif. Et j'ai plusieurs questions 😃

Tout d'abord les points communs entre nos deux installations :

Domaine OVH, IP fixe Free, j'héberge mes zones locale et publique, je suis SOA et NS, j'utilise les mêmes url côté WAN et LAN, et  le reverse proxy pour ne pas avoir à mettre le port dans l'url.

Les divergences :

Dans la config : L'utilisation de l'IPV6 pour pouvoir accéder à mes zones (locale et privée ) sur mes deux NAS accès aux zones nas2 avec l'IPV4 du réseau (par la redirection du port 53 vers celui-ci) et  accès direct aux zones nas1 avec l'IPV6 du nas1.


Dans la mise en place : Je ne suis pas passé par les serveurs dns d'OVH ni fait de zone dans mon espace OVH. J'ai directement mis dans la section DNS SERVEURS de mon espace OVH: mon ns principal (DNS serveur) et mon serveur secondaire (pris chez Hurrrican Electric,  fournisseur de DNS secondaire gratuit que j'avais trouvé). 1ère question : peut-être ma mémoire me joue des tours....est-ce que l'usage des serveurs d'OVH et la mise en place d'une zone sont nécessaires??                       

Comme dit plus haut, je n'ai pas fait usage de l'option glue . J'ai vu que l'option glue était nécessaire si tu n'utilises pas les serveurs dns d'OVH et pourtant ça fonctionnait. C'est l'objet de ma deuxième question : dans ton cas cette option était-elle vraiment nécessaire?

 J'ai également été surpris par l'usage "temporaire" du serveur de Fenrir comme dsn secondaire. J'ai essayé de supprimer ma zone secondaire mais ça met le pagaille et mon domaine s'écroule.

Alors troisième question qui pourrait répondre à la seconde : Est-ce que c'est l'option glue qui fait que le dsn secondaire peut-être détruit sans crainte pour le principal ??? est-ce que le glue est une sorte de sauvegarde de ta zone chez OVH qui remplacerait le dns secondaire??

J'hésite à supprimer HE et tes réponses vont m'aider dans un sens comme dans l'autre. 

Deux remarques sur zonemaster pour finir :

J'ai un reverse DNS IPV4 chez Free, le reverse DNS IPV6 n'est pas implémenté chez eux, j'ai vu qu'il y avait qq demandes dans des forums. J'ai fait une zone inversée avec l'enregistrement PTR en IPV6 avec une zone slave sur HE et sur le deuxième nas mais zonemaster me met toujours le warning : "Le serveur de noms ns.ndd.ovh a une adresse IP (2a01:e34:.......) sans enregistrement "PTR" correspondant." C'est donc bien à Free de le faire 😅.

Un point que le glue à changé c'est un autre warning sur zonemaster : "Le serveur de noms ns.ndd.ovh a une adresse IP (2a01:e34:.......) qui est inconnue de la zone parente" (approximativement, car de mémoire). Cet avertissement à disparu. Ce qui est curieux c'est qu'au tout début je n'avais pas ce warning, il est apparu soudainement le mois dernier.

En tout cas merci à toi pour ton retour sur ce développement personnel du tuto DNS Serveur.....même si certains parleront de déterrage 😉

Modifié par Jeff777
Lien vers le commentaire
Partager sur d’autres sites

Lorsque ta zone publique est chez ton registar, l'enregistrement GLUE est automatique puisque ton domaine est inscrit dans les serveurs DNS du registar.

Lorsque tu héberges à la fois ta zone publique et ton serveur DNS, il faut indiquer aux serveurs externes où est situé le serveur DNS pour ton ndd. C'est le rôle de l'enregistrement GLUE qui en fournissant l'adresse IP de ton serveur DNS permet de faire le lien entre ton registar (hébergeur de ton ndd) et ton serveur DNS.

il y a une heure, Jeff777 a dit :

dans ton cas cette option était-elle vraiment nécessaire?

A vrai dire, je n'en sais rien. Je l'avais mis en place dès le début, une fois mes zones fonctionnelles. Mais ça fonctionnait aussi sans. C'est juste à mon sens de rendre plus rapide la résolution des noms et surtout d'éviter des boucles.

il y a une heure, Jeff777 a dit :

J'ai directement mis mon ns principal (DNS serveur) et secondaire (chez Hurrrican Electric

Tu aurais pu (dû) installer ton serveur principal chez toi et le secondaire chez HE car si les services HE tombent en panne, ton ndd est injoignable. Tu me diras que c'est la même chose chez OVH, mais là le service est payant donc on peut penser qu'il est plus stable.

il y a une heure, Jeff777 a dit :

est-ce que l'usage des serveurs d'OVH et la mise en place d'une zone sont nécessaires?? 

Non. Tes serveurs DNS peuvent être où tu veux. S'ils ne sont pas chez OVH (ton cas), la zone chez eux n'a aucune utilité puisqu'elle ne sera pas utilisée pour la résolution des ndd.

Il y a 1 heure, Jeff777 a dit :

J'ai également été surpris par l'usage "temporaire" du serveur de Fenrir comme dsn secondaire. J'ai essayé de supprimer ma zone secondaire mais ça met le pagaille et mon domaine s'écroule.

Tant que ton serveur principal est fonctionnel et que tu ne fais pas appel au secondaire, tu peux très bien te passer de ce dernier. Les demandes se font d'abord sur le principal, puis s'il n'est pas dispo, sur le secondaire, etc.. Si le secondaire est absent, les requêtes qu'il devrait traiter ne seront pas résolues.

En réalité, l'usage "temporaire" du serveur de Fenrir a été permanent, jusqu'à ce que Free ait eu la bonne idée de changer mon IP. Le serveur secondaire hébergé chez lui ne s'est pas mis à jour et ça à mis comme toi un patacaisse pas possible avec certains ndd qui pouvaient être résolus et d'autres pas. N'ayant pas réussi à le contacter rapidement, j'ai basculé ma zone chez OVH où je l'ai gardée depuis. Il a fallu cependant que je supprime l'enregistrement GLUE et j'ai dû faire intervenir OVH car je n'arrivais pas à le supprimer.

Il y a 1 heure, Jeff777 a dit :

Est-ce que c'est l'option glue qui fait que le dsn secondaire peut-être détruit sans crainte pour le principal ???

Pas vraiment non. La preuve juste au dessus.

Il y a 2 heures, Jeff777 a dit :

J'ai un reverse DNS IPV4 chez Free

Je n'en n'ai pas.

Il y a 2 heures, Jeff777 a dit :

sans enregistrement "PTR" correspondant." C'est donc bien à Free de le faire

C'est effectivement le propriétaire qui doit le faire.

 

Lien vers le commentaire
Partager sur d’autres sites

il y a une heure, Mic13710 a dit :

Tu aurais pu (dû) installer ton serveur principal chez toi et le secondaire chez HE

Je me suis peut-être mal exprimé, mais c'est ce que j'ai fait bien sûr. J'ai corrigé comme cela : "J'ai directement mis dans la section DNS SERVEURS de mon espace OVH mon ns principal (DNS serveur) et mon serveur secondaire (pris chez Hurrrican Electric,  fournisseur de DNS secondaire gratuit que j'avais trouvé)"

Merci pour ces détails. J'en conclue qu'il faut garder le DNS secondaire chez HE si je ne veux pas voir mon domaine s'écrouler.

Par contre je n'avais pas compris que tu avais aussi déclaré celui de Fenrir dans l'option glue. Je n'ai pas celui de HE dans l'option glue et je ne sais pas bien ce que cela ajouterai si je le faisais.

Lien vers le commentaire
Partager sur d’autres sites

Le 16/04/2020 à 08:02, .Shad. a dit :

Avant de rapatrier sur pfSense, j'avais 2 serveurs DNS, un sur le NAS et un (bind9) sur raspberry (esclave de celui du NAS), et chacun redirigeait vers sa propre instance de Pi-hole, qui redirigeait ensuite vers les DNS de FDN. 

Hello @.Shad., suite à ta remarque sur un autre fil (Authelia) au sujet des possibles problèmes de DNS que j'ai, j'ai jeté un oeil à ce tuto pour mieux comprendre les DNS. Avant d'éventuellement tenter de déployer DNS server, il y a un truc qui m'échappe.

Comment intégrer dans cette "configuration DNS" un bloqueur comme Pi-Hole ou AdGuard Home qui tourne sur un raspberry pi différent du NAS ?

J'essaye de comprendre, mais sans y parvenir... Voici ma configuration :

  1. mon routeur, une freebox pop avec :
    1. IP extérieure fixe, et un domaine perso chez OVH qui pointe dessus
    2. IP locale : 192.168.1.1
    3. ports 80 et 443 ouverts et redirigés vers le reverse proxy
    4. serveur DHCP, avec comme DNS l'ip locale du Raspberry Pi hébergeant AdGuard
  2. un Raspberry Pi :
    1. IP locale : 192.168.1.10
    2. SWAG comme reverse proxy
    3. AdGuard comme serveur de DNS bloquand les pub
    4. les DNS d'AdGuard sont ceux de la FDN
  3. un NAS :
    1. IP locale : 192.168.1.20
    2. des services comme Drive de Synology accessible sur drive.mondomaine.fr
    3. ...et pas encore de serveur DNS (mais si je suis ici, j'y pense 😉

 

Donc si je suis le tuto et mets en place le cache et la zone locale via DNS server sur le NAS, où et comment intégrer le raspberry pi avec Adguard dans la chaîne ?

Merci d'avance pour vos conseils et explications qui me permettront d'y voir clair.

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.