DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense

DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense

Chiffrer et signer la résolution DNS (Domain Name System) règle de vrais problèmes : DNSSEC (Domain Name System Security Extensions) authentifie les réponses, DoT (DNS over TLS), DoH (DNS over HTTPS) et ODoH (Oblivious DNS over HTTPS) cachent les questions aux curieux du chemin. La facture arrive côté défense : chaque requête qui part chiffrée vers un résolveur extérieur, c’est une ligne de journal en moins, un filtrage contourné, une détection aveugle. Cette page compare ce que chaque protocole protège, contre qui, et dit comment garder le chiffrement sans rendre les clés du réseau.

Explication de la marmotte

Demander son chemin à voix haute dans un hall de gare, c’est pratique : tout le monde entend, y compris l’agent de sécurité, qui repère ainsi les demandes louches. Chuchoter la question à l’oreille d’un inconnu protège des curieux, mais l’agent n’entend plus rien non plus. Toute la page parle de ce chuchotement et de ce qu’il fait perdre.

→ Lire l’explication complète de la marmotte

DNSSEC, DoT, DoH, DoQ, ODoH : ce que chaque protocole protège et contre qui

Deux axes, à ne jamais confondre. L’authenticité : la réponse vient-elle bien du titulaire de la zone ? La confidentialité : qui lit la question ? DNSSEC traite le premier et rien que le premier. Les quatre autres traitent le second, et dans leur usage courant sur le seul tronçon entre le poste et son résolveur. Aucun ne rend la résolution invisible, ils choisissent seulement qui a encore le droit de regarder.

Quelques sigles avant le tableau : RFC (Request for Comments, les documents de spécification d’Internet), TLS (Transport Layer Security), UDP (User Datagram Protocol), TCP (Transmission Control Protocol), HTTP (HyperText Transfer Protocol), DoQ (DNS over QUIC, QUIC étant un transport chiffré sur UDP dont le nom n’est pas un sigle), HPKE (Hybrid Public Key Encryption, RFC 9180), IP (Internet Protocol).

Mécanisme	Référence	Transport	Ce qui est protégé	Contre qui	Qui lit encore la question
DNSSEC	RFC 4033 à 4035	inchangé, port 53	authenticité et intégrité des enregistrements	réponse forgée, empoisonnement de cache	tout le monde : chemin, résolveur, serveurs faisant autorité
DoT	RFC 7858	TCP 853	confidentialité et intégrité poste vers résolveur	écoute et réécriture sur le chemin	le résolveur ; le réseau sait que c’est du DNS (port dédié)
DoH	RFC 8484	TCP 443 (HTTP/2) ou UDP 443 (HTTP/3)	comme DoT, fondu dans le trafic web	écoute, réécriture, filtrage par port	le résolveur ; le réseau voit du HTTPS vers une adresse
DoQ	RFC 9250	UDP 853	comme DoT, sans blocage de tête de file	écoute et réécriture sur le chemin	le résolveur ; port dédié comme DoT
ODoH	RFC 9230 (statut expérimental)	HTTPS, message chiffré par HPKE	dissociation entre identité du client et contenu	le résolveur lui-même	relais : l’adresse sans la question ; cible : la question sans l’adresse

Le détail de DoT est dans DNS over TLS, celui de la chaîne de confiance dans DNSSEC : chaîne de confiance, validation et exploitation des clés ; les bases de la résolution sont dans DNS, DHCP, NTP et services d’infrastructure, et QUIC dans QUIC et HTTP moderne. Ici, seul le tableau de chasse compte.

Trois lectures à en tirer.

DNSSEC ne coûte rien en visibilité. Tout reste lisible, les journaux du résolveur sont intacts, le filtrage fonctionne. C’est le seul de la liste qu’on peut activer sans réunir personne.

DoT et DoQ sont honnêtes : un port dédié, 853, qui annonce la couleur. Un pare-feu les autorise ou les refuse en une règle. DoH est conçu pour que cette règle n’existe pas : même port, même protocole, mêmes hébergeurs que le reste du web. Un atout face à un réseau hostile, un problème quand le réseau hostile s’appelle « le réseau de l’entreprise, qui essaie de se défendre ».

ODoH ajoute un étage. Le schéma suivant montre ce que chaque acteur détient ; la propriété tient tant que relais et cible ne se parlent pas en dehors du protocole.

