DNS do farol Nebula: quem pode consultar quais registros?

O papel de farol no Nebula faz muito trabalho que as pessoas supõem automático, e responder DNS não é uma delas. O serviço de nomes é um ouvinte opcional que começa desativado, e por isso um host que resolve bem dentro do overlay pode não ter nada com que resolver o portátil de um colega. Antes de ativá-lo, decida quem deve alcançá-lo e quais tipos de registro você aceita responder, porque essas duas respostas são diferentes.

O ouvinte é opcional e está desativado por padrão

Descoberta e DNS são serviços separados. O farol ajuda os pares a se encontrarem e pode, além disso, responder consultas de nomes sobre hosts que conhece, mas essa segunda parte tem de ser ativada explicitamente na configuração.

Decida quais interfaces e redes devem alcançar o ouvinte antes de habilitar qualquer coisa. Um serviço DNS que responde numa interface que você não pretendia torna-se um pequeno vazamento de informação sem nenhuma entrada de log que alguém leia. A decisão é muito mais barata agora do que restringi-la depois, quando algo depender da resposta errada. Duas linhas de configuração justificam-se melhor do que uma nota de incidente daqui a seis meses.

Registros A e TXT não compartilham público

Esses dois tipos de registro são respondidos em condições diferentes, e tratá-los como um único serviço é o erro que este artigo existe para evitar.

Essa assimetria é deliberada e não um descuido. Um mapeamento de nome para endereço tem pouco valor para um estranho, enquanto os metadados do certificado descrevem as identidades do seu overlay. Não transporte uma suposição de uma linha para a outra só porque o mesmo processo responde às duas.

Ele responde apenas sobre os hosts próprios do farol

Isto não é um resolvedor geral para o seu escritório, o VPC na nuvem ou a internet pública. O farol responde a partir de informações de hosts que recebeu, e por isso o recurso vive nos nós de farol e não em cada par.

Quando um nome falha sem qualquer relação com o overlay, encontre a zona e o resolvedor que realmente o possuem. Misturar um resolvedor de overlay na configuração DNS geral de um host produz falhas que parecem aleatórias, porque alguns nomes resolvem e a outros nada responde.

Observe também o ponto de entrada de bootstrap. Um nome de host usado para alcançar o primeiro farol precisa resolver por um caminho comum antes que a descoberta possa depender dele, então um problema de ovo e galinha aqui parece exatamente um overlay quebrado. Ele até se reporta da mesma forma: um par que nunca sobe e nenhum motivo óbvio. Verifique a resolução de nomes antes de tocar em certificados, porque essa ordem apanha quem começou pela metade mais difícil.

Verifique o endereço de escuta e depois teste de fora

lighthouse.dns.host e lighthouse.dns.port decidem onde o serviço opcional escuta. Revise esses valores junto com o firewall do host e a política de rede, porque um endereço de escuta é uma declaração de intenção e não um controle de segurança 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

Consulte a partir das redes que você pretende permitir, não do próprio farol. Uma consulta bem-sucedida no farol prova que o processo está em execução e não lhe diz nada sobre o que um host externo pode perguntar, e essa é a pergunta que realmente importa.

Exponha-o de propósito

Nomes e metadados de certificado são informação operacional útil, e a utilidade corta nos dois sentidos. Decida se o ouvinte deve ser apenas para o overlay, quais tipos de registro permitir e quem revisa a configuração quando ela muda.

Depois escreva isso ao lado das configurações do farol. A próxima pessoa que depurar uma falha de resolução assumirá, de outro modo, que o serviço sempre esteve ali. Ela também assumirá que sempre era alcançável de onde estiver testando. Um parágrafo registrando o endereço de escuta, as redes permitidas e os tipos de registro poupa a essa pessoa uma tarde e poupa a você uma mensagem perguntando por que algo mudou.