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é il y a 1 heure1 h 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