Pour un parc géré, ODoH n’a aucun usage légitime sur le réseau interne : il est conçu pour qu’aucun tiers unique ne puisse relier une machine à ses requêtes, ce qui est très exactement le travail d’un journal de résolveur. Le choix d’un résolveur pour un particulier ou un poste nomade relève d’un autre raisonnement, traité dans l’éditorial Le DNS, le protocole qu’on ne regarde jamais.

Perte de visibilité : journaux du résolveur, filtrage RPZ, détection de C2, DGA et tunnels DNS

Le DNS est la télémétrie la moins chère d’un réseau : presque toute action commence par une résolution, et le résolveur interne la consigne sans agent ni sonde. Quatre mécanismes de défense vivent dessus.

• Les journaux de requêtes : qui a demandé quel nom, quand. C’est la matière première de la recherche rétrospective quand un indicateur de compromission est publié.
• Les RPZ (Response Policy Zones) : des zones de politique qui font répondre au résolveur autre chose que la vérité (inexistence du nom, redirection vers un puits) pour les domaines malveillants.
• La détection de C2 (Command and Control, le serveur de commande d’un maliciel) et de DGA (Domain Generation Algorithm) : un maliciel à DGA tire des centaines de noms pseudo-aléatoires jusqu’à trouver celui que son opérateur a enregistré. La signature est une rafale de réponses NXDOMAIN (Non-Existent Domain) sur des noms à forte entropie.
• La détection de tunnels DNS : des labels longs, une part anormale d’enregistrements de type TXT ou NULL, des milliers de sous-domaines uniques sous un même domaine parent.

Un poste ou un maliciel qui résout en DoH vers l’extérieur éteint les quatre d’un coup. Le résolveur interne ne reçoit rien, donc ne journalise rien, donc la RPZ ne s’applique pas, donc la rafale de NXDOMAIN n’existe pas. Quant au tunnel DNS, il n’a même plus besoin d’en être un aux yeux du réseau : c’est une session HTTPS vers un hébergeur respectable.

Le point vicieux : rien ne tombe en erreur. Les tableaux de bord restent verts, le volume de requêtes baisse un peu, et l’absence d’alerte passe pour une absence de menace. Le capteur le plus dangereux n’est pas celui qui tombe en panne, c’est celui qui continue d’afficher zéro.

Deux dégâts collatéraux s’ajoutent. La résolution à vues multiples casse : un poste qui interroge un résolveur public ne résout plus les noms internes. Et il les fuit : chaque tentative envoie le nom d’un serveur interne à un tiers, qui obtient gratuitement un bout de cartographie.

Une précision qui évite de se tromper d’ennemi. Les navigateurs, dans leur réglage par défaut, sont moins coupables que leur réputation. Le mode automatique de Chrome ne change pas de résolveur : il ne passe en DoH que si le résolveur système figure parmi ceux qu’il sait compatibles, et il se désactive sur un poste où des politiques d’entreprise sont présentes. Firefox, là où DoH est actif par défaut, interroge un domaine canari avant de l’activer. Le vrai sujet, ce sont les applications qui embarquent leur propre client DoH avec une adresse codée en dur, les utilisateurs qui forcent le réglage à la main, et les maliciels, qui ne lisent pas les politiques d’entreprise.

Ce qui reste observable sans déchiffrer : adresses IP, SNI, volumétrie, empreintes TLS

Le chiffrement cache le contenu, pas l’existence de la conversation. Quatre signaux survivent.

L’adresse de destination. Les grands résolveurs publics ont des adresses connues et stables. Un flux 443 vers l’une d’elles depuis un poste de travail est du DoH jusqu’à preuve du contraire. Limite : n’importe qui peut monter un point DoH sur un hébergement mutualisé, derrière un CDN (Content Delivery Network) partagé avec dix mille sites honnêtes. La liste d’adresses ne sera jamais complète.

Le SNI (Server Name Indication). Le nom du serveur demandé voyage lisible dans le premier message de la poignée de main TLS. Tant qu’ECH (Encrypted Client Hello) n’est pas déployé de bout en bout, un pare-feu lit le nom du résolveur visé. Avec ECH, seul le nom public de façade de l’hébergeur reste lisible. Détail savoureux : les clés ECH sont distribuées par des enregistrements DNS de type HTTPS, donc un client qui a déjà contourné le résolveur interne obtient tout ce qu’il faut pour masquer aussi son SNI. La fuite s’auto-entretient.

