[TUTO] DNS Server

[Fenrir]

Il y a 2 heures, Antwan a dit :

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

Il fallait deviner que cette erreur provenait de chrome ?

Tu as du louper un truc, ou je n'ai pas été clair sur un point (bon ça c'est sur, je ferai des retouches de temps en temps pour rendre le tuto plus accessible).

• Tu as bien configuré le cache DNS ?
  • nslookup nas-forum.com adresse.ip.privée.du.nas
• Ton client, qui je suppose est en vpn, à le droit d'accéder au nas avec l'ip indiquée et les ports DNS ?
  • essaye en mettant l'adresse de terminaison vpn (10....)

Il y a 2 heures, Antwan a dit :

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

merci, c'est corrigé

[antdid]

Ah désolé, je n'ai pas reprécisé pour chrome. 

Problème résolu. C'était l'interface VPN dans le pare-feu sans les droits. Merci pour le retour.

J'ai également configuré les redirecteurs de la vue comme pour la partie cache DNS local du tuto, je ne sais pas si ça a un impact ou non.

 

[Fenrir]

il y a 10 minutes, Antwan a dit :

J'ai également configuré les redirecteurs de la vue comme pour la partie cache DNS local du tuto, je ne sais pas si ça a un impact ou non.

Oui ça a un impact, il vaut mieux éviter de le faire (sauf à bien connaitre le sujet).

[antdid]

D'accord, je vais remettre ça comme il faut et ça sera bon pour l'instant.

Prochaine étape remplacer quickconnect, mais pas pour tout de suite 

[Fenrir]

À chaque fois que je me relis, je trouve de nouvelles fautes ... c'est sans fin

[Fenrir]

Vu les difficultés rencontrées par certains pour mettre ce tuto en pratique (je les remercie d'essayer), j'ai fait quelques tests pour trouver un compromis plus simple techniquement (pas certain que ça soit plus simple à comprendre par contre ...).

En intro j'avais énuméré quelques termes que je recommandais fortement de rechercher.

Dans la liste on y trouve la notion de "pinpoint zone", c'est une technique que j'évite le plus possible d'utiliser car elle devient très lourde du point de vue administration dès qu'on commence à avoir de nombreux enregistrements.

Le principe est simple : pour chaque enregistrement pour lequel on souhaite avoir une réponse différente en fonction de l'emplacement du client, on créé une zone

En entreprise c'est très vite un enfer, mais pour un particulier, c'est peut être une planche de salut.

Voici un exemple :

• on part du domaine : fenrir.tuto
• on souhaites que :
  • depuis Internet ou le lan : mail.fenrir.tuto renvoi l'ip publique d'un service de messagerie => on créé l'enregistrement chez son prestataire comme d'habitude
  • depuis Internet, nas.fenrir.tuto renvoi l'ip publique de la box => on créé l'enregistrement chez son prestataire comme d'habitude
  • depuis le LAN, nas.fenrir.tuto renvoi l'ip privée de la nas => on créé une zone "nas.fenrir.tuto" avec comme seuls enregistrements :
    • nas.fenrir.tuto A 192.168.0.2
    • nas.fenrir.tuto NS nas.fenrir.tuto
  • depuis le LAN, tv.fenrir.tuto renvoi l'ip privée d'une tv => on créé une zone "tv.fenrir.tuto" avec comme seuls enregistrements :
    • tv.fenrir.tuto A 192.168.0.3
    • tv.fenrir.tuto NS tv.fenrir.tuto

Puis on recommence pour chacun des enregistrements.

Dit autrement, on créé tous les enregistrements qui doivent être accessibles depuis Internet chez son gestionnaire de domaine et pour ceux qui doivent renvoyer une autre adresse en local, on créé une zone dans le nas (une zone par nom).

En espérant que ça en aide certains.

Modifié le 4 février 2017 par Fenrir

[Invité]

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

 

Re,

En pleine étude sur le DNS via mon routeur, je m interroge. Pourquoi est-ce ton nas qui traite le cache et pas le routeur ? Pour une question de rapidité ? Espace ? Délocalisation sur 2 endroits si l un ou l'autre plante ?

 

J ai qd mm adapté tes lignes à ma config et j avais déjà fdn. ;0)

 

