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, какие типы записей разрешить и кто пересматривает конфигурацию, когда она меняется.

Затем запишите это рядом с настройками маяка. Следующий человек, который будет отлаживать сбой разрешения, иначе предположит, что служба была там всегда. Он также предположит, что она всегда была доступна оттуда, где ему случится тестировать. Один абзац с адресом привязки, разрешёнными сетями и типами записей экономит этому человеку полдня, а вам — сообщение с вопросом, почему что-то изменилось.