La volumétrie et la forme du trafic. Une session DoH n’a pas la silhouette d’une navigation : connexion longue, échanges petits et nombreux, tailles serrées, souvent du bourrage par blocs. Un tunnel d’exfiltration par-dessus DoH se trahit par un volume montant sans commune mesure avec ce qu’un poste a besoin de résoudre.

Les empreintes TLS. Les méthodes JA3 et JA4 condensent les paramètres du premier message TLS en une empreinte. Un client DoH embarqué dans un maliciel n’a pas l’empreinte du navigateur du parc. Signal d’appoint, pas preuve : une empreinte s’imite.

Et un cinquième, le plus rentable : l’absence. Une connexion sortante vers une adresse qu’aucune réponse du résolveur interne n’a jamais fournie à ce poste signifie que le nom a été résolu ailleurs, ou que l’adresse était codée en dur. Dans les deux cas, ça mérite un regard.

L’interception TLS sur un proxy rend le contenu, quand elle est en place : une requête DoH porte le type de média application/dns-message, une requête ODoH application/oblivious-dns-message. Dans le second cas, le proxy sait que c’est de l’ODoH et n’en lit pas davantage. Un client qui épingle son certificat refusera l’interception et la connexion échouera, ce qui est aussi un résultat.

Reprendre la main : résolveur interne chiffrant, politiques navigateurs, domaine canari, DDR, blocage

La position défendue ici : chiffrer, oui, mais au bon endroit. Le résolveur interne valide DNSSEC et parle lui-même DoT ou DoH vers son amont ; les postes ne parlent qu’à lui ; tout DNS chiffré sortant direct depuis un poste est une violation de politique, bloquée par construction et non par liste. On garde la confidentialité face à l’opérateur et au transit, on garde les journaux, la RPZ et la détection. Le compromis est assumé : l’organisation voit les requêtes de ses postes. Sur un parc géré, c’est le contrat. Sur un réseau invité ou des terminaux personnels, il ne tient pas : là, on isole et on ne prétend pas journaliser.

La topologie ci-dessous montre les deux seuls chemins DNS autorisés (poste vers résolveur interne, résolveur interne vers amont) et celui que le pare-feu refuse.

Les leviers, du plus structurant au plus cosmétique.

1. Sortie refusée par défaut, web par proxy explicite. C’est la seule mesure qui ne dépend pas d’une liste. Un poste qui ne peut pas ouvrir de 443 direct vers Internet ne peut pas faire de DoH direct, quel que soit le résolveur visé. Le proxy résout lui-même les noms, via le résolveur interne. Le reste de la liste est du complément. Voir filtrage, segmentation et NAC.
2. Blocage de 853 en TCP et en UDP vers l’extérieur, sauf depuis le résolveur interne. Une règle, DoT et DoQ réglés.
3. Résolveur interne qui chiffre vers l’amont et, si possible, vers les postes. Offrir du DoT ou du DoH en interne retire leur argument aux clients qui exigent un transport chiffré.
4. Annonce du résolveur chiffré par DDR (Discovery of Designated Resolvers, RFC 9462). Le poste demande au résolveur non chiffré, via un enregistrement SVCB (Service Binding) sur le nom _dns.resolver.arpa, s’il existe un équivalent chiffré. Piège : la découverte vérifiée exige que le certificat du résolveur chiffré contienne l’adresse IP du résolveur d’origine, ce qui se prévoit dans l’autorité de certification interne. La variante par DHCP (Dynamic Host Configuration Protocol), dite DNR (Discovery of Network-designated Resolvers, RFC 9463), évite l’aller-retour.
5. Politiques d’entreprise des navigateurs. Chrome et dérivés : DnsOverHttpsMode à off, ou à secure avec DnsOverHttpsTemplates pointant sur le résolveur interne. Firefox : politique DNSOverHTTPS verrouillée. Verrouiller, sinon c’est une suggestion.
6. Domaine canari use-application-dns.net. Si le résolveur interne répond NXDOMAIN pour ce nom, Firefox renonce à son DoH par défaut. Deux limites : seul Firefox le consulte, et un utilisateur qui a activé DoH explicitement n’en tient pas compte. Dans la même famille, répondre NXDOMAIN pour mask.icloud.com et mask-h2.icloud.com désactive le relais privé d’Apple (iCloud Private Relay), qui fait passer le trafic par deux relais successifs et résout ses noms en ODoH. Une ligne de RPZ par nom.
7. Blocage des résolveurs publics connus (adresses et noms, relais ODoH compris). Indispensable et incomplet par nature : la liste attrape les clients configurés par défaut, pas un point DoH monté pour l’occasion. S’en contenter revient à fermer le parking officiel en espérant que personne ne se gare dans la rue.
8. Télémétrie sur le poste. Dernier recours et seul capteur qui suit le poste nomade hors du réseau. Détail dans la section sur les limites.

