DNS do faro de Nebula: quen pode consultar que rexistros?

O papel de faro en Nebula fai moito traballo que a xente supón automático, e responder DNS non é unha desas tarefas. Servir nomes é un oínte opcional que arrinca desactivado, por iso un host que resolve ben dentro do overlay pode non ter con que resolver o portátil dun compañeiro. Antes de activalo, decide quen debe alcanzalo e que tipos de rexistro estás disposto a responder, porque esas dúas respostas son distintas.

O oínte é opcional e está desactivado por defecto

O descubrimento e o DNS son servizos separados. O faro axuda aos pares a atoparse e, ademais, pode responder consultas de nomes sobre hosts que coñece, pero esa segunda parte ten que activarse de forma explícita na configuración.

Decide que interfaces e redes deben chegar ao oínte antes de habilitar nada. Un servizo DNS que responde nunha interface que non pretendías convértese nunha pequena fuga de información sen ningunha entrada de rexistro que alguén lea. A decisión é moito máis barata agora que restrinxila despois, cando algo dependa da resposta equivocada. Dúas liñas de configuración xustifícanse mellor que unha nota de incidente dentro de seis meses.

Os rexistros A e TXT non comparten público

Eses dous tipos de rexistro respóndense en condicións distintas, e tratalos como un só servizo é o erro que este artigo existe para evitar.

Esa asimetría é deliberada e non un descoido. Unha correspondencia de nome a enderezo ten pouco valor para un estraño, mentres que os metadatos do certificado describen as identidades do teu overlay. Non traslades unha suposición dunha fila á outra só porque o mesmo proceso responde ambas.

Só responde sobre os hosts propios do faro

Isto non é un resolvedor xeral para a túa oficina, o teu VPC na nube nin a internet pública. O faro responde con información de hosts que se lle deu, e por iso a función vive en nodos de faro e non en cada par.

Cando falla un nome que non ten nada que ver co overlay, atopa a zona e o resolvedor que realmente o posúen. Mesturar un resolvedor de overlay na configuración DNS xeral dun host produce fallos que parecen aleatorios, porque algúns nomes resolven e a outros non responde nada.

Vixía tamén o punto de entrada de arranque. Un nome de host usado para alcanzar o primeiro faro ten que resolverse por unha ruta ordinaria antes de que o descubrimento poida depender del, así que un problema do ovo e a galiña aquí parécese exactamente a un overlay roto. Incluso se informa igual: un par que nunca arrinca e ningún motivo evidente. Comproba a resolución de nomes antes de tocar certificados, porque esa orde atrapa a quen comezou pola metade máis difícil.

Comproba o enderezo de escoita e logo proba desde fóra

lighthouse.dns.host e lighthouse.dns.port deciden onde escoita o servizo opcional. Revisa eses valores xunto coa devasa do host e a política de rede, porque un enderezo de escoita é unha declaración de intencións e non un control de seguridade por si só.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

Consulta desde as redes que pretendes permitir, non desde o propio faro. Unha consulta correcta no faro demostra que o proceso está en marcha e non che di nada sobre o que pode preguntar un host externo, que é a pregunta que de verdade importa.

Expóno a propósito

Os nomes e os metadatos do certificado son información operativa útil, e a utilidade corta en ambos os sentidos. Decide se o oínte debe ser só para o overlay, que tipos de rexistro permitir e quen revisa a configuración cando cambia.

Logo anótao xunto aos axustes do faro. A seguinte persoa que depure un fallo de resolución asumirá doutro xeito que o servizo sempre estivo aí. Tamén asumirá que sempre foi alcanzable desde onde lle toque probar. Un parágrafo que rexistre o enderezo de escoita, as redes permitidas e os tipos de rexistro aforra a esa persoa unha tarde e aforra che a ti unha mensaxe preguntando por que cambiou algo.