DNS du phare Nebula : qui peut interroger quels enregistrements ?
L’écouteur facultatif répond à partir des données d’hôtes que le phare détient. Les requêtes d’enregistrements A et TXT diffèrent en portée et en public, alors liez-le délibérément.
Le rôle de phare dans Nebula abat beaucoup de travail que les gens croient automatique, et répondre au DNS n’en fait pas partie. Servir des noms est un écouteur facultatif qui démarre désactivé, ce qui explique qu’un hôte qui résout bien dans l’overlay puisse n’avoir rien du tout pour résoudre l’ordinateur portable d’un collègue. Avant de l’activer, décidez qui doit l’atteindre et quels types d’enregistrements vous acceptez de servir, car ces deux réponses diffèrent.
L’écouteur est facultatif et désactivé par défaut
La découverte et le DNS sont des services distincts. Le phare aide les pairs à se trouver et peut en plus répondre à des requêtes de noms sur les hôtes qu’il connaît, mais cette seconde partie doit être activée explicitement dans la configuration.
Décidez quelles interfaces et quels réseaux doivent atteindre l’écouteur avant d’activer quoi que ce soit. Un service DNS qui répond sur une interface que vous n’aviez pas prévue devient une petite fuite d’information sans aucune entrée de journal que quelqu’un lirait. La décision coûte bien moins cher maintenant que de la restreindre plus tard, quand quelque chose dépend de la mauvaise réponse. Deux lignes de configuration se justifient plus facilement qu’une note d’incident dans six mois.
Les enregistrements A et TXT ne partagent pas le même public
Ces deux types d’enregistrements sont servis dans des conditions différentes, et les traiter comme un seul service est l’erreur que cet article existe pour éviter.
| Query | What it returns | Who can reach it |
|---|---|---|
| A record for a host name | That host Nebula IP | Any host that can reach the listener, overlay or not |
| TXT for a host IP | Certificate information | Only over the Nebula network |
Cette asymétrie est délibérée et non un oubli. Une correspondance nom-adresse a peu de valeur pour un tiers, tandis que les métadonnées de certificat décrivent les identités de votre overlay. Ne transportez pas une hypothèse d’une ligne à l’autre simplement parce que le même processus sert les deux.
Il ne répond que pour les hôtes propres au phare
Ce n’est pas un résolveur général pour votre bureau, votre VPC dans le cloud ou l’internet public. Le phare répond à partir d’informations d’hôtes qui lui ont été fournies, et c’est pourquoi la fonction vit sur les nœuds de phare plutôt que sur chaque pair.
Quand un nom échoue sans aucun rapport avec l’overlay, trouvez la zone et le résolveur qui le possèdent réellement. Mélanger un résolveur overlay dans la configuration DNS générale d’un hôte produit des échecs qui semblent aléatoires, parce que certains noms se résolvent et d’autres ne reçoivent aucune réponse.
Surveillez aussi le point d’entrée d’amorçage. Un nom d’hôte utilisé pour joindre le premier phare doit se résoudre par un chemin ordinaire avant que la découverte puisse en dépendre, donc un problème d’œuf et de poule ici ressemble exactement à un overlay cassé. Il se signale même de la même manière : un pair qui ne monte jamais et aucune raison évidente. Vérifiez la résolution de noms avant de toucher aux certificats, car cet ordre attrape ceux qui ont commencé par la moitié la plus difficile.
Vérifiez l’adresse d’écoute, puis testez depuis l’extérieur
lighthouse.dns.host et lighthouse.dns.port décident où le service facultatif écoute. Examinez ces valeurs avec le pare-feu de l’hôte et la politique réseau, car une adresse d’écoute est une déclaration d’intention et non un contrôle de sécurité à elle seule.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortInterrogez depuis les réseaux que vous comptez autoriser, pas depuis le phare lui-même. Une recherche réussie sur le phare prouve que le processus tourne et ne vous dit rien sur ce qu’un hôte extérieur peut demander, et c’est la question qui compte vraiment.
Exposez-le à dessein
Les noms et les métadonnées de certificat sont des informations d’exploitation utiles, et l’utilité coupe dans les deux sens. Décidez si l’écouteur doit être réservé à l’overlay, quels types d’enregistrements autoriser et qui révise la configuration quand elle change.
Ensuite, notez-le à côté des réglages du phare. La personne suivante qui déboguerra un échec de résolution supposera sinon que le service a toujours été là. Elle supposera aussi qu’il était toujours joignable depuis l’endroit où elle teste. Un paragraphe consignant l’adresse d’écoute, les réseaux autorisés et les types d’enregistrements épargne à cette personne un après-midi et vous épargne un message demandant pourquoi quelque chose a changé.