DNS v svetilniku Nebula: kdo sme vprašati katere zapise?

Vloga svetilnika v Nebuli opravi veliko dela, ki ga ljudje imajo za samodejno, in odgovarjanje na DNS ni eno od njih. Storitev imen je izbirni poslušalec, ki se zažene izklopljen, zato gostitelj, ki v overlayu dobro razrešuje imena, morda sploh nima s čim razrešiti prenosnika sodelavca. Preden ga vklopite, se odločite, kdo naj ga doseže in katere vrste zapisov ste pripravljeni odgovarjati, ker se ta dva odgovora razlikujeta.

Poslušalec je izbiren in privzeto izklopljen

Odkrivanje in DNS sta ločeni storitvi. Svetilnik pomaga peerom najti drug drugega in lahko dodatno odgovarja na poizvedbe imen o gostiteljih, ki jih pozna, vendar mora biti ta drugi del v konfiguraciji izrecno vklopljen.

Preden karkoli omogočite, se odločite, kateri vmesniki in omrežja naj dosežejo poslušalca. Storitev DNS, ki odgovarja na vmesniku, ki ga niste predvideli, postane majhen uhajanje informacij brez enega samega vpisa v dnevnik, ki bi ga kdo prebral. Odločitev je zdaj veliko cenejša kot poznejše zoževanje, ko je nekaj že odvisno od napačnega odgovora. Dve vrstici konfiguracije je lažje utemeljiti kot zapis o incidentu čez pol leta.

Zapisi A in TXT si ne delijo občinstva

Na ti dve vrsti zapisov se odgovarja pod različnimi pogoji, in obravnavanje kot ene storitve je napaka, ki jo želi ta članek preprečiti.

Ta asimetrija je namerna in ne spregled. Preslikava imena v naslov ima za zunanjega človeka majhno vrednost, medtem ko metapodatki potrdila opisujejo identitete v vašem overlayu. Ne prenašajte predpostavke iz ene vrstice v drugo samo zato, ker na obe odgovarja isti proces.

Odgovarja le o lastnih gostiteljih svetilnika

To ni splošen razreševalnik za vašo pisarno, oblačni VPC ali javni internet. Svetilnik odgovarja iz podatkov o gostiteljih, ki jih je prejel, zato ta funkcija živi na vozliščih svetilnika in ne na vsakem peeru.

Ko ime ne uspe in overlay nima nič s tem, poiščite cono in razreševalnik, ki ju resnično imata v lasti. Mešanje overlay razreševalnika v splošno konfiguracijo DNS gostitelja povzroča napake, ki izgledajo naključne, ker se nekatera imena razrešijo, na druga pa ne odgovori nič.

Bodite pozorni tudi na vstopno točko bootstrap. Ime gostitelja, ki se uporablja za doseganje prvega svetilnika, mora biti razrešeno po običajni poti, preden se odkrivanje lahko zanese nanj, zato je problem kokoši in jajca tukaj videti natanko kot pokvarjen overlay. Celo poroča na enak način: peer, ki se nikoli ne dvigne, in nobenega očitnega razloga. Preverite razreševanje imen, preden se dotaknete potrdil, ker ta vrstni red ujame ljudi, ki so začeli s težjo polovico.

Preverite naslov vezave in nato preizkusite od zunaj

lighthouse.dns.host in lighthouse.dns.port določata, kje posluša izbirna storitev. Preglejte te vrednosti skupaj z gostiteljevo požarno pregrado in omrežno politiko, ker je naslov vezave izjava o nameri in ne varnostni nadzor sam po sebi.

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

Poizvedujte iz omrežij, ki jih nameravate dovoliti, ne iz samega svetilnika. Uspešno iskanje na svetilniku dokazuje, da proces teče, in vam ne pove ničesar o tem, kaj lahko vpraša zunanji gostitelj, in prav to vprašanje je resnično pomembno.

Izpostavite ga namenoma

Imena in metapodatki potrdila so koristne operativne informacije, koristnost pa reže na obe strani. Odločite se, ali naj bo poslušalec samo za overlay, katere vrste zapisov dovoliti in kdo pregleda konfiguracijo, ko se spremeni.

Nato to zapišite poleg nastavitev svetilnika. Naslednja oseba, ki bo razhroščevala napako razreševanja, bo sicer domnevala, da je storitev vedno bila tam. Domnevala bo tudi, da je bila vedno dosegljiva od tam, kjer slučajno preizkuša. En odstavek z naslovom vezave, dovoljenimi omrežji in vrstami zapisov prihrani tej osebi popoldne, vam pa sporočilo z vprašanjem, zakaj se je nekaj spremenilo.