Concernant bind - il semblerait que je ne puisse le faire tourner sur l erx - nécessité de plus d espace.... d un autre côté - j'en ai pas l utilité mais en tant que bon geek bêta testeur, ca m aurait un peu plus.

[Fenrir]

Mon routeur ET mon nas font cache DNS.

C'est juste par principe, pas par besoin (ça reste un réseau domestique).

Pour l'installation sur ton erx, bind est un des rare serveur DNS capable de tout faire (zone+récursif+cache+split horizon), ce qui explique sont embonpoint, mais même si je suis certain qu'il rentre sur un erx si tu l'installes à la main (sans les dépôts), ça ne présente pas d'intérêt, mieux vaut le faire sur le NAS.

[Invité]

Ok - merci pour la précision.

[PiwiLAbruti]

Je viens de monter un DNS local sur mon DS109, ça marche parfaitement.

Il y aura quelques modifications à faire dans la capture d'écran "Création de la zone master" avec la mise à jour du paquet DNS Server (2.2.0-3032).

[Mic13710]

Edition du 11/01/2023 :

Veillez noter que ce fil à été créé il y a 5 ans. Certains chapitres sont maintenant obsolètes, notamment la partie concernant le certificat qui accepte le wildcard ce qui simplifie grandement sa mise en oeuvre.

Les images ne sont plus accessibles car l'hébergeur a fermé ses portes. Ce descriptif étant ancien et quelque peu dépassé, je les mettrai à jour seulement si quelqu'un m'en fait la demande.

J'ai conservé l'hébergement de ma zone publique à titre de test pendant quelque temps. Aujourd'hui cet hébergement est à nouveau chez OVH.

Pour info, lors du rapatriement de ma zone chez OVH, je n'ai pas réussi à supprimer l'enregistrement GLUE à partir de mon interface client. Il a fallu pour cela que je contacte OVH.

Mic13710

________________________________________

Après quelques semaines d’utilisation, je viens vous faire part de ma petite expérience pour la mise en place de mon serveur DNS et de ce qui en a découlé.

Tout d'abord je remercie Fenrir pour cet excellent tuto, et aussi (et surtout) pour son assistance lors de sa mise en oeuvre sans laquelle j'aurais sûrement abandonné. Il lui aura fallu beaucoup de patience et de bienveillance pour supporter un boulet tel que moi. Il est vrai que le sujet n'est pas des plus faciles quand on n'est pas de la partie. C'est mon cas.

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.

Il ne me restait plus qu'à trouver le courage et le temps, puis je me suis lancé.

Je ne vais pas m'étendre sur la zone DNS locale qui est largement documentée sur le tuto (mais j'y reviendrai plus loin) pour passer sur la partie publique.

L'idée étant de tester le tuto jusqu'au bout, j'ai opté pour la troisième possibilité : Être à la fois serveur SOA et NS c'est à dire le point 2 de mon objectif.

Tant qu'à être dans la mouise, autant s'y mettre carrément.

Mon compte chez OVH étant très basique (juste le nom de domaine) je n’ai pas la possibilité de créer un DNS secondaire. Et comme je n'ai pas non plus la possibilité de l'héberger ailleurs, c'est Fenrir qui m’a permis d'utiliser temporairement son domaine, le temps de la mise en place de mon serveur. Merci à lui.

Après quelques errements sur des problèmes de NS, A et CNAME qui bloquaient le processus (Fenrir saura de quoi je parle), j’ai enfin réussi à passer le test Zonemaster pour nos deux serveurs DNS.

Ne restait plus qu’à officialiser ces serveurs pour les faire connaître au monde entier.

Pour ceux qui sont chez OVH, il suffit d’aller dans l’onglet Serveurs DNS du domaine, de cliquer sur "Ajouter un serveur DNS", de rentrer l’adresse du serveur principal (c’est l’adresse de l’enregistrement NS de la zone publique), d’indiquer son IP publique fixe puis de valider. Faire de même pour le serveur DNS secondaire. La procédure devrait être similaire chez les autres fournisseurs.

