Nebulan majakan DNS: kuka saa kysyä mitä tietueita?

Majakan rooli Nebulassa tekee paljon työtä, jota ihmiset pitävät automaattisena, eikä DNS-kysymyksiin vastaaminen ole yksi niistä. Nimien tarjoilu on valinnainen kuuntelija, joka käynnistyy pois päältä, minkä vuoksi isäntä, joka ratkaisee hyvin overlayn sisällä, ei välttämättä pysty ratkaisemaan kollegan kannettavaa lainkaan. Ennen kuin kytket sen päälle, päätä kuka sitä saa lähestyä ja mihin tietuetyyppeihin olet valmis vastaamaan, sillä nämä kaksi vastausta eroavat toisistaan.

Kuuntelija on valinnainen ja oletuksena pois päältä

Löytäminen ja DNS ovat erillisiä palveluita. Majakka auttaa vertaisia löytämään toisensa ja voi lisäksi vastata nimikyselyihin isännistä, jotka se tuntee, mutta tämä toinen osa on kytkettävä erikseen päälle asetuksissa.

Päätä, mitkä rajapinnat ja verkot saavat tavoittaa kuuntelijan, ennen kuin otat mitään käyttöön. DNS-palvelu, joka vastaa rajapinnalla, jota et tarkoittanut, muuttuu pieneksi tietovuodoksi ilman yhtäkään lokimerkintää, jota joku lukisi. Päätös on nyt paljon halvempi tehdä kuin kaventaa myöhemmin, kun jokin riippuu väärästä vastauksesta. Kaksi riviä asetuksia on helpompi perustella kuin välikohtausmuistio puolen vuoden päästä.

A-tietueet ja TXT eivät jaa yleisöä

Näihin kahteen tietuetyyppiin vastataan eri ehdoilla, ja niiden kohteleminen yhtenä palveluna on se virhe, jonka tämä artikkeli on olemassa estääkseen.

Tämä epäsymmetria on tahallinen eikä laiminlyönti. Nimen ja osoitteen vastaavuus on ulkopuoliselle vähäarvoinen, kun taas sertifikaatin metatiedot kuvaavat overlay-verkkosi identiteetit. Älä siirrä oletusta riviltä toiselle vain siksi, että sama prosessi vastaa molempiin.

Se vastaa vain majakan omista isännistä

Tämä ei ole yleinen resolveri toimistollesi, pilvi-VPC:llesi tai julkiselle internetille. Majakka vastaa sille annetuista isäntätiedoista, ja siksi ominaisuus asuu majakkasolmussa eikä jokaisessa vertaisessa.

Kun nimi epäonnistuu ilman yhteyttä overlayhin, etsi vyöhyke ja resolveri, jotka todella omistavat sen. Overlay-resolverin sekoittaminen isännän yleisiin DNS-asetuksiin tuottaa epäonnistumisia, jotka näyttävät satunnaisilta, koska jotkin nimet ratkeavat ja toisiin ei vastaa mikään.

Seuraa myös bootstrap-aloituspistettä. Isäntänimi, jota käytetään ensimmäisen majakan tavoittamiseen, on ratkaistava tavallista reittiä pitkin ennen kuin löytäminen voi nojata siihen, joten muna ja kana -ongelma näyttää täällä täsmälleen rikkinäiseltä overlaylta. Se jopa raportoituu samalla tavalla: vertainen, joka ei koskaan nouse, eikä mitään ilmeistä syytä. Tarkista nimien ratkaisu ennen kuin kosket sertifikaatteihin, sillä tämä järjestys nappaa ne, jotka aloittivat vaikeammasta puolikkaasta.

Tarkista sidontaosoite ja testaa sitten ulkopuolelta

lighthouse.dns.host ja lighthouse.dns.port päättävät, missä valinnainen palvelu kuuntelee. Käy nämä arvot läpi isännän palomuurin ja verkkokäytännön kanssa, sillä sidontaosoite on aikomuksen ilmoitus eikä itsessään turvakontrolli.

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

Kysy verkoista, jotka aiot sallia, älä itse majakasta. Onnistunut haku majakalla todistaa, että prosessi on käynnissä, eikä kerro sinulle mitään siitä, mitä ulkopuolinen isäntä voi kysyä, ja juuri se kysymys todella merkitsee.

Paljasta se tarkoituksella

Nimet ja sertifikaatin metatiedot ovat hyödyllistä operatiivista tietoa, ja hyödyllisyys leikkaa molempiin suuntiin. Päätä, pitäisikö kuuntelijan olla vain overlayta varten, mitkä tietuetyypit sallitaan ja kuka tarkistaa asetukset, kun ne muuttuvat.

Kirjoita se sitten majakan asetusten viereen. Seuraava henkilö, joka selvittää ratkaisuvirhettä, olettaa muuten, että palvelu oli aina siellä. Hän olettaa myös, että se oli aina tavoitettavissa sieltä, missä hän sattuu testaamaan. Yksi kappale, johon kirjataan sidontaosoite, sallitut verkot ja tietuetyypit, säästää siltä henkilöltä yhden iltapäivän ja sinulta viestin, jossa kysytään miksi jokin muuttui.