Hello,

Je suis perdu, le contexte :

NextDNS est configuré uniquement via Tailscale (DNS global, remplacement activé). Le tout via Docker.
Appareils : 3 Apple (macOS/iOS), 2 NAS Synology (DSM), tous connectés et fonctionnant sur Tailscale.

Dans NextDNS :
• Le trafic DNS apparaît à partir de 4 adresses IP alors que seuls 3 appareils Apple sont identifiés.
• Aucun trafic DNS n'apparaît pour les deux NAS Synology ou je ne sais comment le voir.

Les appareils Apple utilisent Apple Private Relay ; NextDNS affiche un message à ce sujet, mais celui-ci est ambigu et n'explique pas clairement l'attribution des adresses IP/appareils.

Si Private Relay a un impact, il affecte probablement uniquement les appareils Apple, et non les NAS Synology.

Tailscale expose la configuration DNS uniquement au niveau global et ne fournit aucune visibilité par appareil sur l'utilisation réelle du DNS.

Résultat : je ne sais pas si NextDNS couvre l'ensemble de mes machines

Comme je bosse sur un projet utilisant Tailscale, ton sujet m'a interpellé en ai discuté avec la LLM qui me donne la main et voilà ce qu'il en ai ressorti en espérant que cela puisse t'éclairer :

Pourquoi NextDNS “voit” 4 IP mais seulement 3 Apple

🔍 Ce qui se passe réellement

Apple Private Relay :

• intercepte une partie des requêtes DNS + HTTP(S)

• les fait sortir via des egress Apple (Cloudflare / Akamai / Apple)

• masque l’IP source réelle

• parfois split le trafic :

  • une partie passe par le DNS “système”

  • une autre ne passe PAS par ton NextDNS

👉 Résultat :

• NextDNS voit :

  • des IP Apple relay

  • parfois plusieurs IP pour un seul device

• Le message NextDNS est volontairement flou car Apple ne documente pas précisément le mapping

🧠 Conclusion
➡️ Les 4 IP ≠ 4 machines
➡️ Ce sont des sorties Apple Relay, pas des hôtes réels

Pourquoi les NAS Synology n’apparaissent PAS

Et là on arrive au point clé 👇

⚠️ Les NAS n’utilisent probablement PAS NextDNS

Cas les plus fréquents sur DSM :

1. ❌ Le NAS utilise :

   • le DNS du LAN

   • ou /etc/resolv.conf généré par DSM

   • ou un fallback IPv6

2. ❌ Le trafic DNS du NAS :

   • passe en dehors de Tailscale

   • ou passe par Tailscale mais ne fait aucune requête DNS observable (cache, peu d’activité)

3. ❌ Tailscale DNS ≠ garantie d’usage réel

   Tailscale impose un DNS, mais ne force pas chaque process à l’utiliser

🧠 Point fondamental
➡️ Tailscale DNS est déclaratif, pas coercitif

Réponse à la question centrale

“Je ne sais pas si NextDNS couvre l’ensemble de mes machines”

👉 Réponse honnête : NON, il n’en a aucune certitude

Et actuellement :

• ❌ Apple = couverture partielle (Private Relay)

• ❌ NAS = probablement hors périmètre