Personnellement, j’ai rencontré un problème pour la mise en place du serveur de Fenrir. En effet, je n’ai pas pu faire l’enregistrement avec le nom du DNS et son adresse IP, chaque tentative se soldant par un échec. Il m’a fallu faire l’enregistrement en utilisant uniquement le DNS (sans l’adresse IP) et là c’est passé. Je n'ai pas compris pourquoi, mais si ça vous arrive vous pouvez essayer de faire de même.

Enfin, j’ai fait un enregistrement GLUE de mon serveur DNS pour qu’il soit diffusé all over the world. Chez OVH, onglet GLUE, bouton "DNS Ajouter". On renseigne les informations du DNS principal (les mêmes que précédemment) et on valide.

Une fois les serveurs DNS actifs, je n’avais plus besoin ni des enregistrements de zone que j’avais créé chez OVH ni des serveurs DNS d’OVH. Pour ces derniers, il m’a suffi de les supprimer dans l’onglet DNS (dans mon cas, il s’agissait de ns200.anycast.me et dns200.anycast.me). J’ai tout de même conservé les enregistrements de zone (juste au cas où j’aurais besoin de revenir en arrière ).

Mes enregistrements Serveurs DNS ressemblent maintenant à ça :

Pour info : puisque j’ai gardé mes anciens enregistrements, j’ai aussi un message dans la page Zone DNS qui m’informe gentiment que j'utilise les serveurs DNS que je viens d’activer (c’est rassurant) et que la zone que j’ai conservée n'est utilisable que si j’active les serveurs DNS d’OVH.

A noter que la mise en place définitive des serveurs est quasi immédiate chez OVH mais peut prendre quelques jours pour être diffusée. J’ai dû attendre 3 à 4 jours pour qu’ils soient enregistrés partout.

A ce stade, le tuto a été testé, le serveur DNS est fonctionnel et les points 1 (utilisation des mêmes url) et 2 (hébergement de mon serveur DNS) de mon objectif sont atteints.

Premières conclusions

Tout ça c’est très bien et à condition d’avoir correctement fait les redirections de ports du NAS et du routeur, ça fonctionne à merveille. Mais ça m’avance à quoi par rapport au loopback en natif chez free ?

Certes, je ne passe plus par le routeur (loopback) pour mes requêtes sur le LAN (qui se limitaient en réalité à CloudStation), mais en pratique ça n’a rien changé côté utilisation. Si j’indique mondomaine:5001 de l’intérieur ou de l’extérieur j’accède bien en https à mon NAS, comme avant. Pareil pour CloudStation et toutes les autres applis. J'utilise les mêmes url qu'avant et je suis toujours obligé d’indiquer des ports pour accéder aux différents services.

Oublier Quickconnect ? Je ne m’en servais pas de toute façon, donc sans intérêt pour moi.

Bref, il n'y a aucune différence palpable sur l'utilisation de mon NAS. En l’état, et exception faite qu'il s'agissait aussi de tester le tuto, le serveur DNS ne me sert à rien.

Pour que tout ce travail puisse avoir un impact concret sur mon utilisation de tous les jours, il fallait pousser plus loin la démarche en s'affranchissant notamment des contraintes de ports (point 3 de mon objectif).

En parallèle, j’avais aussi un soucis à résoudre avec les certificats Domoticz de mes deux Raspberry qui ne sont pas bien reconnus par mon navigateur, ce qui m'obligeait à faire des exceptions pour pouvoir m'y connecter. Et tant qu'à faire, c’eut été bien de pouvoir aussi y apporter une solution.

Et c‘est là qu’intervient le reverse proxy.

Reverse proxy

Une version simplifiée du proxy inversé (reverse proxy) est incluse dans DSM depuis la version 6.0. Elle se trouve dans le portail des Applications et elle est bien suffisante pour mon utilisation.

Pour commencer, j’ai modifié et complété mes enregistrements DNS pour y intégrer un certain nombre de domaines. Voici une partie de ces enregistrements.

DNS local :

 DNS publique :

Je n’ai pas mis tous mes enregistrements publiques car ça n’apporte rien pour la suite.

