[TUTO] DNS Server

[Fenrir]

Préambule

L'objectif de ce tutoriel est de vous aider à mettre en place votre propre serveur DNS en interne (dans votre réseau local).

Pour ce qui est de l’intérêt de disposer d'un serveur DNS en interne, voici quelques exemples :

• c'est plus fiable : vous n'êtes plus dépendant de la (non) fiabilité des DNS de votre opérateur (cf pannes d'Orange et de Free par exemple)
• c'est plus fiable (bis) : vous n'êtes plus soumis aux mensonges des DNS de votre opérateur (cf panne d'Orange et filtrage étatique)
• c'est plus rapide : grâce aux mécanismes de cache, vous ferez moins de requêtes DNS vers Internet
• c'est plus confortable : ça vous permet, par exemple, d'éviter de faire du loopback ou encore d'adresser vos équipements interne avec un nom au lieu d'une IP
• et enfin, ça vous permettra de remplacer une bonne partie des fonctions de QuickConnect (il faudra juste ouvrir les ports) et donc de couper ce dernier

C'est surtout les 2 derniers points qui devrait vous intéresser car en remplaçant le loopback et Quickconnect vous gagnerez en sécurité, en fiabilité, en confort et en performances.

Il ne s'agira pas d'un guide sur le protocole DNS, il y aurait beaucoup trop de choses à détailler (bien plus que sur mes précédents tuto combinés). Je vais donc prendre pas mal de libertés sur les termes employés afin de faciliter ma rédaction et votre compréhension. Pour la même raison, je serai assez avars en détails et en explications.

Gardez juste à l'esprit qu'Internet repose sur 2 protocoles : BGP et DNS. Quand l'un des 2 attrape froid, tout Internet tombe malade (c'est déjà arrivé, y compris récemment).

Si vous souhaitez gérer de A à Z vos DNS, renseignez-vous sur ces termes (c'est vraiment le strict minimum) : zone/resolver/XFER/glue/root/cache/split-horizon/pinpoint zone/DDNS/TTL/SOA/NS/A/AAAA/PTR/CNAME/TCP/UDP - et pour ceux qui s'intéressent à la sécurité : DNSSEC/DANE/HPKP/CAA.

Petite précision tout de même, la notion de "sous-domaine" qu'on voit un peu partout n'existe pas. L'adresse www.nas-forum.com est un domaine au même titre que nas-forum.com.

À la fin de ce tutoriel, vous aurez les éléments pour accéder à votre nas (ou à tout autre équipement) avec le même nom DNS que vous soyez chez vous, à distance via un VPN ou directement depuis Internet. Le DNS vous renverra à chaque fois la bonne adresse en fonction de votre emplacement.

Mais je préfère vous avertir tout de suite, le DNS est un sujet bien plus complexe qu'il n'y parait.

######################################################################################

Notes de lecture

Pour l'exemple, j'ai indiqué des valeurs fictives, il faudra donc les remplacer chez vous :

• fenrir.tuto : à remplacer par votre nom de domaine
• 192.168.0.2 : à remplacer par l'adresse IP privée de votre nas
• 192.0.2.3 : à remplacer par votre adresse IP publique (à ne pas confondre avec 192.168.x.y)
• www.fenrir.tuto : c'est un enregistrement d'exemple, vous pouvez en créer autant que nécessaire
• ns.registrar.externe : c'est le nom d'un serveur DNS qui fera office de serveur secondaire
• 1.2.3.4 : adresse IP d'un serveur qui fera office de serveur secondaire

nb : les exemples sont en IPv4, mais le fonctionnement en IPv6 reste identique (il faut juste changer les adresses et remplacer les A par des AAAA).

Ce tuto comporte 3 parties, par ordre croissant de difficulté :

• Cache DNS local : tout le monde devrait pouvoir y arriver en quelques cliques
• Zone DNS locale : cette partie devrait être abordable pour la plupart des utilisateurs
• Zone DNS publique : on change totalement d’échelle de difficulté ici, le principe est simple, mais la mise en œuvre peut être complexe

Il n'y a aucune raison technique qui nécessite de faire la dernière partie, elle est là pour illustrer un peu plus le fonctionnement d'une architecture DNS, mais elle n'est en aucun cas nécessaire.

Certains points ne seront pas abordés ou détaillés, mais il peut être utile, voir nécessaire de les mettre en œuvre, en particulier les zones de type "esclave" et inverses.

Vous trouverez aussi pas mal d'informations complémentaires dans les commentaires, en particulier un retour très complet de @Mic13710 :  --> cliquez ici <--

######################################################################################

Pré requis

Savoir faire des requêtes DNS, ça peut paraitre bateau dit comme ça, mais ce n'est pas aussi simple qu'un ping. Vous pouvez utiliser la commande "nslookup", elle est présente par défaut sur la plupart des systèmes (y compris les Synology). Je ne vais pas vous faire une doc, mais les 3 commandes importantes sont :

• demander les informations de zone : nslookup -querytype=SOA fenrir.tuto 192.168.0.2
• demander la liste des serveurs de zone : nslookup -querytype=NS fenrir.tuto 192.168.0.2
• demander la valeur d'un enregistrement : nslookup www.fenrir.tuto 192.168.0.2

Pour utiliser votre NAS comme serveur DNS, pour devrez modifier la configuration DNS de vos clients, le plus simple reste de le faire avec votre serveur DHCP, si vous utilisez une "box", ça ne sera surement pas possible, dans ce cas, utilisez le serveur DHCP du NAS (il est intégré par défaut dans tous les Synology depuis DSM 6.0 ou sous forme de paquet dans les versions précédentes).

Si vous souhaitez héberger la résolution de votre domaine du point de vu d'Internet (donc être SOA et/ou NS), vous devez avoir une adresse IP fixe et disposer d'un second serveur DNS ailleurs.

######################################################################################

Cache DNS local

Un cache DNS est un serveur DNS qui garde en mémoire les précédentes résolutions qu'il a du faire afin d'y répondre plus vite lors de nouvelles demandes. L'autre intérêt de disposer de son propre cache local et de s'affranchir des pannes et autres filtrages des serveurs DNS de votre opérateur Internet. Ce cache joue alors le rôle de "résolveur".

C'est très rapide à mettre en place et ça consomme très peu de ressources, donc faites-le !

Commencez par installer et lancer le paquet DNS Server.

Puis allez dans :

Et configurez les options comme suit :

nb : j'utilise les DNS de FDN comme "redirecteurs", car ils sont fiables et respectent votre vie privée (contrairement à ceux d'OpenDNS par exemple), mais vous êtes libre d'utiliser les serveurs de votre choix, voir aucun, votre serveur se chargera alors de l’ensemble des résolutions (ce n'est pas toujours très efficace).

