.Shad.

Comme dit @Jeff777, c'est qui tu veux, ça peut être FdN et Cloudflare aussi. Tant que c'est dans le domaine publique. En fait rien ne t'empêche de mettre l'adresse du RPI pour les DNS du RT même, mais dès que ton RPI sera déconnecté ou en train de rebooter, il ne pourra plus résoudre les adresses. Je ne vois pas l'intérêt, à moins que tu veuilles filtrer ce qu'envoie éventuellement ton routeur vers Synology. Selon moi c'est plus de problèmes potentiels qu'autre chose.

Ajout d'un guide succinct pour fail2ban et de remarques suite à celles de @Einsteinium

Une seule et même application peut écouter sur un port donné. Il faudra donc que NextDNS écoute sur un autre port que le 53.

Un lien intéressant pour connaître la différence entre DoT (DNS-over-TLS) et DoH (DNS-over-HTTPS) : https://www.cloudflare.com/learning/dns/dns-over-tls/ Si on héberge déjà une zone locale (ce qu'on appelle faire du split horizon) il faudra que NextDNS écoute sur un autre port que le 53 si sur le même hôte, sinon sur un autre périphérique, dans une VM ou un conteneur en macvlan, ça devrait le faire. 😉

Tu devrais pouvoir trouver des choses intéressantes par ici : https://github.com/search?q=synology+downloadstation