A noter : hormis le premier enregistrement NS dans la zone publique qui est l’adresse du DNS secondaire (Fenrir), tout ce qui est caché correspond à mon nom de domaine chez OVH.

Pour ceux qui suivraient ce tuto et qui utilisent le DNS publique de leur bureau d'enregistrement (points 1 et 2 du DNS publique du tuto de Fenrir), la démarche est la même : les enregistrements sont à faire dans la zone DNS du bureau d'enregistrement (internet).

Quelques explications sur les noms de domaine :

• audio, video, file, cam, get sont les noms que j’ai attribués pour accéder aux applications du NAS. Pour que ces noms soient utilisables à la fois sur le LAN et le WAN, ils sont enregistrés dans les deux zones DNS.
• domo accède à Domoticz sur le NAS, domo.s1 et domo.s2 à mes deux Raspberry sur lesquels tourne Domoticz. Ces noms sont enregistrés eux aussi dans les deux zones DNS pour être accessibles côté LAN et côté WAN.
• cam.bureau, cam.cuisine etc… sont les adresses pour accéder à mes caméras. Elles ne sont accessibles que sur le LAN (enregistrements dans le DNS local uniquement).
• sauvegarde c’est pour mon NAS de sauvegarde, routeur est suffisamment explicite, nas aussi, quant à tv1 c’est ma télé. Ces noms ne sont enregistrés que dans le DNS local.

A noter que domo.s1 et domo.s2 ne pointent pas vers des adresses IP de mon LAN mais vers mon nom de domaine. C’est important pour la suite.

Dans le portail des applications, j’utilisais jusqu'à présent les alias côté LAN (très pratique) mais c’est incompatible avec le DNS et le reverse proxy de DSM qui n'acceptent que des noms de domaine ou des IP. Je les ai donc désactivés et j’ai activé les ports DSM par défaut pour chaque application. J'aurais pu les modifier, mais ça n'aurait rien apporté en terme de sécurité, d'autant qu'ils ne sont pas accessibles de l'extérieur.

A noter qu’il n’est pas utile d’activer les ports https pour le proxy inversé comme nous le verrons par la suite.

Puis j’ai rempli les sources et destinations du proxy inversé comme ceci :

Côté source, exception faite de video, toutes les adresses en http sont uniquement sur le LAN. Elles utilisent le port standard (80). Les autres (https) sont dispos des deux côtés, LAN et WAN. Elles utilisent le port standard (443).

Côté destination, les adresses sont exclusivement en http vers les IP et les ports correspondants aux applications du NAS et aux autres équipements du réseau local (NAS de sauvegarde, Raspberry). Il est en effet inutile et contreproductif de doubler les chiffrements (une fois à la source, une autre fois à la destination).

Et pour que ça puisse fonctionner, j’ai dirigé dans le routeur le port 443 vers le NAS, et je l’ai ouvert dans le pare-feu du NAS.

Et là j’ai rempli mon dernier objectif : plus besoin d’indiquer des ports puisque tout passe par les ports standards http (80) ou https (443).

Maintenant, quand je rentre par exemple https:\\file.mondomaine côté LAN ou WAN, j’accède à File Station via l’adresse http:\\localhost:7000. De même, avec https:\\audio.mondomaine, j’accède à Audio Station via l’adresse http:\\localhost:8800.

Mais un des gros avantages que j’ai trouvé au serveur DNS combiné au reverse proxy c’est la possibilité d'accéder à mes Rasp en https sans utiliser leurs certificats.

En effet, si je rentre https:\\domo.s1.mondomaine, j’accède bien à Domoticz sur mon Raspberry 1, sans passer par le certificat Domoticz puisque le reverse proxy communique avec lui via une adresse en http. Le serveur DNS transfère l’adresse https non pas vers le Rasp mais vers le NAS comme on l’a vu plus haut et de là, c’est le reverse proxy qui met en relation le NAS avec le Rasp. C’est donc le certificat du NAS qui est sollicité.

Et voilà, tout devrait maintenant fonctionner comme prévu.

Hélas non. Il reste encore une dernière action à mener, c’est justement sur les certificats : ils ne fonctionnent pas correctement !

Certificats

