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

Правете заявки от мрежите, които възнамерявате да разрешите, а не от самия фар. Успешно търсене на фара доказва, че процесът работи, и не ви казва нищо за това какво може да попита външен хост, а това е въпросът, който наистина има значение.

Излагайте го умишлено

Имената и метаданните на сертификатите са полезна оперативна информация и полезността реже и в двете посоки. Решете дали слушателят да е само за оверлея, кои типове записи да се разрешават и кой преглежда конфигурацията, когато тя се промени.

После го запишете до настройките на фара. Следващият човек, който отстранява проблем с резолвиране, иначе ще приеме, че услугата винаги е била там. Той също ще приеме, че винаги е била достъпна откъдето и да тества. Един абзац с адреса за свързване, разрешените мрежи и типовете записи спестява на този човек един следобед и ви спестява съобщение с въпрос защо нещо се е променило.