DNS del faro Nebula: chi può interrogare quali record?
L’ascoltatore opzionale risponde dai dati degli host che il faro detiene. Le query dei record A e TXT differiscono per raggiungibilità e pubblico, quindi vincolalo deliberatamente.
Il ruolo di faro in Nebula svolge molto lavoro che le persone danno per automatico, e rispondere al DNS non è una di quelle cose. Servire nomi è un ascoltatore opzionale che parte disattivato, ed è per questo che un host che risolve bene dentro l’overlay può non avere affatto con cosa risolvere il portatile di un collega. Prima di attivarlo, decidi chi deve raggiungerlo e quali tipi di record sei disposto a servire, perché queste due risposte sono diverse.
L’ascoltatore è opzionale e disattivato per impostazione predefinita
Scoperta e DNS sono servizi separati. Il faro aiuta i peer a trovarsi e può inoltre rispondere a query di nomi sugli host che conosce, ma questa seconda parte deve essere attivata esplicitamente nella configurazione.
Decidi quali interfacce e quali reti devono raggiungere l’ascoltatore prima di attivare qualcosa. Un servizio DNS che risponde su un’interfaccia che non avevi previsto diventa una piccola fuga di informazioni senza alcuna voce di registro che qualcuno legga. La decisione costa molto meno ora che restringerla dopo, quando qualcosa dipende dalla risposta sbagliata. Due righe di configurazione si giustificano più facilmente di una nota di incidente fra sei mesi.
I record A e TXT non condividono lo stesso pubblico
Questi due tipi di record vengono serviti in condizioni diverse, e trattarli come un unico servizio è l’errore che questo articolo esiste per evitare.
| 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 |
Questa asimmetria è deliberata e non una svista. Una corrispondenza nome-indirizzo ha poco valore per un estraneo, mentre i metadati del certificato descrivono le identità nel tuo overlay. Non trasportare un’ipotesi da una riga all’altra solo perché lo stesso processo serve entrambe.
Risponde solo per gli host propri del faro
Questo non è un resolver generale per il tuo ufficio, il tuo VPC nel cloud o l’internet pubblico. Il faro risponde da informazioni sugli host che gli sono state fornite, ed è per questo che la funzione vive sui nodi del faro e non su ogni peer.
Quando un nome fallisce senza alcun rapporto con l’overlay, trova la zona e il resolver che lo possiedono davvero. Mescolare un resolver overlay nella configurazione DNS generale di un host produce errori che sembrano casuali, perché alcuni nomi si risolvono e ad altri non risponde nulla.
Osserva anche il punto di ingresso di bootstrap. Un nome host usato per raggiungere il primo faro deve risolversi tramite un percorso ordinario prima che la scoperta possa dipenderne, quindi un problema dell’uovo e della gallina qui somiglia esattamente a un overlay rotto. Si segnala persino allo stesso modo: un peer che non si alza mai e nessuna ragione evidente. Verifica la risoluzione dei nomi prima di toccare i certificati, perché quest’ordine coglie chi ha iniziato dalla metà più difficile.
Controlla l’indirizzo di ascolto, poi prova dall’esterno
lighthouse.dns.host e lighthouse.dns.port decidono dove ascolta il servizio opzionale. Esamina quei valori insieme al firewall dell’host e alla politica di rete, perché un indirizzo di ascolto è una dichiarazione di intenti e non un controllo di sicurezza da solo.
dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short
Interroga dalle reti che intendi consentire, non dal faro stesso. Una ricerca riuscita sul faro dimostra che il processo è in esecuzione e non ti dice nulla su ciò che un host esterno può chiedere, ed è la domanda che conta davvero.
Esponilo di proposito
I nomi e i metadati del certificato sono informazioni operative utili, e l’utilità taglia in entrambe le direzioni. Decidi se l’ascoltatore deve essere riservato all’overlay, quali tipi di record consentire e chi rivede la configurazione quando cambia.
Poi scrivilo accanto alle impostazioni del faro. La prossima persona che farà debug di un errore di risoluzione supporrà altrimenti che il servizio ci sia sempre stato. Supporrà anche che sia sempre stato raggiungibile da dove capita che stia provando. Un paragrafo che registra l’indirizzo di ascolto, le reti consentite e i tipi di record risparmia a quella persona un pomeriggio e risparmia a te un messaggio che chiede perché qualcosa è cambiato.