Comme beaucoup ici, je suis chez Let’s Encrypt via le NAS et on ne peut pas dire que la documentation Synology soit foisonnante sur la manière de gérer ces certificats.

Il faut d'abord commencer par comprendre comment se comporte DSM avec les noms de domaine nouvellement créés. Lorsqu’une nouvelle source en https est créée dans le proxy inversé, DSM inscrit automatiquement le nom du domaine dans la rubrique "Pour" du certificat par défaut. On pourrait croire que ce nouveau domaine est pris en compte par le certificat, or il n’en n’est rien. Il s'agit seulement pour DSM d'associer un domaine à un certificat et en l'occurrence, c'est celui défini par défaut qui est choisi. Ce n'est en aucun cas une validation. Les seuls domaines couverts par le certificats restent le domaine principal et ceux inscrits dans le SAN (rubrique "Autre nom de l’objet"). Il n'y a aucun changement ni sur la validité, ni sur le périmètre de couverture du certificat.

Il faut donc éditer le certificat existant pour y inclure les nouveaux domaines, et comme DSM6.0 et au-delà permet de faire cohabiter plusieurs certificats, il sera peut-être nécessaire d’en rajouter.

En effet, alors que chaque certificat Let’s Encrypt peut gérer jusqu’à 100 SAN en natif, la rubrique "Autre nom de l’objet" du NAS n'accepte pas plus de 256 caractères ce qui peut être rapidement atteint selon le nombre de noms à saisir et leurs longueurs. D’où la nécessité de devoir créer plusieurs certificats. Cette limite est semble t'il contournable mais il faut pour cela passer en SSH pour modifier les paramétrages. Je ne le conseille pas.

On peut aussi les créer en externe (PC, MAC, Rasp, autre)  et les importer dans le NAS, mais on perd du même coup le renouvellement automatique et il faudra alors le faire manuellement tous les 3 mois ou moins.

Pour ma part, j’ai utilisé ceux proposés par DSM. Et puisque c'est possible et pour que ce soit plus clair, j’ai créé 3 certificats :

•          un par défaut que j'ai appelé "Principal" qui couvre les applis de base (CloudStation, VPN, mail serveur, ..),
•          un autre que j'ai appelé "Applications" qui couvre les applis DS (audio, video, file, cam, get ...),
•          et un autre que j'ai appelé "Domoticz" pour la domotique.

A partir de l'onglet "Certificats" du module "Sécurité" du panneau de configuration (vue ci-dessus), on peut soit créer un certificat, soit éditer un certificat existant. Dans les deux cas, il faut cliquer sur le bouton "Ajouter" et dans la page qui apparait on choisit soit "Ajouter un certificat", soit "Remplacer un certificat" et on sélectionne celui à remplacer.

Selon le choix, sur la page suivante on rempli ou on modifie la description du certificat puis on choisi "Procurez-vous un certificat auprès de Let’s Encrypt". Dans l’exemple ci-dessous, j’ai choisi de modifier mon certificat Domoticz.

En cliquant sur suivant, on arrive à la page des paramétrages. C’est la même, que ce soit pour une création ou une modification (les champs ne sont pas renseignés avec les données de l’ancien certificat).

Après avoir complété le nom de domaine (mondomaine) et l’adresse email valide, il faut renseigner la rubrique "Autre nom de l’objet" (le fameux SAN) avec tous les noms de domaine complets à couvrir, séparés par des " ; " . Exemple pour mon certificat Domoticz :

domo.mondomaine;domo.s1.mondomaine;domo.s2.mondomaine

Important : il faut que tous les noms de domaine soient valides. Pour cela, ils doivent impérativement avoir un enregistrement A ou CNAME dans le serveur DNS publique car Let's Encrypt vérifie l'existence de chaque nom. Si on indique dans le SAN un nom de domaine qui n’existe pas ou pas encore, le certificat ne sera pas créé.

A ce sujet, le message renvoyé par DSM en cas d’échec est assez déroutant. Au lieu de signaler qu'il y a un ou plusieurs domaine(s) qui n'existe(nt) pas, le message indique qu’il y a un problème sur le port 80 qui n'est pas ouvert. Comprend qui peut.

