DNS у маяку Nebula: хто може запитувати які записи?

Роль маяка в Nebula виконує багато роботи, яку люди вважають автоматичною, і відповіді по DNS до неї не входять. Обслуговування імен — це необов'язковий слухач, який запускається вимкненим, тому хост, який добре розв'язує імена всередині overlay, може взагалі не мати чим розв'язати ноутбук колеги. Перш ніж його вмикати, вирішіть, хто має до нього дістатися і на які типи записів ви готові відповідати, бо ці дві відповіді різняться.

Слухач необов'язковий і вимкнений за замовчуванням

Виявлення і DNS — окремі служби. Маяк допомагає пірам знаходити одне одного і додатково може відповідати на запити імен про відомі йому хости, але ця друга частина має бути явно ввімкнена в конфігурації.

Перш ніж щось увімкнути, вирішіть, які інтерфейси й мережі мають досягати слухача. Служба DNS, що відповідає на інтерфейсі, якого ви не передбачали, перетворюється на невеликий витік інформації без жодного запису в журналі, який хтось прочитає. Рішення зараз коштує значно дешевше, ніж звужувати пізніше, коли щось уже залежить від неправильної відповіді. Два рядки конфігурації обґрунтувати легше, ніж нотатку про інцидент через пів року.

Записи A і TXT не поділяють однієї аудиторії

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

Ця асиметрія навмисна, а не недогляд. Зіставлення імені з адресою мало цінне для стороннього, тоді як метадані сертифіката описують ідентичності у вашому overlay. Не переносьте припущення з одного рядка на інший лише тому, що той самий процес відповідає на обидва.

Він відповідає лише про власні хости маяка

Це не загальний резолвер для вашого офісу, хмарного VPC чи публічного інтернету. Маяк відповідає з даних про хости, які йому надали, тому ця функція живе на вузлах маяка, а не на кожному пірі.

Коли ім'я не розв'язується, а overlay тут ні до чого, знайдіть зону й резолвер, які справді ним володіють. Змішування overlay-резолвера із загальною конфігурацією DNS хоста породжує збої, які виглядають випадковими, бо одні імена розв'язуються, а на інші ніщо не відповідає.

Зверніть увагу також на точку входу bootstrap. Ім'я хоста, що використовується для досягнення першого маяка, має розв'язуватися звичайним шляхом, перш ніж виявлення зможе на нього покластися, тому проблема курки й яйця тут виглядає точно як зламаний overlay. Воно навіть повідомляє про себе так само: пір, який ніколи не піднімається, і жодної очевидної причини. Перевірте розв'язування імен, перш ніж торкатися сертифікатів, бо цей порядок ловить тих, хто почав із складнішої половини.

Перевірте адресу прив'язки, потім тестуйте ззовні

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

Запитуйте з мереж, які ви збираєтеся дозволити, а не з самого маяка. Успішний пошук на маяку доводить, що процес працює, і нічого не каже про те, що може запитати зовнішній хост, а саме це питання справді важливе.

Відкривайте його свідомо

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

Потім запишіть це поруч із налаштуваннями маяка. Наступна людина, яка відлагоджуватиме збій розв'язування, інакше припустить, що служба була там завжди. Вона також припустить, що служба завжди була доступна звідти, де їй випаде тестувати. Один абзац з адресою прив'язки, дозволеними мережами й типами записів економить цій людині півдня, а вам — повідомлення із питанням, чому щось змінилося.