Il est primordial de cocher la case "Limiter le service IP source" et de bien configurer son contenu. Si vous ne le faites pas, tout le monde pourra utiliser votre serveur DNS pour résoudre n'importe quel enregistrement, votre NAS en souffrira et sera peut-être utilisé pour des attaques vers d'autres cibles.

Dans la "Liste d'IP source", mettez ces adresses :

Maintenant il faut tester que ce serveur fonctionne correctement, le plus simple reste de lui poser une question : nslookup nas-forum.com 192.168.0.2

Vous devriez obtenir une adresse IP (au moment de la rédaction de ce tuto, c'est 5.196.244.24).

• Si vous n'obtenez pas de réponse ("timeout" ou encore "No response from server") c'est que vous n'arrivez pas à contacter le serveur DNS, dans ce cas il faut vérifier qu'il est bien lancé, que c'est la bonne IP, que le firewall autorise bien le trafic ...)
• Si vous obtenez une réponse du type "Query refused" c'est qu'il y a bien un serveur DNS en face, mais qu'il refuse votre question, donc soit vous lui parlez mal, soit il n'est pas autorisé à vous répondre (cf "Liste d'IP source" juste au dessus)

Si le serveur vous répond correctement, vous en avez terminé pour le cache DNS et vous disposez maintenant d'un résolveur DNS local utilisable par tous vos clients (y compris ceux en VPN).

N'oubliez pas de modifier votre serveur DHCP pour qu'il renseigne vos clients sur l'adresse de votre serveur DNS.

######################################################################################

Zone DNS locale

Une zone DNS est un fichier dans lequel sont inscrits les enregistrements DNS d'un domaine. Un des avantages d'une zone locale c'est qu'elle n'a pas besoin d'exister sur Internet. Un usage courant de ce type de zone est de s'en servir pour donner des noms à ses équipements, plus simple facile à retenir que des adresses IP.

Vous pouvez par exemple créer une zone "maison", elle sera fonctionnelle dans votre réseau pour faire nas.maison, routeur.maison, ... Vous pouvez aussi créer un domaine enfant du premier (par exemple cam.maison qui contiendrait vos caméras IP, comme salon.cam.maison) et qui sera soumis à d'autres restrictions.

• Néanmoins, je vous déconseille fortement d'utiliser un nom de domaine que vous ne possédez pas car ça risque de créer des problèmes de sécurité.
• Préférez l'usage d'un domaine que vous possédez, si vous n'en avez pas ça ne coute que quelques euros par an (on en trouve à 1€/an), même si vous n'avez pas prévu de vous en servir sur Internet.

nb : il ne faut jamais utiliser le suffixe ".local", même en interne

Si vous ne souhaitez pas acheter un nom de domaine, vous pouvez utiliser sans risques les noms suivants : .test, .example, .invalid et .localhost

Pour la suite, j'ai utilisé le gTLD .tuto car il n'est pas enregistré au moment de la rédaction de cet article, mais rien ne dit qu'il ne le sera pas quand vous lirez ces lignes.

Allez dans :

Puis "Créez" => "Zone master" :

Et configurez-la comme suit :

Pour la "Liste d'IP source", mettez ceci :

Puis sélectionnez votre zone et faites "Modifier" => "Enregistrement de ressource" :

Enfin, créez une (ou plusieurs) ressource(s) du type CNAME :

Par exemple :

Vous devriez obtenir ça :

Le nom www.fenrir.tuto renverra l'adresse de ns.fenrir.tuto, donc l'adresse IP privée de votre nas.

Voici un exemple plus complet :

Il se lit comme suit :

1. fenrir.tuto de type NS : cet enregistrement indique que le serveur de nom (NS) pour le domaine "fenrir.tuto" est ns.fenrir.tuto
   • ici j'ai gardé le nom créé par Synology, ns.fenrir.tuto, mais si vous souhaitez que votre NS s’appelle ratatouille.fenrir.tuto, aucun soucis (il faudra juste modifier le type A correspondant)
2. nas.fenrir.tuto : il s'agit d'un "alias" qui renvoi la même chose que ns.fenrir.tuto
   • c'est plus parlant que ns pour un nas
3. wordpress.fenrir.tuto : un autre alias
   • pour l'utiliser avec WebStation (vhost) ou avec un reverse proxy
4. tv.fenrir.tuto : j'ai donné un nom à la tv
   • on se demande bien pourquoi faire ?
5. mail.fenrir.tuto : adresse du serveur de messagerie pour vos utilisateurs
   • c'est un type A (pas un alias) car c'est important pour les enregistrements MX
6. ns.fenrir.tuto : l'adresse du serveur DNS (l'enregistrement de la première ligne)
   • il doit toujours s'agir d'un type A