Une fois tous les certificats créés, il reste une ultime étape : leur attribution pour chaque nom de domaine et chaque application.

Pour cela, dans la page des certificats, il suffit de cliquer sur le bouton "Configurer", de choisir pour chaque ligne quel certificat est applicable puis de valider.

Cette opération terminée, tout fonctionne correctement, je n’ai plus de soucis avec mes connexions https.

Conclusion

La mise en oeuvre a été longue et laborieuse, avec beaucoup d'erreurs de ma part, d'incompréhensions parfois car le sujet est assez complexe, mais au final je suis très satisfait du résultat.

Objectif atteint.

Voilà. Je suis sûr qu’il y a beaucoup à redire sur ce que j’ai fait, qu’il y a certainement mieux à faire. Certes, je suis ouvert à toute proposition d’amélioration. Je souhaite en tout cas que ça puisse aider la communauté.

Modifié le 11 janvier 2023 par Mic13710
Message d'en-tête

[Fenrir]

Merci pour ton retour, c'est presque un tuto (voir plusieurs en même temps) à part entière .

J'avais effectivement prévenu que la gestion de la zone publique était autrement plus complexe que le reste, bravo à toi pour avoir relevé le défi avec succès.

Comme tu l'indiques, le DNS peut donner l'impression de compliquer les choses et sans reverse proxy et/ou plusieurs IP publiques l'intérêt est très limité pour la plupart des usages.

Modifié le 28 février 2017 par Fenrir

[Mic13710]

Je t'avais bien dit que je ferais un "petit" retour .

Bon, d'accord, je suis allé un peu loin, mais je pense que ça peut en aider certains après la mise en place de leur serveur DNS. C'est une bonne suite à ton tuto.

[antdid]

Merci pour ce retour, je pense que ça va aider pas mal de personnes :)

[nexius2]

encore aujourd'hui j'ai fais des modifs sur mon DNS OVH.... et ca me gonfle... j'ai de plus en plus envie d'avoir un DNS publique.

ya juste l'adressage fixe qu'il faut que je vois. il me semble que chez orange fibre c'est fixe mais je suis pas sur sur et en plus je demenage fin d'année. OVH me servant aussi de dynhost on ne peut pas s'appuyer la dessus?

ca me permettrais d'avoir un 2ieme DNS via un VPN ou un sous domaine :-)

 

[Fenrir]

Un serveur DNS (enregistrement NS) doit pointer sur un enregistrement direct (type A) et cet enregistrement doit être fixe (donc IP fixe). Donc un dynhost ou un vpn ne te servira à rien pour ça.

[Vanosmael]

J'ai encore besoin d'un petit éclaircissement..... mais d'abord félicitation pour le Tuto.

