DNS en la lumturo de Nebula: kiu rajtas demandi kiujn rikordojn?

La lumtura rolo en Nebula faras multe da laboro, kiun homoj supozas aŭtomata, kaj respondi DNS ne estas unu el ili. Servi nomojn estas laŭvola aŭskultanto, kiu startas malŝaltita, kaj tial gastiganto, kiu bone solvas ene de la overlay, povas tute ne havi per kio solvi la tekkomputilon de kolego. Antaŭ ol ŝalti ĝin, decidu, kiu devus atingi ĝin kaj kiujn rikordtipojn vi pretas respondi, ĉar tiuj du respondoj diferencas.

La aŭskultanto estas laŭvola kaj defaŭlte malŝaltita

Malkovro kaj DNS estas apartaj servoj. La lumturo helpas al peer-oj trovi unu la alian kaj krome povas respondi nomdemandojn pri gastigantoj, kiujn ĝi konas, sed tiu dua parto devas esti eksplicite ŝaltita en la agordo.

Decidu, kiuj interfacoj kaj retoj devus atingi la aŭskultanton antaŭ ol vi ebligos ion ajn. DNS-servo, kiu respondas sur interfaco, kiun vi ne intencis, fariĝas malgranda informfluo sen ajna protokola ero, kiun iu legas. La decido estas multe pli malmultekosta nun ol mallarĝigi poste, kiam io dependas de la malĝusta respondo. Du linioj da agordo estas pli facile pravigeblaj ol noto pri incidento post duonjaro.

A-rikordoj kaj TXT ne dividas publikon

Tiuj du rikordtipoj estas respondataj sub malsamaj kondiĉoj, kaj trakti ilin kiel unu servon estas la eraro, kiun ĉi tiu artikolo ekzistas por malhelpi.

Tiu nesimetrio estas intenca, ne neglekto. Nom-al-adresa mapado havas malgrandan valoron por eksterulo, dum atestila metadateno priskribas la identecojn en via overlay. Ne portu supozon de unu vico al la alia simple ĉar la sama procezo respondas ambaŭ.

Ĝi respondas nur pri la propraj gastigantoj de la lumturo

Ĉi tio ne estas ĝenerala solvilo por via oficejo, via nuba VPC aŭ la publika interreto. La lumturo respondas el gastigaj informoj, kiujn ĝi ricevis, kaj tial la funkcio loĝas sur lumturaj nodoj anstataŭ sur ĉiu peer.

Kiam nomo malsukcesas sen rilato al la overlay, trovu la zonon kaj solvilon, kiuj vere posedas ĝin. Miksi overlay-solvilon en la ĝeneralan DNS-agordon de gastiganto produktas malsukcesojn, kiuj aspektas hazardaj, ĉar iuj nomoj solviĝas kaj aliajn respondas nenio.

Rigardu ankaŭ la bootstrap-enirejon. Gastigantnomo uzata por atingi la unuan lumturon devas solviĝi per ordinara vojo antaŭ ol malkovro povas dependi de ĝi, do kokina-ova problemo ĉi tie aspektas ĝuste kiel rompita overlay. Ĝi eĉ raportas same: peer, kiu neniam ekfunkcias, kaj neniu evidenta kialo. Kontrolu nomosolvadon antaŭ ol tuŝi atestilojn, ĉar tiu ordo kaptas homojn, kiuj komencis per la pli malfacila duono.

Kontrolu la bind-adreson, poste testu de ekstere

lighthouse.dns.host kaj lighthouse.dns.port decidas, kie la laŭvola servo aŭskultas. Revizu tiujn valorojn kune kun la fajromuro de la gastiganto kaj la reta politiko, ĉar bind-adreso estas deklaro de intenco kaj ne sekureca kontrolo per si mem.

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

Demandu el la retoj, kiujn vi intencas permesi, ne el la lumturo mem. Sukcesa serĉo sur la lumturo pruvas, ke la procezo funkcias, kaj diras al vi nenion pri tio, kion ekstera gastiganto povas demandi, kaj tio estas la demando, kiu vere gravas.

Elmetu ĝin konscie

Nomoj kaj atestila metadateno estas utilaj operaciaj informoj, kaj utileco tranĉas ambaŭdirekten. Decidu, ĉu la aŭskultanto estu nur por la overlay, kiuj rikordtipoj permesiĝu kaj kiu revizias la agordon, kiam ĝi ŝanĝiĝas.

Poste skribu ĝin apud la lumturaj agordoj. La sekva persono, kiu sencimigos solvomalsukceson, alie supozos, ke la servo ĉiam estis tie. Ĝi ankaŭ supozos, ke ĝi ĉiam estis atingebla de kie ajn ĝi hazarde testas. Unu paragrafo, kiu notus la bind-adreson, la permesitajn retojn kaj la rikordtipojn, ŝparas al tiu persono posttagmezon kaj ŝparas al vi mesaĝon demandantan, kial io ŝanĝiĝis.