DNS у светионику Nebula: ко може да упита које записе?

Улога светионика у Nebula обавља много посла за који људи претпостављају да је аутоматски, а одговарање на DNS није један од њих. Служење имена је необавезни слушалац који почиње искључен, због чега домаћин који се добро разрешава унутар overlay-а можда уопште нема чиме да разреши преносни рачунар колеге. Пре него што га укључите, одлучите ко треба да га достигне и које типове записа сте спремни да одговарате, јер се та два одговора разликују.

Слушалац је необавезан и подразумевано искључен

Откривање и DNS су одвојене услуге. Светионик помаже peer-овима да пронађу једни друге и додатно може да одговара на упите имена о домаћинима које познаје, али тај други део мора изричито да се укључи у конфигурацији.

Одлучите која мрежна сучеља и мреже треба да достигну слушаоца пре него што било шта омогућите. DNS услуга која одговара на сучељу које нисте намеравали постаје мало цурење информација без иједног записа у дневнику који би неко прочитао. Одлуку је сада много јефтиније донети него је касније сужавати, након што се нешто ослони на погрешан одговор. Два реда конфигурације лакше је образложити од белешке о инциденту за шест месеци.

A записи и TXT не деле исту публику

На та два типа записа одговара се под различитим условима, а третирање њих као једне услуге грешка је коју овај чланак постоји да спречи.

Та асиметрија је намерна, а не пропуст. Пресликавање имена у адресу има малу вредност за аутсајдера, док метаподаци сертификата описују идентитете у вашем overlay-у. Не преносите претпоставку са једног реда на други само зато што исти процес одговара на оба.

Одговара само о сопственим домаћинима светионика

Ово није општи resolver за вашу канцеларију, ваш cloud VPC или јавни интернет. Светионик одговара из података о домаћинима који су му дати, зато и та функција живи на чворовима светионика, а не на сваком peer-у.

Када име не успе, а overlay нема с тим везе, пронађите зону и resolver који га заиста поседују. Мешање overlay resolver-а у општу DNS конфигурацију домаћина ствара отказе који изгледају случајно, јер се нека имена разрешавају, а на друга ништа не одговара.

Обратите пажњу и на почетну тачку за bootstrap. Име домаћина које се користи за достизање првог светионика мора да се разреши обичним путем пре него што откривање може да се ослони на њега, па проблем кокошке и јајета овде изгледа тачно као покварен overlay. Чак се и пријављује на исти начин: peer који никада не устаје и никакав очигледан разлог. Проверите разрешавање имена пре него што дирате сертификате, јер тај редослед хвата људе који су почели са тежом половином.

Проверите адресу повезивања, па тестирајте споља

lighthouse.dns.host и lighthouse.dns.port одређују где необавезна услуга слуша. Прегледајте те вредности уз firewall домаћина и мрежну политику, јер адреса повезивања је изјава намере, а не безбедносна контрола сама по себи.

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

Упућујте упите са мрежа које намеравате да дозволите, не са самог светионика. Успешно тражење на светионику доказује да процес ради и не говори вам ништа о томе шта спољни домаћин може да пита, а то је питање које је заиста важно.

Изложите га намерно

Имена и метаподаци сертификата корисна су оперативна информација, а корисност сече на обе стране. Одлучите да ли слушалац треба да буде само за overlay, које типове записа допустити и ко прегледа конфигурацију када се промени.

Затим то запишите поред поставки светионика. Следећа особа која буде отклањала квар разрешавања иначе ће претпоставити да је услуга одувек била ту. Такође ће претпоставити да је одувек била доступна одакле год случајно тестира. Један пасус који бележи адресу повезивања, дозвољене мреже и типове записа штеди тој особи једно поподне и штеди вама поруку са питањем зашто се нешто променило.