7. fenrir.tuto : il indique l'adresse du serveur de messagerie pour les autres serveurs de messagerie
   • un MX doit pointer sur un type A

Vous pouvez voir que j'ai indiqué plusieurs enregistrements avec le même nom mais un type différent ou encore plusieurs noms différents qui pointent sur la même IP, c'est parfaitement valable et ne pose aucun problème si vous restez cohérents. J'aurai aussi pu mettre des IP publique pour "nommer" des ressources externes (par exemple donner un nom à un autre nas hébergé je ne sais où). Notez aussi que les TTL ne sont pas tous les mêmes.

nb : avant d'aller plus loin, faites des tests avec "nslookup" pour vérifier que tout fonctionne correctement.

C'est terminé pour cette zone, mais nous allons lui associer une vue pour plus de sécurité et de contrôle.

######################################################################################

Vue DNS locale

Pour simplifier, considérez qu'une vue DNS est un mécanisme permettent de donner des réponses différentes en fonction de l'adresse des clients. Ça revient à peu près à disposer de plusieurs serveurs DNS au même endroit, mais avec des données et des droits différents.

Nous allons créer une vue pour nos clients locaux (ou vpn), ce n'est pas une obligation, mais ça simplifiera les choses pour la suite tout en ajoutant un peu de sécurité.

Allez dans :

Puis "Créer" :

Ici on va limiter cette vue aux seuls clients locaux (ou vpn).

Enfin, on sélectionne les zones qui seront dans cette vue :

nb : encore une fois, il faut tester que tout fonctionne avant de continuer.

Voilà, vous avez maintenant un serveur DNS local pleinement fonctionnel pour les rôles de cache, de résolveur et de serveur de zone.