Le schéma résume où la visibilité se retrouve, couche par couche.

Exemple : détecter un DoH sortant par corrélation entre flux et journaux DNS

La règle la plus rentable ne cherche pas le DoH. Elle cherche les connexions sans résolution préalable. Elle demande deux sources déjà présentes : les journaux de flux du pare-feu ou du proxy, et les journaux du résolveur interne, avec les réponses (adresses renvoyées), pas seulement les questions.

Trois précautions pour que la règle ne noie pas l’analyste. La fenêtre de corrélation doit couvrir la durée de vie des enregistrements plus le cache local du poste, sinon chaque connexion réutilisant une réponse ancienne déclenche. Les flux qui passent par le proxy explicite sont exclus, puisque c’est le proxy qui résout. Les adresses légitimement codées en dur (mises à jour d’agents, supervision) vont dans une liste d’exceptions tenue à la main, courte, et relue.

La dernière branche est la plus parlante : un poste actif qui ne pose plus aucune question au résolveur interne a trouvé quelqu’un d’autre à qui parler. Pour brancher la règle sur l’existant, voir menaces réseau et détection et captures, observabilité et diagnostic.

Surface d’attaque et limites : ce que DNSSEC et le DNS chiffré ne garantissent pas

Le DNS chiffré déplace la confiance, il ne la supprime pas. DoT, DoH et DoQ protègent le tronçon poste vers résolveur. Le résolveur lit tout. Derrière lui, la résolution vers les serveurs faisant autorité part le plus souvent non chiffrée. La question n’est jamais « chiffré ou pas », c’est « à qui remet-on l’historique ».

DNSSEC ne dit rien de l’intention. Une zone malveillante signe ses enregistrements aussi bien qu’une autre. La validation prouve que la réponse est authentique, pas que le domaine est fréquentable. Et elle s’arrête au résolveur : entre le résolveur et le poste, sans transport chiffré, la réponse validée redevient modifiable.

RPZ et DNSSEC se contredisent par construction. Une réponse réécrite par RPZ est un mensonge délibéré, donc non signée. Pour un nom situé dans une zone signée, un client qui validerait lui-même la rejetterait. Tant que la validation se fait sur le résolveur interne, là où s’applique la RPZ, le conflit reste théorique ; il cesse de l’être le jour où un client validant apparaît dans le parc.

L’adresse de destination reste visible. Cacher le nom ne cache pas où part le paquet. Quand une adresse n’héberge qu’un service, la confidentialité de la requête est décorative.

Le canari est un signal de courtoisie. Il n’est ni signé ni authentifié : n’importe quel réseau peut l’émettre, et n’importe quel client peut l’ignorer. Un maliciel l’ignore.

DDR en mode opportuniste se détourne. Sans vérification du certificat, un attaquant capable de répondre à la place du résolveur non chiffré désigne le résolveur chiffré de son choix. D’où l’intérêt du mode vérifié, et du certificat qui va avec.

La télémétrie DNS du poste a un angle mort précis. Le journal du client DNS de Windows (canal ETW, Event Tracing for Windows) et l’événement 22 de Sysmon ne voient que les résolutions passant par l’interface du système. Une application qui embarque sa propre pile DoH n’y laisse rien. Ce qui reste, c’est la vue d’un EDR (Endpoint Detection and Response) sur les connexions : tel processus, telle adresse, port 443. D’où la corrélation de l’exemple.

