Nebulos švyturio DNS: kas gali užklausti kurių įrašų?

Švyturio vaidmuo Nebuloje atlieka daug darbo, kurį žmonės laiko automatiniu, o atsakinėjimas DNS prie jo nepriklauso. Vardų aptarnavimas yra neprivalomas klausytojas, kuris paleidžiamas išjungtas, todėl hostas, kuris gerai išsprendžia vardus overlay tinkle, gali visai neturėti kuo išspręsti kolegos nešiojamojo kompiuterio. Prieš jį įjungdami nuspręskite, kas turi jį pasiekti ir kokių įrašų tipų esate pasirengę atsakyti, nes šie du atsakymai skiriasi.

Klausytojas yra neprivalomas ir pagal nutylėjimą išjungtas

Aptikimas ir DNS yra atskiros paslaugos. Švyturys padeda peerams rasti vienas kitą ir papildomai gali atsakyti į vardų užklausas apie jam žinomus hostus, tačiau ši antroji dalis turi būti aiškiai įjungta konfigūracijoje.

Nuspręskite, kurios sąsajos ir tinklai turi pasiekti klausytoją, prieš ką nors įjungdami. DNS paslauga, kuri atsako sąsajoje, kurios nenumatėte, tampa nedideliu informacijos nutekėjimu be vieno žurnalo įrašo, kurį kas nors skaitytų. Sprendimą priimti dabar daug pigiau nei vėliau siaurinti, kai kažkas jau priklauso nuo neteisingo atsakymo. Dvi konfigūracijos eilutės pagrindžiamos lengviau nei incidento užrašas po pusmečio.

A įrašai ir TXT nesidalija ta pačia auditorija

Į šiuos du įrašų tipus atsakoma skirtingomis sąlygomis, o jų traktavimas kaip vienos paslaugos yra klaida, kuriai užkirsti kelią skirtas šis straipsnis.

Ši asimetrija yra tyčinė, o ne aplaidumas. Vardo ir adreso atitikimas pašaliniam žmogui mažai vertingas, o sertifikato metaduomenys aprašo jūsų overlay tapatybes. Neperkelkite prielaidos iš vienos eilutės į kitą vien todėl, kad tas pats procesas atsako abiem.

Jis atsako tik apie pačius švyturio hostus

Tai nėra bendras sprendiklis jūsų biurui, debesijos VPC ar viešajam internetui. Švyturys atsako iš jam suteiktos hostų informacijos, todėl ši funkcija gyvena švyturio mazguose, o ne kiekviename peere.

Kai vardas nepavyksta ir overlay tam neturi jokio ryšio, raskite zoną ir sprendiklį, kurie iš tikrųjų jam priklauso. Overlay sprendiklio įmaišymas į bendrą hosto DNS konfigūraciją sukelia gedimus, kurie atrodo atsitiktiniai, nes kai kurie vardai išsprendžiami, o į kitus niekas neatsako.

Taip pat atkreipkite dėmesį į bootstrap įėjimo tašką. Hosto vardas, naudojamas pasiekti pirmąjį švyturį, turi būti išspręstas įprastu keliu, kol aptikimas gali juo remtis, todėl vištos ir kiaušinio problema čia atrodo lygiai kaip sugedęs overlay. Jis netgi praneša taip pat: peer, kuris niekada nepakyla, ir jokios akivaizdžios priežasties. Patikrinkite vardų sprendimą prieš liesdami sertifikatus, nes ši tvarka pagauna tuos, kurie pradėjo nuo sunkesnės pusės.

Patikrinkite susiejimo adresą, tada išbandykite iš išorės

lighthouse.dns.host ir lighthouse.dns.port nusprendžia, kur klausosi neprivaloma paslauga. Peržiūrėkite šias reikšmes kartu su hosto užkarda ir tinklo politika, nes susiejimo adresas yra ketinimo pareiškimas, o ne saugumo kontrolė savaime.

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

Klauskite iš tinklų, kuriuos ketinate leisti, o ne iš paties švyturio. Sėkminga paieška švyturyje įrodo, kad procesas veikia, ir nieko nepasako apie tai, ko gali klausti išorinis hostas, o būtent šis klausimas ir yra svarbus.

Atskleiskite jį sąmoningai

Vardai ir sertifikato metaduomenys yra naudinga operacinė informacija, o naudingumas pjauna į abi puses. Nuspręskite, ar klausytojas turi būti skirtas tik overlay tinklui, kokie įrašų tipai leidžiami ir kas peržiūri konfigūraciją, kai ji keičiasi.

Tada užrašykite tai šalia švyturio nustatymų. Kitas žmogus, kuris derins sprendimo gedimą, kitaip manys, kad paslauga visada ten buvo. Jis taip pat manys, kad ji visada buvo pasiekiama iš ten, kur jis atsitiktinai testuoja. Viena pastraipa su susiejimo adresu, leidžiamais tinklais ir įrašų tipais sutaupo tam žmogui popietę ir sutaupo jums žinutę, klausiančią, kodėl kažkas pasikeitė.