Tu ne perds aucun blocage, car ce qui se passe c'est éventuellement qu'une application X envoie des données au périphérique Y depuis le périphérique Z, tout ça en local. Dès que ça doit accéder au domaine public, ça passera forcément par Pi-hole, car ton DNS local ne saura pas résoudre (à condition de bien avoir défini des redirecteurs dans DNS Serveur, ce qui est normalement le cas, sans redirecteur le serveur résout récursivement les domaines et donc n'a pas plus besoin de passer par Pi-hole).

A ta place je ne fixerais pas l'IP WAN du RT mais je ferais une réservation d'IP dans la Livebox pour lui attribuer l'IP en question. Pour le sous-réseau 192.168.2.0/24, si tu n'arrives pas à libérer la case DNS du serveur DHCP, je laisserais tel quel, donc le RT pousserai sa propre IP comme serveur DNS à ses clients, dans DNS Server je mettrais l'IP du Pi-hole comme redirecteur. Dans Pi-hole, je mettrai les upstream DNS (FdN et Cloudflare dans ton cas) dans DNS 1 et 2.

La convention de nommage n'est peut-être pas la même, voir ce lien qui décrit comment nommer ses fichiers pour maximiser les chances d'identification automatique : https://support.plex.tv/articles/naming-and-organizing-your-tv-show-files/

C'est un peu réducteur de dire ça. Si j'ai juste besoin d'un NAS qui fait simplement office de serveur de fichiers, ou de destination de sauvegarde, un J conviendra tout à fait... Il faut juste connaître son besoin. Récemment j'ai pris un DS118 pour en faire une destination de sauvegarde car j'ai trouvé cette occasion à 40€, ce qui était une très bonne affaire, sinon j'aurais sûrement pris un J neuf. 🙂

A toi. Pour ta question, c'est assez simple. Tu n'as visiblement pas laissé la box attribuer une IP sur le WAN de ton RT, tu l'as configuré en manuel. Et tu as mis l'IP de la box pour les DNS du routeur. Donc quand il cherche à résoudre un domaine, il demande à la box. Sauf qu'en-dessous tu as décidé de configurer manuellement les DNS, donc il ne va pas demander à la box, mais à FdN puis Cloudflare si FdN ne répond pas suffisamment vite. Et le DHCP dit aux clients sur l'interface LAN d'utiliser le routeur comme serveur DNS, donc ce qu'il y a sur 192.168.2.1:53, a priori ta zone DNS locale via DNS Serveur qui occupe ce port.

Aucune idée, n'ayant pas de RT je ne peux pas t'aider. Sinon tu fais : DNS local -> Pi-hole -> Internet au lieu de Pi-hole -> DNS local -> Internet.

Un renouvellement tous les mois c'est étrange, un certificat Let's Encrypt c'est tous les trois mois que ça se renouvelle, si laissé en automatique. Pour ma part je n'ai pas de souci avec Drive, qui utilise un certificat wildcard Let's Encrypt avec le NDD Synology renouvelé automatiquement dans DSM. Pas de message qui me précise que le certificat a changé. Sinon tu peux créer un certificat autosigné, ils peuvent avoir une durée "éternelle" (plusieurs années), la première fois il te dira que le certificat n'est pas fiable, car non émis par une autorité de certification (vu que c'est toi qui le crée). Pour une utilisation locale c'est amplement suffisant.

Pourquoi tu passes le DHCP sur le NAS alors que ta box est totalement paramétrable ? La discussion d'avant concernait un utilisateur dont la box est totalement bridée (comme la vaste majorité des box FAI), tu peux très bien laisser la Freebox gérer tout ça.

C'est ce que donne Pi-hole quand il bloque une pub, il ne modifie pas la mise en page comme le fait un adblocker sur navigateur. Les Upstream DNS sont les redirecteurs, Pi-hole consulte ses listes de blocage, bloque ce qu'il doit, puis transfère la requête aux upstream DNS. Pi-hole ne fait pas de résolution récursive, il ne va pas lui-même interroger les serveurs DNS racine pour connaître l'IP d'un domaine, il transfère à l'upstream DNS qui se charge du reste. Si tu as une zone locale, je te conseille de mettre : - l'IP du pi-hole comme serveur DNS pour le DHCP. - Mettre en Upstream DNS 1 l'IP du NAS qui héberge ta zone locale (dans ton cas, vu que tu as une zone esclave sur ton autre NAS, tu peux mettre en DNS 2 l'IP du deuxième NAS). - Dans DNS Server, mettre en redirecteur les DNS dont tu te sers pour la résolution publique (FdN, Cloudflare, Google, ton FAI, etc...). PS : Je ne vois rien d'anormal sur les graphiques et les valeurs renvoyées.

Dans l'ultra majorité des cas on va effectivement s'en servir ainsi, mais pourquoi l'obliger ? je pourrais très bien vouloir que cela ne serve qu'à certains périphériques (qui rentreraient manuellement l'adresse du routeur comme serveur DNS). J'insiste, l'obliger c'est clairement un raccourci à ne pas emprunter, on devrait être libre de mettre ce qu'on veut. Plus globalement, je ne comprends pas le succès qu'ont les routeurs Synology. Le rapport fonctionnalités/prix est risible. Pour le même prix on peut avoir un vrai pare-feu et une borne Unifi. 😕 @oracle7 Est-ce que tu as essayé de stopper le paquet DNS Server pour voir si la case était toujours grisée comme l'a suggéré @Jeff777 ?

Regarde dans ce fil de discussion le message de johnk.dev.null : https://community.synology.com/enu/forum/17/post/69726 Essaie via Telnet les commandes qu'il donne. Synology garde dans /etc.defaults les fichiers de configuration originaux en cas de problème. Donc il fait un backup de l'existant au cas où, l'écrase par le fichier par défaut, et tue le processus SSH. Essaie ensuite de te connecter en SSH via ton utilisateur ou root.

Et ils appellent ça un événement ? 😅

Faut pas tronquer le début de phrase !

Non non, ce que je dis c'est que si SRM grise cette case car tu as une zone locale hébergée sur ton RT, c'est anormal. Je n'ai aucune idée si c'est la cause ou pas, je donne juste une piste. 😉 Le fait de mettre ta zone DNS locale sur le RT a tout à fait son sens. À mon avis ça doit être autre chose. Mais aucune idée de quoi.

Je n'ai pas de RT, mais je ne vois pas pourquoi tu serais obligé de fournir son IP à ses clients DHCP. Il doit y avoir un réglage quelque part qui grise cette case. Je suis tombé sur cette impression d'écran : Si c'est parce que tu héberges une zone DNS sur le RT que c'est grisé, ça n'a pas de sens, c'est une zone que tu pourrais très bien ne pas vouloir diffuser via DHCP et que des périphériques s'y connectent uniquement par adressage statique côté client.

Tu peux te remettre en automatique parfois derrière et ça refonctionne, ça m'arrive de le faire de temps en temps.

J'ai des livraisons assez rapides depuis la FNAC (Belgique), certes sans commune mesure avec Amazon Prime. Mais 2 jours je trouve ça correct. 🙂

Bonjour, On aime bien que les nouveaux membres se présentent, en précisant a minima leur matériel et leur niveau en informatique et réseau. Ca permet d'adapter nos réponses. Pour tes questions : A ma connaissance non, à moins de tout transférer sur Google Drive (j'imagine que tu utilises Google Photos ?), dans ce cas-là je crois qu'il y a moyen de monter un dossier partagé avec le contenu de Google Drive. Mais Google ne permet pas facilement d'archiver ses photos et les télécharger ? Je ne pense pas que ce soit possible, on parle de deux logiciels qui n'ont rien à voir. Pour une expérience proche (j'insiste sur proche, car Google Photos est largement au-dessus de la mêlée), tu as Moments de Synology (reconnaissance faciale, tri chronologique), sinon Photo Station est plus classique (gestion par dossier principalement). A savoir que DSM 7 fusionne ses deux applications photos pour n'en faire qu'une : Synology Photos (Moments avec quelques adaptations importées de Photo Station).

Tu n'as pas joué avec les permissions des utilisateurs entre temps ? Si pas, tu peux toujours tenter un reset mode 1 du NAS : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS#t2 Voir sur la page ce que ça implique.

Juste un truc, je ne comprends pas pourquoi vous souhaitez faire passer votre routeur ou modem par le Pi-hole ? Je trouve ça contre-productif, je trouve que ça a plus de "bon sens" de ne pas faire pointer les requêtes du périphérique qui fournit la connexion Internet sur un élément du réseau interne. D'autant que vous me diriez que votre Pi-hole est installé sur une serveur d'entreprise avec une redondance d'alim, de processeur, etc... je dis pas. Mais il n'y a pas plus fragile qu'un Raspberry Pi, surtout si vous avez installé l'OS sur une carte SD. Donner aux clients l'IP du Pi-hole comme serveur DNS via le DHCP, oui, forcer le DNS du routeur ou modem sur le Pi-hole, je ne vois pas l'utilité. @Jeff777 à vérifier les autres options, si pas, tu supprimes le contenu du volume monté : etc-pihole.