DNS у маяку Nebula: хто можа запытваць якія запісы?

Роля маяка ў Nebula выконвае шмат працы, якую людзі лічаць аўтаматычнай, і адказ на DNS не ўваходзіць у яе. Служба імёнаў — гэта неабавязковы слухач, які пачынае выключаным, таму хост, які добра развязвае імёны ўнутры оверлея, можа зусім не мець чым развязаць ноўтбук калегі. Перад уключэннем вырашыце, хто павінен да яго дабрацца і якія тыпы запісаў вы гатовыя аддаваць, бо гэтыя два адказы розныя.

Слухач неабавязковы і па змаўчанні выключаны

Выяўленне і DNS — асобныя службы. Маяк дапамагае пірам знаходзіць адзін аднаго і дадаткова можа адказваць на запыты імёнаў пра вядомыя яму хасты, але гэтая другая частка мусіць быць уключана яўна ў канфігурацыі.

Вызначце інтэрфейсы і сеткі, якія павінны дасягаць слухача, перш чым нешта ўключаць. Служба DNS, якая адказвае на інтэрфейсе, якога вы не мелі на ўвазе, робіцца маленькай уцечкай інфармацыі без запісу ў журнале, які хто-небудзь чытае. Рашэнне зараз каштуе значна танней, чым звужаць пазней, калі нешта ўжо залежыць ад няправільнага адказу. Дзве радкі канфігурацыі прасцей абгрунтаваць, чым нататку пра інцыдэнт праз паўгода.

Запісы A і TXT не маюць адной аўдыторыі

На гэтыя два тыпы запісаў адказваюць пры розных умовах, і ставіцца да іх як да адной службы — гэта памылка, дзеля якой напісаны гэты артыкул.

Гэтая асіметрыя наўмысная, а не недагляд. Супастаўленне імя з адрасам мае малую каштоўнасць для старонняга, а метаданыя сертыфіката апісваюць ідэнтычнасці ў вашым оверлеі. Не пераносьце здагадку з аднаго радка на другі толькі таму, што адзін і той жа працэс адказвае на абодва.

Ён адказвае толькі пра ўласныя хасты маяка

Гэта не агульны рэзалвер для вашага офіса, хмарнага VPC ці публічнага інтэрнэту. Маяк адказвае з даных хостаў, якія яму далі, і менавіта таму функцыя жыве на вузлах маяка, а не на кожным піры.

Калі імя не развязваецца, а оверлей тут ні пры чым, знайдзіце зону і рэзалвер, якія сапраўды ім валодаюць. Змешванне оверлейнага рэзалвера ў агульную канфігурацыю DNS хоста стварае збоі, якія выглядаюць выпадковымі, бо адны імёны развязваюцца, а на іншыя не адказвае нішто.

Сачыце таксама за пунктам загрузкі bootstrap. Імя хоста, якое выкарыстоўваецца для дасягнення першага маяка, мусіць развязацца звычайным шляхам, перш чым выяўленне зможа на яго абаперціся, таму праблема куркі і яйка тут выглядае дакладна як зламаны оверлей. Яна нават паведамляе пра сябе гэтак жа: пір, які ніколі не ўзнімаецца, і ніякай відавочнай прычыны. Праверце развязанне імёнаў, перш чым чапаць сертыфікаты, бо такі парадак ловіць тых, хто пачаў з цяжэйшай паловы.

Праверце адрас прывязкі, затым тэстуйце звонку

lighthouse.dns.host і lighthouse.dns.port вызначаюць, дзе слухае неабавязковая служба. Разгледзьце гэтыя значэнні разам з фаерволам хоста і палітыкай сеткі, бо адрас прывязкі — гэта заява пра намер, а не сродак абароны сам па сабе.

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

Рабіце запыты з сетак, якія вы маеце намер дазволіць, а не з самога маяка. Паспяховы пошук на маяку даказвае, што працэс працуе, і нічога не кажа пра тое, што можа спытаць знешні хост, а гэта і ёсць пытанне, якое сапраўды мае значэнне.

Адкрывайце яго свядома

Імёны і метаданыя сертыфікатаў — карысная аперацыйная інфармацыя, а карысць рэжа ў абодва бакі. Вырашыце, ці слухач павінен быць толькі для оверлея, якія тыпы запісаў дазволіць і хто разглядае канфігурацыю, калі яна змяняецца.

Затым запішыце гэта побач з наладамі маяка. Наступны чалавек, які будзе адладжваць збой развязання, інакш будзе меркаваць, што служба была там заўсёды. Ён таксама будзе меркаваць, што яна заўсёды была даступная адтуль, дзе ён выпадкова тэстуе. Адзін абзац з адрасам прывязкі, дазволенымі сеткамі і тыпамі запісаў зэканоміць гэтаму чалавеку паўдня і пазбавіць вас паведамлення з пытаннем, чаму нешта змянілася.