Nebula bākas DNS: kurš drīkst vaicāt kuras ierakstus?

Bākas loma Nebulā veic daudz darba, ko cilvēki uzskata par automātisku, un atbildēšana uz DNS pie tā nepieder. Vārdu apkalpošana ir neobligāts klausītājs, kas startē izslēgts, tāpēc resursdators, kas overlaya ietvaros labi atrisina vārdus, var vispār ne ar ko neatrisināt kolēģa portatīvo datoru. Pirms ieslēgšanas izlemiet, kam tam jāpiekļūst un uz kādiem ierakstu tipiem esat gatavs atbildēt, jo šīs divas atbildes atšķiras.

Klausītājs ir neobligāts un pēc noklusējuma izslēgts

Atklāšana un DNS ir atsevišķi pakalpojumi. Bāka palīdz peeriem atrast viens otru un papildus var atbildēt uz vārdu vaicājumiem par tai zināmiem resursdatoriem, taču šī otrā daļa konfigurācijā ir skaidri jāieslēdz.

Pirms kaut ko iespējojat, izlemiet, kurām saskarnēm un tīkliem jāsasniedz klausītājs. DNS pakalpojums, kas atbild uz saskarni, kuru neesat paredzējis, kļūst par nelielu informācijas noplūdi bez neviena žurnāla ieraksta, ko kāds lasītu. Lēmumu pieņemt tagad ir daudz lētāk nekā vēlāk to sašaurināt, kad kaut kas jau ir atkarīgs no nepareizas atbildes. Divas konfigurācijas rindas ir vieglāk pamatot nekā incidenta pierakstu pēc pusgada.

A ieraksti un TXT nedala vienu auditoriju

Uz šiem diviem ierakstu tipiem atbild dažādos apstākļos, un to uzskatīšana par vienu pakalpojumu ir kļūda, kuras novēršanai šis raksts ir domāts.

Šī asimetrija ir apzināta, nevis nolaidība. Vārda un adreses atbilstība ārējam cilvēkam ir mazvērtīga, savukārt sertifikāta metadati apraksta jūsu overlaya identitātes. Nepārnesiet pieņēmumu no vienas rindas uz otru tikai tāpēc, ka tas pats process atbild uz abiem.

Tas atbild tikai par pašas bākas resursdatoriem

Šis nav vispārīgs atrisinātājs jūsu birojam, mākoņa VPC vai publiskajam internetam. Bāka atbild no tai sniegtās resursdatoru informācijas, tāpēc šī funkcija dzīvo bākas mezglos, nevis katrā peer.

Kad vārds neizdodas un overlay tam nav nekāda sakara, atrodiet zonu un atrisinātāju, kas to patiešām pārvalda. Overlay atrisinātāja iemaisīšana resursdatora vispārīgajā DNS konfigurācijā rada kļūmes, kas izskatās nejaušas, jo daži vārdi tiek atrisināti, bet uz citiem nekas neatbild.

Pievērsiet uzmanību arī bootstrap ieejas punktam. Resursdatora vārds, kas tiek izmantots pirmās bākas sasniegšanai, ir jāatrisina parastā ceļā, pirms atklāšana var uz to paļauties, tāpēc vistas un olas problēma šeit izskatās tieši kā salauzts overlay. Tas pat ziņo tāpat: peer, kas nekad nepaceļas, un nekāda acīmredzama iemesla. Pārbaudiet vārdu atrisināšanu pirms sertifikātu aizskaršanas, jo šī secība noķer tos, kuri sāka ar grūtāko pusi.

Pārbaudiet piesaistes adresi, pēc tam pārbaudiet no ārpuses

lighthouse.dns.host un lighthouse.dns.port nosaka, kur klausās neobligātais pakalpojums. Pārskatiet šīs vērtības kopā ar resursdatora ugunsmūri un tīkla politiku, jo piesaistes adrese ir nodoma paziņojums, nevis drošības kontrole pati par sevi.

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

Vaicājiet no tīkliem, kurus plānojat atļaut, nevis no pašas bākas. Veiksmīga meklēšana bākā pierāda, ka process darbojas, un neko nepasaka par to, ko var jautāt ārējs resursdators, un tieši šis jautājums patiešām ir svarīgs.

Atklājiet to apzināti

Vārdi un sertifikāta metadati ir noderīga operatīvā informācija, un lietderība griež abos virzienos. Izlemiet, vai klausītājam jābūt tikai overlay vajadzībām, kuri ierakstu tipi ir atļauti un kas pārskata konfigurāciju, kad tā mainās.

Pēc tam pierakstiet to blakus bākas iestatījumiem. Nākamā persona, kas atkļūdos atrisināšanas kļūmi, citādi pieņems, ka pakalpojums vienmēr ir bijis tur. Viņš arī pieņems, ka tas vienmēr ir bijis sasniedzams no jebkurienes, kur viņš nejauši testē. Viena rindkopa ar piesaistes adresi, atļautajiem tīkliem un ierakstu tipiem ietaupa šai personai pēcpusdienu un ietaupa jums ziņu, kas jautā, kāpēc kaut kas mainījās.