Split DNS, SPF non aligné et publication d'un intranet

Mécanisme. Le domaine AD porte le même nom que le domaine public : les DC hébergent une zone auralis.fr faisant autorité pour tout le nom. Tout poste du siège interroge DC01 ou DC02, qui répondent avec leurs propres enregistrements et ne transmettent jamais la requête vers l'extérieur pour un nom dont ils sont autoritaires. Quand le prestataire a changé l'adresse publique de www.auralis.fr, la zone interne a continué à servir l'ancienne valeur. Le smartphone en 4G interroge le DNS public et voit la nouvelle adresse : d'où la différence de comportement. L'erreur de certificat et la page par défaut s'expliquent par le fait que l'ancienne adresse pointe désormais vers un autre service ou vers un hôte virtuel par défaut.

Deux corrections possibles :

• Déléguer le nom www, ou tout le sous-domaine web, depuis la zone interne vers les serveurs de noms publics du prestataire. Les clients internes résolvent alors comme les clients externes et le changement d'adresse est suivi automatiquement. Conséquence : les serveurs de noms publics doivent être joignables depuis le réseau interne (UDP et TCP 53 en sortie), et l'on perd la possibilité de forcer une adresse interne pour ce nom.
• Renommer le domaine AD en sous-domaine (ad.auralis.fr) pour ne plus être autoritaire sur la zone publique. C'est la solution propre et durable, mais lourde : migration de domaine, réinscription des postes, reconfiguration des applications et des SPN, interruption planifiée. À mener en projet, pas en urgence.

À court terme : corriger l'enregistrement www dans la zone interne avec un TTL court (300 s) et mettre en place une vérification hebdomadaire qui compare la zone interne à la zone publique. Pour l'intranet, la question ne se pose pas : il doit rester un enregistrement interne.

Pourquoi les messages arrivent en indésirables. SPF authentifie le domaine de l'expéditeur d'enveloppe (MAIL FROM) ou le HELO, pas le domaine affiché dans l'en-tête From. DMARC exige un alignement entre ce From et un domaine authentifié par SPF ou par DKIM. Ici, l'ERP remet ses messages à un relais SMTP interne qui utilise probablement son propre domaine d'enveloppe (relais-auralis.net) : SPF passe pour ce domaine, mais le From affiché reste @auralis.fr et n'est aligné avec rien. Aucun DKIM n'est publié pour le relais, donc DMARC échoue. Le ~all (softfail) et le p=none aggravent la situation : aucune politique ne protège le domaine et les filtres des destinataires se rabattent sur des signaux réputationnels.

Plan de correction progressif :

1. Inventorier les expéditeurs légitimes : Google, le relais interne, les outils marketing, les applications métier. Chacun doit être couvert par SPF et par un alignement.
2. Faire signer le relais interne en DKIM avec d=auralis.fr et un sélecteur publié, par exemple relais._domainkey. C'est la correction de fond : l'alignement DKIM fonctionne même si l'enveloppe n'est pas alignée.
3. Aligner l'enveloppe si l'outil le permet : MAIL FROM en @auralis.fr, ce qui fait passer SPF et DMARC simultanément.
4. Vérifier le budget de dix requêtes DNS de l'enregistrement SPF (chaque include et ses include imbriqués comptent) et aplatir la liste si nécessaire.
5. Durcir progressivement DMARC : p=none avec rua pendant quatre semaines pour observer, puis p=quarantine pct=25, 50, 100, avant d'envisager p=reject. Passer SPF en -all seulement après l'inventaire.

Sans DKIM aligné, un passage en p=reject casserait la messagerie de l'ERP : l'ordre des étapes n'est pas négociable.

Configuration nécessaire :

• En-têtes de proxy : proxy_set_header Host $host;, X-Real-IP $remote_addr;, X-Forwarded-For $proxy_add_x_forwarded_for;, X-Forwarded-Proto $scheme;. Sans eux, l'application génère des redirections vers une adresse interne, journalise l'IP du proxy pour tous les utilisateurs et peut refuser la connexion (CSRF, cookies Secure). L'application doit être configurée pour faire confiance à ces en-têtes, et le proxy doit écraser tout X-Forwarded-For entrant pour éviter l'usurpation.
• TLS : terminaison sur le proxy avec un certificat valide pour intranet.auralis.fr. Si le nom n'est pas public, utiliser la validation DNS-01, sinon HTTP-01. Activer HSTS, limiter à TLS 1.2 et 1.3, désactiver les protocoles obsolètes et forcer la redirection de 80 vers 443.
• Résolution interne : le proxy en DMZ doit résoudre le nom du serveur applicatif via un résolveur interne dédié, tout en gardant un résolveur public pour les mises à jour. Ne pas utiliser le DC interne comme unique résolveur depuis la DMZ : c'est exposer le DNS interne à la zone démilitarisée.
• Contrôle d'accès : l'intranet ne devrait pas être ouvert à Internet. Le plus sûr est un accès VPN ou une authentification forte devant le proxy ; à défaut, filtrage géographique et limitation de débit sur le formulaire de connexion.
• Durcissement : masquer la version de Nginx (server_tokens off), limiter la taille des requêtes, bloquer les méthodes inutiles, journaliser les accès avec l'IP réelle pour la supervision.

Risques résiduels : le proxy devient un point unique de panne et une cible ; il doit être supervisé, mis à jour mensuellement et sauvegardé. Un WAF devant l'application est recommandé si celle-ci est ancienne et peu maintenue.