• ❌ Tailscale = aucune visibilité par device

  🧭 Recommandations claires (par ordre de maturité)

  ---

  🟢 OPTION 1 — Vérification factuelle (indispensable)

  Sur chaque NAS Synology :

  cat /etc/resolv.conf
  

  Puis :

  nslookup google.com
  

  ➡️ Vérifier vers quel DNS ça sort réellement

  ---

  🟢 OPTION 2 — Désactiver Apple Private Relay (si objectif = contrôle DNS)

  Sur Apple :

  • iCloud → Private Relay → OFF

  💬 Sans ça :

  • aucun DNS central ne peut être fiable

  • NextDNS, Pi-hole, AdGuard = tous aveugles partiellement

  ---

  🟡 OPTION 3 — Forcer NextDNS par appareil (recommandé)

  Au lieu de “DNS global Tailscale” :

  • Installer NextDNS client :

    • sur macOS

    • sur iOS

    • sur DSM (possible via script / container sidecar)

  ➡️ Là, NextDNS tagge chaque appareil
  ➡️ Plus de doute
  ➡️ Plus de mapping fantôme

  ---

  🟡 OPTION 4 — Architecture propre (niveau Rahan 🧠)

  DNS ≠ VPN ≠ Privacy

  • Tailscale : transport

  • DNS : local-first

  • Apple Private Relay : OFF sur machines de confiance

  👉 Sinon :

  • Il empile des couches qui s’aveuglent mutuellement

  ---

  🧩 Synthèse ultra-courte à transmettre à ton ami

  Le problème n’est pas une erreur de config.
  C’est l’interaction normale entre Apple Private Relay (opacifiant), Tailscale DNS (non coercitif) et NextDNS (observateur passif).

  Tant que Private Relay est actif et que NextDNS n’est pas installé par appareil, aucune vision fiable n’est possible.

Modifié le 3 janvierle 3 janv. par RAHAN-31

Hello,

Merci beaucoup pour ton retour complet 😀

Je suis d'accord avec toi, l'option #3 me semble meilleure. Question, est-ce qu'ajouter les DNS/DoH au routeur permettrait de passer par NextDNS en local ?

KeizerSauze

👉 Réponse courte : OUI… mais seulement sous conditions strictes.
👉 Réponse honnête : ça ne résout PAS Apple Private Relay, et ça ne garantit pas 100 % de couverture sans coercition réseau.

On déroule proprement.

---

🧠 Principe général : DNS au routeur = point de centralisation

Configurer NextDNS au routeur (DNS classique ou DoH) signifie :

• Tous les clients qui respectent le DNS du LAN

• et qui ne contournent pas le DNS
  👉 passeront par NextDNS

📌 C’est une centralisation, pas une garantie absolue.

---

✅ Ce que ça couvre VRAIMENT

🟢 Appareils “normaux”

• NAS Synology

• PC / Linux

• VM / containers

• IoT

• Services système classiques

➡️ OUI, ils passeront par NextDNS si :

• DHCP du routeur = DNS unique

• pas de DNS hardcodé

• pas de DoH local actif

👉 Dans ce cas, NextDNS verra clairement le trafic (IP = routeur ou subnet).

---

🟡 NAS Synology (cas précis DSM)

• DSM respecte le DNS LAN

• mais :

  • peut avoir fallback IPv6

  • peut cacher l’origine (cache agressif)

  • ne “tagge” pas l’appareil dans NextDNS

👉 Résultat :

• trafic visible

• mais non attribuable finement par machine

✔️ Couverture fonctionnelle
❌ Traçabilité par device

---

❌ Ce que ça ne résout PAS

🔴 Apple Private Relay (point bloquant)

Apple Private Relay :

• court-circuite DNS + HTTPS

• sort via Apple (Cloudflare / Akamai)

• ignore totalement :

  • DNS du routeur

  • DoH du routeur

  • DNS Tailscale

  • Pi-hole

  • NextDNS

👉 AUCUNE config routeur ne peut forcer ça.

📌 Donc :

• Apple + Private Relay = angle mort DNS

• même avec NextDNS au routeur

➡️ Obligation :

• Private Relay OFF
  ou

• accepter une visibilité partielle

---

🔴 DoH / DoQ côté client

Si un appareil :

• utilise DoH intégré (Firefox, Chrome, Apple)

• ou un client NextDNS local

• ou un resolver embarqué

👉 il bypass le routeur

Sauf si tu fais…

---

🧱 Le seul moyen de “forcer” réellement (niveau expert)

🔥 DNS coercitif au routeur

1. Bloquer tout DNS sortant

   • UDP/TCP 53

   • DoH (443 vers resolvers connus)

2. Autoriser uniquement :

   • routeur → NextDNS (DoH)

👉 Là :

• tout DNS est capturé

• tout contournement échoue

⚠️ MAIS :

• Apple Private Relay casse quand même le modèle

• certaines apps refusent de fonctionner

• maintenance plus lourde