Le blocage dégrade parfois en silence. Un client configuré en DoH « si possible » retombe sur le résolveur système quand le blocage frappe : parfait. Un client en mode strict cesse de résoudre : le support le saura vite. Un client qui essaie un second résolveur public absent de la liste passe : personne ne le saura.

Prérequis et conditions d’exploitation du résolveur interne chiffrant

Avant de commencer. Un résolveur interne récursif ou relais, redondé, que tous les postes utilisent déjà : si la moitié du parc pointe ailleurs par héritage de configuration, le chiffrement n’est pas le premier chantier. Une sortie Internet filtrée, avec le résolveur comme seule source autorisée vers 853. Un logiciel qui sait faire ce qu’on lui demande, car écoute chiffrée et relais chiffré ne sont pas arrivés ensemble : BIND écoute en DoT et DoH depuis la branche 9.18 et relaie en DoT depuis la 9.20 ; Unbound relaie en DoT de longue date et sert du DoH depuis la 1.12. Un amont qui accepte DoT avec un nom à authentifier, pas seulement une adresse.

Certificats. Le résolveur qui écoute en DoT ou DoH porte un certificat, avec son nom et, pour DDR vérifié, ses adresses IP. Son expiration coupe la résolution chiffrée de tout le parc d’un coup : renouvellement automatisé et alerte sur la date, sans négociation. Côté amont, authentifier le nom du serveur ; un relais DoT en mode opportuniste chiffre pour n’importe qui se présentant à cette adresse.

Ancre de confiance DNSSEC. La clé racine se renouvelle ; le suivi automatique (RFC 5011) doit être actif et l’horloge juste, car une signature se juge à sa période de validité. Un résolveur validant avec une heure fausse répond en échec à tout.

Supervision. Taux de réponses en échec de validation, latence de l’amont, état de la session TLS amont, volume de requêtes par poste (une chute à zéro est une alerte, pas une bonne nouvelle), compteurs de refus du pare-feu sur 853 et vers les résolveurs publics.

Journaux. Ils associent une machine, donc souvent une personne, à tout ce qu’elle a cherché à joindre : ce sont des données à caractère personnel au sens du RGPD (Règlement général sur la protection des données). Durée de conservation, accès restreint et finalité se décident avant la collecte, pas après la première demande embarrassante.

Listes et politiques. La liste des résolveurs publics et des relais vieillit vite : source datée, mise à jour planifiée, test après chaque mise à jour. Les politiques de navigateur se vérifient sur un poste réel après chaque montée de version, les éditeurs renommant leurs réglages avec une régularité admirable.

Sauvegarde et reprise. Configuration du résolveur, zones RPZ, clés et certificats, liste d’exceptions de la règle de corrélation. Le plan de reprise doit dire quoi faire quand l’amont chiffré ne répond plus : basculer sur un second amont chiffré, jamais sur du port 53 non chiffré « le temps que ça revienne ».

FAQ

Faut-il interdire DoH sur un réseau d’entreprise ?

Interdire le DoH sortant direct depuis les postes, oui. Interdire DoH en tant que protocole, non : servi par le résolveur interne, il apporte le chiffrement sans retirer les journaux. Le critère n’est pas le protocole, c’est le résolveur qui termine la connexion.

DNSSEC devient-il superflu quand la résolution est chiffrée ?

Non. Le transport chiffré garantit que la réponse n’a pas été modifiée entre le poste et le résolveur ; il ne dit rien de ce que le résolveur a reçu en amont. DNSSEC authentifie la donnée à la source. Les deux se cumulent.

L’interception TLS suffit-elle à retrouver la visibilité ?

Elle rend lisible le DoH qui traverse le proxy et permet de reconnaître l’ODoH sans le lire. Elle ne voit rien de ce qui ne passe pas par le proxy, d’où la sortie refusée par défaut, et elle échoue face aux clients à certificat épinglé. C’est un capteur de plus, pas le socle.

Que faire des postes nomades hors du réseau ?

Hors du réseau, ni pare-feu ni résolveur interne ne voient quoi que ce soit. Restent le tunnel permanent vers l’entreprise, qui ramène la résolution vers le résolveur interne, et la télémétrie de l’agent sur le poste. Sans l’un des deux, la visibilité DNS d’un poste nomade est nulle, chiffrement ou pas.

