DNS del faro de Nebula: ¿quién puede consultar qué registros?
El oyente opcional responde con datos de hosts que el faro guarda. Las consultas de registros A y TXT difieren en alcance y público, así que enlázalo a propósito.
El papel de faro en Nebula hace mucho trabajo que la gente supone automático, y responder DNS no es una de esas tareas. Servir nombres es un oyente opcional que arranca desactivado, por eso un host que resuelve bien dentro del overlay puede no tener con qué resolver el portátil de un colega. Antes de activarlo, decide quién debe alcanzarlo y qué tipos de registro estás dispuesto a responder, porque esas dos respuestas son distintas.
El oyente es opcional y está desactivado por defecto
El descubrimiento y el DNS son servicios separados. El faro ayuda a los pares a encontrarse y, además, puede responder consultas de nombres sobre hosts que conoce, pero esa segunda parte tiene que activarse de forma explícita en la configuración.
Decide qué interfaces y redes deben llegar al oyente antes de habilitar nada. Un servicio DNS que responde en una interfaz que no pretendías se convierte en una pequeña fuga de información sin ninguna entrada de registro que alguien lea. La decisión es mucho más barata ahora que restringirla después, cuando algo dependa de la respuesta equivocada. Dos líneas de configuración se justifican mejor que una nota de incidente dentro de seis meses.
Los registros A y TXT no comparten público
Esos dos tipos de registro se responden en condiciones distintas, y tratarlos como un solo servicio es el error que este artículo existe para evitar.
| 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 |
Esa asimetría es deliberada y no un descuido. Una correspondencia de nombre a dirección tiene poco valor para un extraño, mientras que los metadatos del certificado describen las identidades de tu overlay. No traslades una suposición de una fila a la otra solo porque el mismo proceso responde ambas.
Solo responde sobre los hosts propios del faro
Esto no es un resolutor general para tu oficina, tu VPC en la nube ni la internet pública. El faro responde con información de hosts que se le ha dado, y por eso la función vive en nodos de faro y no en cada par.
Cuando falla un nombre que no tiene nada que ver con el overlay, encuentra la zona y el resolutor que realmente lo poseen. Mezclar un resolutor de overlay en la configuración DNS general de un host produce fallos que parecen aleatorios, porque algunos nombres resuelven y a otros no responde nada.
Vigila también el punto de entrada de arranque. Un nombre de host usado para alcanzar el primer faro tiene que resolverse por una ruta ordinaria antes de que el descubrimiento pueda depender de él, así que un problema del huevo y la gallina aquí se parece exactamente a un overlay roto. Incluso se reporta igual: un par que nunca arranca y ningún motivo evidente. Comprueba la resolución de nombres antes de tocar certificados, porque ese orden atrapa a quien empezó por la mitad más difícil.
Comprueba la dirección de escucha y luego prueba desde fuera
lighthouse.dns.host y lighthouse.dns.port deciden dónde escucha el servicio opcional. Revisa esos valores junto con el cortafuegos del host y la política de red, porque una dirección de escucha es una declaración de intenciones y no un control de seguridad por sí sola.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +shortConsulta desde las redes que pretendes permitir, no desde el propio faro. Una consulta correcta en el faro demuestra que el proceso está en marcha y no te dice nada sobre lo que puede preguntar un host externo, que es la pregunta que de verdad importa.
Expónlo a propósito
Los nombres y los metadatos del certificado son información operativa útil, y la utilidad corta en ambos sentidos. Decide si el oyente debe ser solo para el overlay, qué tipos de registro permitir y quién revisa la configuración cuando cambia.
Luego anótalo junto a los ajustes del faro. La siguiente persona que depure un fallo de resolución asumirá de otro modo que el servicio siempre estuvo ahí. También asumirá que siempre fue alcanzable desde donde le toque probar. Un párrafo que registre la dirección de escucha, las redes permitidas y los tipos de registro le ahorra a esa persona una tarde y te ahorra un mensaje preguntando por qué cambió algo.