Mais vous pouvez faire pleins d'autres choses, tout dépend de votre niveau de connaissances et de compétences comme par exemple du filtrage de contenu indésirable (pub, facebook, malware, ...), du MitM, un annuaire, ...

nb : vous pouvez aussi créer une vue dédiée à vos clients VPN afin qu'ils puissent atteindre votre nas via son adresse en 10.x (cf tuto vpn) simplement en entrant un nom DNS, il faudra juste bien penser à le limiter aux adresses VPN (en 10.x).

######################################################################################

Zone DNS publique

Jusqu'à présent on ne s'est occupé que de nos clients locaux ou VPN mais pour permettre à un client sur Internet de résoudre une adresse, il faut créer une zone publique.

Ici vous avez 3 possibilités.

• Utiliser des serveurs sur Internet, généralement ceux de votre bureau d'enregistrement, en tant que SOA et NS, dans ce cas la suite n'est pas nécessaire.
• Utiliser des serveurs sur Internet, généralement ceux de votre bureau d'enregistrement, en tant que NS, mais vous êtes SOA, ça peut être assez complexe à faire
• Être à la fois serveur SOA et NS, c'est le choix de l'indépendance, mais c'est aussi le plus complexe à faire

Ici je vais prendre l'exemple d'un auto hébergement complet, vous êtes donc SOA et NS pour votre domaine. À ne faire que si vous commencez à être bien à l'aise avec les DNS ou pour tester et apprendre.

Cette opération n'est pas triviale et nécessite plusieurs prérequis, pas toujours accessibles, je recommande donc de choisir la première option, elle devrait convenir à la plupart d'entre vous.

Le résultat sera le même du point de vue résolution, cette étape n'est en aucun cas obligatoire pour se passer de QuickConnect ou pour avoir des réponses différentes entre le LAN et Internet.

nb : il faut une adresse IP fixe et un autre serveur DNS pour la suite, si ce n'est pas votre cas, ceci ne fonctionnera pas, ou mal.

Allez dans :

Puis "Créez" => "Zone master" :

Et configurez-la comme suit :

nb : 192.0.2.3 est une adresse publique (réservée pour les documentations), à ne pas confondre avec 192.168.x.y

On garde le même nom de domaine, mais on déclare l'IP publique pour le serveur DNS principal, par contre on ne limite pas le service à certaines IP source.

Vous devriez obtenir ceci :

La nouvelle zone est nommée fenrir.tuto(2).

On va devoir faire un peu plus de réglages pour qu'elle soit fonctionnelle :

