ThysTips_dn42/infra-dn42
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

fix(monitoring) : la sonde DNS interrogeait le seul nom qui marchait encore #36

Merged
thystips merged 1 commit from fix/dns-recursion-probe into main 2026-08-13 00:46:41 +02:00
Conversation 0 Commits 1 Files changed 2 +59
thystips commented 2026-08-12 23:34:13 +02:00
Owner
Copy link

La sonde du résolveur anycast demandait thystips.dn42 SOA — notre propre zone, servie par une stub-zone qui pointe sur nos propres serveurs autoritatifs, sur nos propres loopbacks. Y répondre n'emprunte aucun des chemins par lesquels un résolveur récursif peut tomber.

Mesuré le 12/08/2026 : deux des quatre résolveurs répondaient NOERROR à cette question et SERVFAIL à tout autre nom DN42, en annonçant la VIP anycast. dn42_dns_probe_success valait 1 sur les quatre.

Ce que la PR ajoute

dn42_dns_recursion_success, qui pose une question que rien de local ne peut satisfaire :

  • un nom sous dn42., hors de notre zone — y répondre exige de joindre les serveurs de délégation ;
  • un label aléatoire, donc jamais servi par le cache : une réponse en cache prouve que le chemin marchait la dernière fois, ce qui est le contraire d'une sonde ;
  • NXDOMAIN compte comme un succès, et c'est le résultat attendu. La question n'est pas « ce nom existe-t-il » mais « la délégation a-t-elle répondu ». SERVFAIL et le silence sont les deux échecs.

recursive: true se déclare dans anycast.yml plutôt que de se déduire du nom, pour la même raison que ports : la boucle teste une propriété.

Vérification

Les deux branches éprouvées sur fr-rbx2 :

172.20.187.253  rc=0  status=NXDOMAIN  -> success=1
172.20.187.254  rc=1  status=aucun     -> success=0

Déployée sur les quatre nœuds, changed=0 au second passage.

⚠ Ce que cette PR ne corrige pas

Le défaut que la sonde existe pour voir. Le /64 de services est partagé par les deux nœuds d'un site et annoncé par les deux, donc la réponse à un flux sortant d'un conteneur peut atterrir sur le nœud voisin, qui n'a pas l'entrée de conntrack et la jette sur drop "DN42 does not reach containers".

Le commentaire de cette règle énonce l'hypothèse, et c'est elle qui est fausse : « le retour revient en established, accepté tout en haut de la chaîne » — vrai seulement si le retour revient sur le même nœud.

fr-rbx2  wgp-yuyuko  Out  ::c:3 > fd42:4242:2601:ac53::1  echo request
fr-rbx1  wgp-kioubit In   fd42:4242:2601:ac53::1 > ::c:3  echo reply    ← autre nœud, puis rien

Le symptôme est par destination et intermittent, ce qui explique qu'il ait vécu inaperçu : Unbound a six serveurs de délégation et s'en sort tant qu'un seul reste joignable. Le correctif retenu est un /64 par nœud pour les conteneurs, et c'est le chantier suivant.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9

