Beryl::CLI::DnsApply
Cœur partagé du nommage DNS multi-provider (ADR-014), extrait de
beryl dns pour que beryl scan --dns ET beryl dns posent les
records EXACTEMENT de la même façon :
- forward A/AAAA → via le dns_provider de la zone
(
host.dns_provider, ex. gandi) :ensure_record+refresh_zone. - reverse PTR → via le compute provider propriétaire de l'IP
(
host.provider, ex. ovh) :set_reverse(Gandi ne sait pas).
Avant l'extraction, scan --dns passait par DnsSetup (100% OVH) :
une zone hébergée chez Gandi (cas acme : dns_provider=gandi,
provider=ovh) faisait 404 « This service does not exist » sur
GET /domain/zone/<zone>/record — OVH ne connaît pas la zone
(constaté qsbg, 9 juin 2026). En passant par le dns_provider réel
de la zone, le forward marche quel que soit l'hébergeur DNS.
La détection d'IP est compute-spécifique : OVH câblé (dédiés). Les
autres providers compute (scaleway/dedibox) gardent leurs propres
flux dans scan — refus explicite ici (principe : pas d'échec
silencieux).
Class methods
Instance methods
Pose / resynchronise le DNS de host (déjà résolu, credentials
déjà appliqués par l'appelant via apply_all_credentials_to_env!).
cmd préfixe les messages (« beryl dns » ou « beryl scan ») pour
que la sortie reste juste selon l'appelant.
Ne lève PAS sur un échec de forward : retourne Outcome::Failed.
L'appelant décide si c'est bloquant (beryl dns) ou best-effort
(scan --dns).
Pose le forward A/AAAA via le dns_provider RÉEL de la zone
(host.dns_provider), puis refresh. C'est la brique multi-provider
du forward, partagée : for_host l'utilise pour le chemin OVH, et
les flux compute-spécifiques de scan (scaleway/dedibox, qui font
leur propre détection d'IP) l'appellent au lieu de hardcoder OVH.
Lève si dns_provider est absent / sans capability :dns, ou sur
échec d'un ensure_record — l'appelant décide du caractère bloquant
(dans scan, tout le DNS est best-effort).