Ici on doit bien faire attention aux différentes valeurs (par exemple l'adresse mail doit exister, mais attention, elle sera visible de tous) :

nb : les valeurs ci-dessous peuvent ne pas convenir à tous les usages, adaptez-les si besoin

Ensuite on procède comme précédemment pour créer les ressources :

Cette fois ci, www.fenrir.tuto renverra l'adresse IP publique de votre NAS.

(edit) : ce n'est pas dans la capture, mais il faut aussi créer un enregistrement pour le "naked domain", le domaine lui même, ça doit être un type A

• Nom : fenrir.tuto
• Type : A
• TTL : à vous de voir
• Information : 192.0.2.3

Quelques remarques sur le TTL :

• Un TTL (Time To Live) est la durée de validité d'une ressource, passé ce délai, les serveurs DNS vont supprimer cette entrée de leurs caches
  • si vous mettez une valeur trop petite, vous ne profiterez pas du cache
  • si vous mettez une valeur trop grande, les modifications mettront du temps à se propager
  • ne mettez JAMAIS la valeur 0 sous peine de ne plus jamais pouvoir corriger un enregistrement ou qu'il ne fonctionne pas (selon les implémentations, 0 peut être considéré comme invalide, donc l'enregistrement sera rejeté ou pire, il sera considéré comme n'expirant jamais)

######################################################################################

Vue DNS publique

Comme pour la zone locale, nous allons associer une vue à cette zone publique, cette fois-ci destinée à nos clients Internet.

Allez dans :

Puis faites "Créer" :

Et sélectionnez bien la zone publique :

Vous devriez obtenir ceci :

• Les clients avec des adresses privées se verront proposer le contenu de la vue LAN, donc de la zone fenrir.tuto
• Les autres clients se verront proposer le contenu de la vue WAN, donc de la zone fenrir.tuto(2)

Il faut maintenant permettre aux clients sur Internet d'accéder à votre serveur.

Ouvrez l'interface de votre routeur pour créer 2 règles de redirection de port :

• port 53 en TCP vers votre nas
• port 53 en UDP vers votre nas

Il faudra aussi autoriser ces ports dans le firewall de votre NAS.

Vous avez maintenant votre zone publique, que tout le monde peut consulter, sauf que personne n'en connait l'adresse !

######################################################################################

NS public

Pour que votre serveur DNS, donc votre NAS, soit référencé, il faut le déclarer dans les serveurs de votre TLD (pour un .fr, c'est l'AFNIC). C'est à faire auprès de votre bureau d'enregistrement (probablement là où vous avez acheté votre domaine).

C'est une opération administrative, qui est soumise à certains contrôles techniques. Donc avant de commencer, vous devez vérifier que votre zone publique est bien configurée.

Le plus simple et de faire le test sur https://www.zonemaster.fr/

Choisissez l'option "Test d'un domaine non délégué" et remplissez les différents champs comme suit :

Vous ne devez avoir aucune erreur (les avertissements ne devraient pas être bloquants), mais si vous avez suivi le tuto, vous allez en avoir au moins une :

• Une architecture DNS se doit de disposer d'au moins 2 serveurs de nom (NS) pour une zone donnée. Il vous faut donc configurer un autre serveur DNS qui contiendra les mêmes valeurs que celles présentent dans votre NAS (le serveur secondaire recevra les données depuis votre NAS).

nb : un DNS secondaire (on parle plutôt d'esclave ou slave en anglais) est un serveur qui contient une copie du fichier de zone, il ne peut pas en modifier le contenu

Le plus simple pour ça et d'utiliser les serveurs DNS de votre bureau d'enregistrement, certains permettent de faire DNS "secondaire". Si ce n'est pas le cas il faudra trouver un autre serveur DNS acceptant de jouer ce rôle pour votre zone.

• Si vous avez plusieurs adresses IP publiques, il vous suffit de monter un autre serveur derrière l'une des autres adresses
• Vous pouvez aussi demander à un ami ou à de la famille de le faire (enfin, vous allez devoir le faire pour eux ), s'ils ont un Synology vous savez déjà comment vous y prendre
• Si vous êtes coincés, je peux faire office de NS secondaire, au moins le temps de la mise en place de votre architecture (envoyez moi un MP pour en discuter)

Vous avez donc 3 choses à faire :

• Autoriser un autre serveur DNS à se synchroniser sur votre NAS (transfert de zone)
• L'ajouter comme serveur NS de la zone
• Et lui indiquer l'adresse de votre NAS pour qu'il se mette à jour (on parle ici de quelques ko maximum à transférer)

Rendez-vous dans

Sélectionnez la zone publique :

Puis cliquez sur "Modifier" => "Paramètres de zone" :

Activez le transfert de zone :

Et spécifiez les adresses des serveurs qui vont faire office de DNS secondaire :

Une fois ceci fait, il faut déclarer ces serveurs comme NS dans votre zone (toujours la zone publique de votre NAS) :

Indiquez l'adresse du serveur secondaire :

Vous devriez avoir ceci :

Et enfin, configurez votre DNS secondaire pour qu'il se synchronise avec votre SOA (votre NAS), il suffit de créer une zone de type "slave" et de lui indiquer les bons paramètres.

Une fois tout ceci en place, refaites le test zonemaster en indiquant vos 2 serveurs NS (votre NAS et le DNS de votre prestataire/ami/...) :

Idéalement vous devriez obtenir un résultat similaire à celui-ci :

nb : jusqu'à présent, tout ce que vous avez configuré n'est valable que pour vous et n'a aucun impact pour le reste des utilisateurs sur Internet, si vous avez un doute, c'est le moment ou jamais de faire pause.

Si et seulement si le test est concluant (pas d'erreur bloquante), il faudra vous rendre une dernière fois sur l'interface de votre bureau d'enregistrement afin d'y spécifier les adresses de vos serveurs NS. L'opération prend en général quelques jours pour être appliquée partout.

nb : vous serez peut être amenés à déclarer un enregistrement de type GLUE pour que ns.fenrir.tuto soit reconnu et puisse fonctionner comme NS de la zone fenrir.tuto, le problème est assez simple, si vous ne le voyez pas, documentez-vous avant de continuer

Dernière précision, les vues isolent les zones, c'est le principe, donc si vous voulez voir apparaitre un même enregistrement dans les différentes vues, il faut le créer dans les différentes zones (comme le www.fenrir.tuto de mon exemple).

Modifié le 29 novembre 2017 par Fenrir

[Einsteinium]

Tutoriel intéressant... il me servira un jour, un bon gain de temps.

[Fenrir]

Il risque de ne pas attirer grand monde car c'est un sujet obscure pour la plupart de gens, c'est dommage car ça leur permettrait de se passer de QuickConnect et de simplifier les accès à leurs ressources.

On verra bien.

[gaetan.cambier]

Pour te rassurer, j'utilise le dns server chez moi avec plusieurs vues
C'est un tutoriel utile, mais comme toujours, faut vouloir le mettre en place.

[Mic13710]

Encore un super tuto, didactique et très complet comme toujours. Merci Fenrir.

Etant chez free, le loopback me facilite déjà bien les choses. Pas d'urgence donc.

J'ai bien un nom de domaine et une IP fixe. Un serveur DNS pourrait probablement m'apporter un plus, mais je n'ai même pas tenté la moindre démarche à ce jour. Non seulement je n'y ai pas vu d'intérêt immédiat, mais sa mise en oeuvre semblait trop compliqué. Je n'aurai désormais plus aucune excuse pour ne pas au moins essayer de le mettre en place, même si ça n'a toujours pas l'air d'être simple !

Il me reste maintenant à trouver le temps de le faire, le courage pour me lancer .... et 20 boites de paracétamol. Autant dire pas pour tout de suite.

[nexius2]

bon tuto, je viens de le lire histoire de...et je me suis rendu compte que je n'avais jamais limité les sources (bon en local l'interet est moindre...)

j'ai aussi appris pour la version publique, je ne m'était jamais penché sur la question ni posé d'ailleurs.

instructif.

merci

[Fenrir]

Il y a 3 heures, Mic13710 a dit :

Etant chez free, le loopback me facilite déjà bien les choses. Pas d'urgence donc.

Le truc avec le loopback, c'est que le trafic entre tes clients du Lan doit passer par le CPU de la box avant de revenir dans le lan. Les perfs sont donc moindre et les trames peuvent être altérées (spoofing ou routage asymétrique ou mauvaise ip source ou ... selon la techno employée).

Avec le DNS, pas de question à se poser, le trafic va là où il doit aller.

[Mic13710]

Tu as certainement raison. Quoique vu l'usage très restreint que je fais du loopback (pratiquement que pour CloudStation de mon PC portable, sinon pour les essais de mes connexions externes), le CPU de la box ne doit pas être beaucoup sollicité .

Ceci étant dit, le serveur DNS pourrait tout de même me simplifier la tâche pour au moins ne plus avoir à jongler entre connexions internes et externes.

[Fenrir]

Personne n'a testé mon tuto pour le moment ?

@Mic13710 Dans ton cas niveau perf, comme c'est ton er-x qui fait le travail, tu ne devrais effectivement pas avoir bcp de pertes, mais ça reste dommage.

[Mic13710]

il y a 24 minutes, Fenrir a dit :

Personne n'a testé mon tuto pour le moment ?

Il est encore un peu vert, il vient tout juste de sortir. Laisse lui au moins le temps de murir ! .

Vu les contraintes de départ (nom de domaine, adresse fixe) et les opérations à mener pour la mise en oeuvre ça ne va surement pas se bousculer au portillon, ou en tout cas beaucoup moins que pour le tuto sur le serveur VPN.

[Fenrir]

Quand je vois le nombre de personnes qui s'arrachent les cheveux avec QuickConnect ... c'est pour ça que j'ai fait ce tuto (maintenant ce n'est peut être pas clair pour tout le monde, comme c'est un sujet que je maitrise, je n'ai peut être pas été assez didactique).

[Mic13710]

Oh non, rassures-toi, à première vu ton tuto à l'air bien charpenté et il semble tout à fait compréhensible. Je pourrais t'en dire plus une fois que je l'aurai exploité.

C'est sûr que question mise en oeuvre, quickconnect est très rapide. C'est après que ça se gâte. Le serveur DNS, c'est très exactement le contraire.

Comme je l'ai dit, le DNS n'est pas une priorité pour moi puisque le loopback fait bien son boulot. Je veux bien essayer mais il faudra que j'y consacre du temps, beaucoup de temps. Car si c'est évident pour toi comme pour beaucoup d'autres sur ce forum, ça l'est franchement moins pour moi (en clair, je ne maitrise pas). Donc ce sera quand ... je me sentirai le courage d'affronter le côté obscur de la force.

[Invité]

Il y a 2 heures, Fenrir a dit :

Personne n'a testé mon tuto pour le moment ?

Ce week end pour moi... trop d'infos à digérer ! ;o)

Mais encore une quetsion bete: Est ce qu on le faire sur un ERX ? Si oui, ca ne serait pas plus judicieux ?

[Fenrir]

il y a 2 minutes, Hedy a dit :

Est ce qu on le faire sur un ERX ?

Sans les vues oui, mais pas via l'interface et même avec la CLI, tu vas devoir indiquer directement les instructions "custo" (options).

Si tu veux tout faire avec ton routeur il faudra installer bind et modifier les confs à la main.

il y a 4 minutes, Hedy a dit :

Si oui, ca ne serait pas plus judicieux ?

Pas nécessairement, chacun voit midi à sa porte comme on dit.

L'avantage de le faire avec le nas c'est que tu as une interface graphique simple qui permet de couvrir la plupart des besoins.

Chez moi c'est effectivement mon routeur qui fait ça, mais je n'ai pas besoin des vues (j'ai 2 vrais serveurs DNS dans des datacenters pour les zones publiques), donc en local, c'est un simple DNS local et mon NAS me sert de DNS cache (quand il ne sait pas, il demande au routeur).

Si tu veux le faire avec le routeur (DNS local + cache, sans les vues), il faut juste ajouter ceci :

set service dns forwarding cache-size 1001
set service dns forwarding listen-on switch0
set service dns forwarding name-server 80.67.169.12
set service dns forwarding name-server 80.67.169.40
set service dns forwarding options host-record=nas.mon.domaine,192.168.0.2
set service dns forwarding options host-record=truc.mon.domaine,192.168.0.3
set service dns forwarding options neg-ttl=300
set service dns forwarding options listen-address=192.168.0.xxx

 

[Invité]

Un truc de plus pour le we ! - merci

[Bavich]

Super tuto. Avant de mettre en prod, est-il possible de tester avec Virtual DSM?


Sent from my iPhone using Tapatalk Pro

[PiwiLAbruti]

Le 29/01/2017 à 22:04, Fenrir a dit :

[...] c'est dommage car ça leur permettrait de se passer de QuickConnect et de simplifier les accès à leurs ressources.

Je pense que tu devrais en parler dès le premier paragraphe de ton tutoriel en expliquant qu'avoir son propre serveur DNS pour les accès locaux et distants est bien plus efficace que QuickConnect :

• pas de relai avec les serveurs de Synology (confidentialité, fiabilité, latences, ...),
• utilisation du même nom en local et distant (très pratique pour les applications mobiles, Cloud Station, accès distant via VPN, ...),
• pas besoin de loopback,
• gain de rapidité (même si peu perceptible par l'utilisateur),
• et j'en passe...

En gros il faut appâter avec du concret dès les premières lignes.

En ce qui me concerne, je pense le mettre en application pour remplacer ma configuration à base de dnsmasq. Je m'en sers pour de la résolution locale et surtout pour l'anti-pub avec des listes assez exhaustives comme http://winhelp2002.mvps.org/hosts.txt. Par contre je crains qu'il soit compliqué de l'appliquer à DNS Server.

[Einsteinium]

@PiwiLAbruti passé par le proxy server pour l'anti pub, je le fais sans utilisé le cache pour ma part, c'est invisible.

[PiwiLAbruti]

@Einsteinium : Je ne veux pas que le trafic http du LAN passe par le NAS et bloquer que http, donc Proxy Server n'est pas la bonne solution pour moi.

[Fenrir]

Le 31/01/2017 à 11:35, PiwiLAbruti a dit :

Je pense que tu devrais en parler dès le premier paragraphe de ton tutoriel en expliquant qu'avoir son propre serveur DNS pour les accès locaux et distants est bien plus efficace que QuickConnect :

Oui, je vais faire ça

Le 31/01/2017 à 11:35, PiwiLAbruti a dit :

Je m'en sers pour de la résolution locale et surtout pour l'anti-pub

Moi aussi, même les appli sur smartphone ont moins de pub

Le 31/01/2017 à 11:35, PiwiLAbruti a dit :

Par contre je crains qu'il soit compliqué de l'appliquer à DNS Server.

J’avais regardé, c'est techniquement possible mais pas à la portée de la plupart

Le 31/01/2017 à 11:42, Einsteinium a dit :

 passé par le proxy server pour l'anti pub, je le fais sans utilisé le cache pour ma part, c'est invisible.

Pas pour les pubs en https, sauf à faire du proxy explicite (ou du mitm)

Modifié le 1 février 2017 par Mic13710
enlevé une remarque devenue obsolète

[gaetan.cambier]

il y a 3 minutes, Fenrir a dit :

proxy explicite (ou du mitm)

j'avais essayer du mitm ... mais avec des plantage aléatoire de squid 

je réessayerai avec e2guardian peut-etre si ca fonctionne mieux ....

[antdid]

Merci pour ce tuto. Je pense que peuvent de personnes le suivent, car (personnellement) je le trouve plus complexe que les autres tutos (VPN ou sécurité du NAS par exemple).

 

J'ai suivi qu'une partie (pour l'instant en tout cas). La partie en local. 

 

Actuellement j'ai plusieurs domaines présents sur internet, alors que certains ne devraient pas être accessibles mais uniquement en local. 

J'ai donc fait une zone master avec mon nom de domaine, la vue LAN avec les adresses locales. Et la partie cache DNS Local.

Je me connecte en VPN ensuite, et essaye mon enregistrement. J'obtiens de chrome l'erreur "ERR_NAME_NOT_RESOLVED".

 

Du coup j'ai plusieurs questions par rapport à ce problème.

Est-ce qu'il faut faire la zone DNS publique pour pouvoir utiliser ma zone DNS local ?

Est-il possible d'avoir ma zone DNS local et de garder ma zone DNS actuelle pour les autres domaines ?

Et dans l'onglet paramètre du paquet DNS, il n'y a rien à paramétrer ?

[Fenrir]

il y a 7 minutes, Antwan a dit :

Merci pour ce tuto. Je pense que peuvent de personnes le suivent, car (personnellement) je le trouve plus complexe que les autres tutos (VPN ou sécurité du NAS par exemple).

Oui, d'où mon intro ;)

il y a 8 minutes, Antwan a dit :

J'ai suivi qu'une partie (pour l'instant en tout cas). La partie en local. 

dans 99% des cas ça suffit

il y a 11 minutes, Antwan a dit :

Je me connecte en VPN ensuite, et essaye mon enregistrement. J'obtiens de chrome l'erreur "ERR_NAME_NOT_RESOLVED".

Tu dois dire à ton client VPN d'utiliser ton serveur DNS, soit via DHCP, soit à la main (sous android en ipsec il faut le faire à la main, dans les paramètres de la conf ipsec, en bas)

il y a 8 minutes, Antwan a dit :

Est-ce qu'il faut faire la zone DNS publique pour pouvoir utiliser ma zone DNS local ?

non

il y a 8 minutes, Antwan a dit :

Est-il possible d'avoir ma zone DNS local et de garder ma zone DNS actuelle pour les autres domaines ?

oui

il y a 10 minutes, Antwan a dit :

Et dans l'onglet paramètre du paquet DNS, il n'y a rien à paramétrer ?

je ne suis pas chez moi pour vérifier, mais de mémoire il s'agit des TTL, si c'est ça les valeurs étaient OK

[antdid]

Merci pour le retour. Je vais configurer le DHCP (je pensais que c'était un prérequis pour une utilisation externe, et je voyais pas l’intérêt du DHCP pour le DNS ).

 

Pour ceux qui utilisent OpenVpn voici la configuration à utiliser : dhcp-option DNS DNS_IP_ADDRESS

[antdid]

J'ai toujours mon problème, ou peut-être pire 

Maintenant j'ai "DNS_PROBE_FINISHED_BAD_CONFIG" et plus d'accès sur l'extérieur. 

Voici les modifications effectuées :

• Configurer le NAS avec le DHCP. Maintenant mon NAS a une IP fixe attribuée par le DHCP. 
• Sur le DHCP, j'ai mis d'utiliser le serveur DNS avec l'IP fixe du NAS.
• Dans la config d'openVPN, j'ai ajouté la ligne "dhcp-option DNS IP_FIXE_NAS".

Pour info, le lien vers le tuto VPN Server est mort.