J'ai besoin exactement de la solution appelée "ZONE DNS LOCALE" et "VUE DNS LOCALE" pour une école où le serveur (server WEB de test) doit être accessible aussi bien en interne qu'en externe avec la même adresse. Je désire héberger le DNS en externe (OVH)  (du fait de l'instabilité des connexions Internet) mais quand même avoir un DNS server interne pour filtrer les sites des étudiants et ne pas les embrouiller avec deux adresses.

J'ai bien créé les résolutions vers les 2 DNS d'OPENDNS (et cela fonctionne bien avec le proxy-cache)

coté ZONE DNS LOCALE:
J'ai créé une zone avec le domaine (DOMAINE.COM) avec le NS par défaut et le CNAME vers le serveur interne

coté VUE DNS LOCALE:
J'ai créé une vue (LAN) avec le lien vers la zone DNS et j'ai décoché les redirecteurs

En externe, évidemment tout fonctionne

En interne, les sites autres que DOMAINE.COM sont tous OK et biens filtré, mais DOMAINE.COM ne fonctionne qu'avec l'enregistrement  renseigné dans le DNS LOCAL. Les enregistrements qui manquent dans ce DNS LOCAL ne sont pas recherchés dans le DNS hébergé chez OVH.   Comment puis-je faire pour faire une cascade vers OVH ..... ou dois-je réencoder directement tout ce qu'il y a en Public , en LOCAL.

Merci de votre aide.

 

[Fenrir]

il y a 6 minutes, Vanosmael a dit :

J'ai bien créé les résolutions vers les 2 DNS d'OPENDNS (et cela fonctionne bien avec le proxy-cache)

Je te déconseille d'utiliser OpenDNS, mais c'est un autre sujet.

il y a 7 minutes, Vanosmael a dit :

Les enregistrements qui manquent dans ce DNS LOCAL ne sont pas recherchés dans le DNS hébergé chez OVH.

C'est le principe

il y a 7 minutes, Vanosmael a dit :

Comment puis-je faire pour faire une cascade vers OVH

Tu ne peux pas

il y a 7 minutes, Vanosmael a dit :

ou dois-je réencoder directement tout ce qu'il y a en Public , en LOCAL

C'est une possibilité, mais il y a une autre manière de faire que j'ai expliquer dans les commentaires un peu plus haut (pinpoint zone) : http://www.nas-forum.com/forum/topic/55206-tuto-dns-server/?do=findComment&comment=1319318099

 

[Vanosmael]

Merci pour cette si rapide réponse....

1 - Opendns est dicté par la direction..... mais je vais essayer de négocier .

2 - je coince sur cette partie:

depuis le LAN, nas.fenrir.tuto renvoi l'ip privée de la nas => on créé une zone "nas.fenrir.tuto" avec comme seuls enregistrements :

• nas.fenrir.tuto A 192.168.0.2

• nas.fenrir.tuto NS nas.fenrir.tuto

Je vais donc dans Zone, et je crée la nouvelle zone avec le domaine FERIR.TUTO avec comme DNS principal 192.168.0.2... je limite le service IP source(cf TUTO) et je ne mets que deux enregistrements .

Je vais dans les vue et je crée une vue LAN avec la limitation et je sélectionne la zone.

Si c'est cela, le domaine ferir.tuto n'est jamais reconnue (même si j'enlève le restriction des sources..... HELP

Merci

 

[Fenrir]

S'agissant d'une école, les arguments CNIL et vie privée devraient suffire pour virer opendns ... (sauf si vous avez un contrat en accord avec le Privacy Shield).

Pour le DNS, si ton domaine est ecole.fr et que tu souhaites jouer avec truc.ecole.fr, il faut créer une zone truc.ecole.fr (avec le truc), bien entendu il ne faut pas créer un enregistrement truc.ecole.fr dans une autre zone du nas (et dans ton cas, ne créés pas du tout la zone ecole.fr dans le nas).

[Vanosmael]

OK.... mais je ne veux pas créer un sous-domaine, je veux rester sur le même domaine avec un nom de serveur nas.ecole.fr des deux cotés.

 

[Fenrir]

Premièrement, un sous domaine ça ne veut rien dire, nas.ecole.fr est un domaine à part entière, au même titre que ecole.fr ou que fr.

=>si tu souhaites que la réponse pour nas.ecole.fr soit différente entre Internet et l'interne, créés la zone nas.ecole.fr

[Vanosmael]

OK.... j'ai enfin compris ... Donc maintenant cela marche bien.

Dernier point..... pour remplacer Opendns , que conseilles-tu qui me permette d'avoir un petit reporting des blocages.

 

Merci de ta patience

 

[Fenrir]

Je n'ai pas de noms en tête, mais donner accès à 100% des données de navigation d'un ensemble de personnes à une entreprise tierce, qui plus est étrangère, notoirement connue pour insérer son propre contenu dans certaines pages et revendre les infos de ses clients (je ne sais pas si ça a changé suite au rachat par Cisco), dans le seul but de tenter de filtrer le trafic ne me parait être une bonne idée, surtout s'agissant d'une école. À la place des parents je porterais plainte ... ou du moins, je demanderais d'avoir accès aux contrats.

Vous pouvez parfaitement faire un filtrage similaire en interne (il existe plein de tuto), il est certain que ce n'est pas du clef en main et que ça demande un peu de travail, mais c'est tout de même bien plus propre (et ça sera plus rapide).

[Vanosmael]

T'as pas tord.... je vais me renseigner..... mais est-ce préférable que les étudiants aient accès au porno ?