➡️ Approche “souveraineté”, pas grand public

---

🧭 Interaction avec Tailscale

Important à se rappeler :

• Tailscale DNS :

  • annonce un DNS

  • ne force rien

• DNS routeur :

  • centralise LAN

  • n’affecte pas le trafic encapsulé Private Relay

👉 Les deux sont complémentaires, mais aucun n’est coercitif seul.

---

🧩 Synthèse

🔹 Mettre NextDNS au routeur améliore fortement la couverture locale, surtout pour les NAS et machines non Apple.
🔹 Ça ne résout pas Apple Private Relay, qui contourne totalement le DNS.
🔹 Pour une vision fiable :

• soit désactiver Private Relay

• soit installer NextDNS par appareil
  🔹 Routeur DNS = centralisation
  🔹 Client NextDNS = traçabilité
  🔹 Private Relay = opacité assumée

---

🧠 Recommandation finale

Si l’objectif est savoir qui fait quoi :

• ❌ Private Relay

• ✅ NextDNS par appareil

• 🟡 DNS routeur en complément

Si l’objectif est juste filtrer globalement :

• ✅ NextDNS au routeur

• 🤷 accepter les angles morts Apple

J'utilise la plateforme de DNS personnalisés d'Adguard et il y a bien une option pour bloquer iCloud Private Relay.

Je viens de faire un test sur un des iPhone de mes enfants et le filtrage DNS de Adguard est bien pris en compte avec DoH actif sur le routeur en prime.

Pas de réglage forcé sur le terminal et pas d'application Adguard non plus.

Idem pour l'option de préchargement des pages de Chrome qui force leurs DNS et contourne le filtrage du réseau local.

Merci

Hello,

J’ai quelques questions sur Tailscale :

1. J'ai envoyé un fichier de mon iPhone à mon NAS Synology #1, Tailscale est installé via Contain Manager > Impossible de savoir ou est le fichier

2. J’ai tenté d’installer le paquet officiel sur mon NAS #2, à l’exécution du paquet j’ai un message qui me dit que ma clé n’est pas valide…

3. J’ai tenté l’envoi de mon iPhone à mon iPad, j’ai vu le fichier sur le lockscreen, impossible de mettre la main dessus

4. J’ai installé Mullvad VPN, je peux choisir l’exit node par machine sous macOS, iOS & iPadOS, je ne peux rien faire sous DSM / Contain Manager

Merci d’avance

KeizerSauze

PS #1: je pensais qu’il n’y avait qu’un seul Exit Node, à priori ce n’est pas le cas ou c’est lié à Mullvad ?

<Slt @KeizerSauze , je vais te répondre que sur la partie que je pense maîtriser... donc hors univers Apple et Mullvad VPN.

Lorsque tu es sur ton UI web de TailScale [TS], l'ensemble de tes machines doivent être sur le même Tailnet et donc être toutes "connected" et administrable dans le même parc machines.
Tu ne dois pas toucher à l'exit Node qui ne doit te servir qu'au cas ou tu voudrais que cela soit le device sur lequel tu l'actives qui devient la porte d'entrée pour internet. Normal que tu ne puisses pas l'activer/désactiver sur le NAS puisque sans son internet tu ne peux plus le voir. ^^
Donc chaque device mobile peuvent activer l'exit Node mais pas les autres.
Pour ce qui est de la visualisation de ton fichier... fait un essai hors TS, repère bien les répertoires depart/arrivée et refait la même chose sous TS tu dois obtenir le même résultat.

Pour aller plus loin dans la vérification :

- Pour vérifier réellement l’usage DNS sur le NAS, il faut faire un test direct (ex. cat /etc/resolv.conf puis nslookup vers un domaine) pour voir vers quel serveur DNS il résout réellement.
- Installer un client NextDNS par appareil (ou configurer explicitement le resolver sur DSM) donne une meilleure traçabilité que de s’appuyer uniquement sur Tailscale DNS global.

Ce qui compte, c'est le chemin pour y arriver... pas l'arrivée... quoique ;-)

Modifié le 6 janvierle 6 janv. par RAHAN-31