🐝 Ce qui arrive si on s’en passe

Sans résolveur interne imposé ni sortie filtrée, le journal DNS devient un échantillon dont personne ne connaît le biais : il contient les machines disciplinées et omet précisément celles qui ont une raison de résoudre ailleurs. La recherche rétrospective sur un domaine malveillant renvoie alors une liste de postes touchés fausse par défaut, et le périmètre d’un incident se trouve sous-estimé sans qu’aucun indice le signale. La zone de politique ne protège plus que les postes qui acceptent de la consulter. Les noms internes demandés à des résolveurs tiers dessinent peu à peu l’inventaire des serveurs chez des opérateurs extérieurs. Et la baisse du volume de requêtes, lue sur un tableau de bord, ressemble à un réseau plus calme.

🦫 Explication de la marmotte 🍫

Quand un ordinateur veut joindre un site, il demande d’abord à un serveur spécialisé, appelé résolveur, quelle adresse numérique correspond au nom du site. À l’origine, cette question et sa réponse circulent sans protection : tout équipement placé sur le trajet peut les lire, et parfois les modifier. Deux familles de protections existent. La première ajoute une signature aux réponses : le résolveur vérifie que la réponse vient bien du propriétaire du nom et n’a pas été changée en route, mais tout reste lisible. La seconde chiffre l’échange entre l’ordinateur et le résolveur : plus personne sur le trajet ne lit la question, mais le résolveur, lui, la lit toujours. Une variante ajoute un intermédiaire, pour que celui qui connaît le demandeur ne voie pas la question et que celui qui voit la question ignore qui la pose. Dans une entreprise, l’équipe de sécurité lit le journal du résolveur interne pour repérer les machines infectées, car un logiciel malveillant doit lui aussi demander l’adresse de son serveur de commande. Si ce logiciel chiffre ses questions et les envoie à un résolveur extérieur, le journal interne reste vide et le blocage des noms dangereux ne s’applique plus. La parade : obliger toutes les machines à passer par le résolveur interne, lui faire chiffrer ses propres échanges avec l’extérieur, bloquer les résolveurs extérieurs et surveiller sur chaque poste quel programme ouvre quelle connexion.

À lire aussi

• Suivre un flux de bout en boutApprendre à raconter un échange complet depuis une action utilisateur jusqu’au service distant, en distinguant nom, adresse, chemin, transport, chiffrement et réponse applicative.
• Empoisonnement de cache DNS de Kaminsky à SAD DNS et paradesComment une réponse forgée entre dans le cache d'un résolveur DNS, de l'attaque de Kaminsky de 2008 aux variantes récentes, et ce qu'arrêtent réellement la randomisation des ports, le codage 0x20, les cookies et DNSSEC.
• Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLSOù se place l'intercepteur sur un chemin réseau (ARP, DHCP, DNS, Wi-Fi, proxy TLS d'entreprise), ce que l'authentification des extrémités arrête et ce qu'elle laisse passer.
• Résolution locale, ICMP, MTU et multicastExpliquer les protocoles qui rendent IP utilisable localement et diagnostiquable : ARP, Neighbor Discovery, ICMP, ICMPv6, MTU, fragmentation, multicast et IGMP.

Pages voisines

La citent

• Attaque de l'intercepteur par ARP, DHCP, DNS, Wi-Fi et proxy TLS
• Empoisonnement de cache DNS de Kaminsky à SAD DNS et parades

DNSSEC, DoH, DoT, ODoH et perte de visibilité pour la défense

Elle cite

• ⇄Lien dans les deux sens :DNS, DHCP, NTP : services d'infrastructure réseau
• ⇄Lien dans les deux sens :Le DNS, le protocole qu'on ne regarde jamais
• DNS over TLS (DoT) : chiffrer la résolution de noms
• DNSSEC : chaîne de confiance, validation et exploitation des clés
• Filtrage, segmentation, NAC et Zero Trust
• QUIC, HTTP moderne, TLS et proxys applicatifs
• Captures, observabilité et diagnostic multi-couche
• Certificate pinning : risques et rotation des certificats
• EDR : fonctionnement, angles morts et contournements
• IoC ou TTP pour détecter une compromission

⇄ : les deux pages se citent l’une l’autre.