La sonde du résolveur anycast demandait `thystips.dn42 SOA` — **notre propre zone**, servie par une `stub-zone` qui pointe sur nos propres serveurs autoritatifs, sur nos propres loopbacks. Y répondre n'emprunte aucun des chemins par lesquels un résolveur récursif peut tomber. **Mesuré le 12/08/2026** : deux des quatre résolveurs répondaient NOERROR à cette question et SERVFAIL à tout autre nom DN42, **en annonçant la VIP anycast**. `dn42_dns_probe_success` valait 1 sur les quatre. ## Ce que la PR ajoute `dn42_dns_recursion_success`, qui pose une question que rien de local ne peut satisfaire : - un nom sous `dn42.`, hors de notre zone — y répondre exige de joindre les serveurs de délégation ; - un label **aléatoire**, donc jamais servi par le cache : une réponse en cache prouve que le chemin marchait la dernière fois, ce qui est le contraire d'une sonde ; - **NXDOMAIN compte comme un succès**, et c'est le résultat attendu. La question n'est pas « ce nom existe-t-il » mais « la délégation a-t-elle répondu ». SERVFAIL et le silence sont les deux échecs. `recursive: true` se **déclare** dans `anycast.yml` plutôt que de se déduire du nom, pour la même raison que `ports` : la boucle teste une propriété. ## Vérification Les deux branches éprouvées sur fr-rbx2 : ``` 172.20.187.253 rc=0 status=NXDOMAIN -> success=1 172.20.187.254 rc=1 status=aucun -> success=0 ``` Déployée sur les quatre nœuds, `changed=0` au second passage. ## ⚠ Ce que cette PR ne corrige pas Le défaut que la sonde existe pour voir. Le `/64` de services est partagé par les deux nœuds d'un site et **annoncé par les deux**, donc la réponse à un flux sortant d'un conteneur peut atterrir sur le nœud **voisin**, qui n'a pas l'entrée de conntrack et la jette sur `drop "DN42 does not reach containers"`. Le commentaire de cette règle énonce l'hypothèse, et c'est elle qui est fausse : *« le retour revient en `established`, accepté tout en haut de la chaîne »* — vrai seulement si le retour revient sur le **même** nœud. ``` fr-rbx2 wgp-yuyuko Out ::c:3 > fd42:4242:2601:ac53::1 echo request fr-rbx1 wgp-kioubit In fd42:4242:2601:ac53::1 > ::c:3 echo reply ← autre nœud, puis rien ``` Le symptôme est **par destination et intermittent**, ce qui explique qu'il ait vécu inaperçu : Unbound a six serveurs de délégation et s'en sort tant qu'un seul reste joignable. Le correctif retenu est **un `/64` par nœud** pour les conteneurs, et c'est le chantier suivant. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
`dns-metrics.sh` demandait `thystips.dn42 SOA` aux deux services anycast. Pour
l'autoritatif c'est la bonne question. Pour le RÉSOLVEUR c'était la seule qu'il
ne fallait pas poser : notre zone est servie par une `stub-zone` qui pointe sur
nos propres serveurs autoritatifs, sur nos propres loopbacks — donc y répondre
n'emprunte aucun des chemins par lesquels un résolveur récursif peut tomber.

MESURÉ le 12/08/2026 : deux des quatre résolveurs répondaient NOERROR à cette
question et SERVFAIL à tout autre nom DN42, en annonçant la VIP anycast pendant
ce temps. `dn42_dns_probe_success` valait 1 sur les quatre.

D'où `dn42_dns_recursion_success`, qui pose une question que rien de local ne
peut satisfaire :

  - un nom sous `dn42.`, hors de notre zone : y répondre EXIGE de joindre les
    serveurs de délégation ;
  - un label aléatoire, donc jamais servi par le cache — une réponse en cache
    prouve que le chemin marchait la dernière fois, ce qui est le contraire
    d'une sonde ;
  - NXDOMAIN compte comme un SUCCÈS, et c'est le résultat attendu : la question
    n'est pas « ce nom existe-t-il » mais « la délégation a-t-elle répondu ».
    SERVFAIL et le silence sont les deux échecs.

Les deux branches sont éprouvées sur fr-rbx2 : NXDOMAIN → 1, adresse muette → 0.

`recursive: true` se DÉCLARE dans anycast.yml plutôt que de se déduire du nom du
service, pour la même raison que `ports` : la boucle teste une propriété, donc un
second résolveur l'obtient en le disant.

⚠ CE QUE CETTE PR NE CORRIGE PAS. Le défaut que la sonde existe pour voir est
toujours là : le `/64` de services est partagé par les deux nœuds d'un site et
annoncé par les deux, donc la réponse à un flux sortant d'un conteneur peut
atterrir sur le nœud VOISIN, qui n'a pas l'entrée de conntrack et jette sur
`drop "DN42 does not reach containers"`. Le commentaire de cette règle énonce
l'hypothèse fausse : « le retour revient en established ». Vrai seulement si le
retour revient sur le MÊME nœud. Capture à l'appui dans la conversation. Le
correctif retenu est un /64 par nœud, et il fait l'objet du chantier suivant.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
thystips deleted branch fix/dns-recursion-probe 2026-08-13 00:46:41 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ThysTips_dn42/infra-dn42!36
No description provided.