Иногда появляются проблемы, которые нельзя быстро решить.
Они неожиданные и вступаешь в ступор "а как какать?".
У нас много подключенных SaaS и интеграций.
Время от времени приходят разные коллеги и просят добавить/обновить DNS записи.
Например интеграция с каким-нибудь
chargebee или hubspot чем бы это не было. Да тысячи их, я даже не знаю чо они делают.В основном задача состоит из двух типов записи:
- добавить новый
CNAME_E2E2BURMALDADZHIGURDA SOMEDOMAIN.COM- обновить существующий
TXT добавив туда новый хост"v=spf1 include:outlook.com include:hubspotemail.net include:chargebee.com ~all\""В общем-то ничего сложного,
Стек на тераформе и легко пилю MR, где добавляю, получаю аппрув, качу в мейн и ..а всё отлично, какие ещё и.
Спустя время прибегают сейлзы/саппорт с большими глазами, говорят не доходят часть почты, а это критикал.
🔥🔥🔥
Бежишь смотришь пайплайн - всё ок, тераформ всё раскатал, валидация прошла, все чеки тоже прошли - всё чисто.
nslookup, dig - базовые привычные команды проверки показывают, что всё ок.Ну магии не существует, пошли на https://mxtoolbox.com/
Пацаны не даром свою зарплату получают (в отличии от меня, лол), и сайт показывает ошибки нарушения контракта.😞
Ошибка, что адресов уже много и пррривет,
RFC, и его лимиты.Дальнейший поиск меня приводит к неизвестному мне ранее
https://datatracker.ietf.org/doc/html/rfc7208
Оказывается есть лимиты и тут. Сука.
RFC 7208 (спека на SPF) прямо говорит: суммарно можно использовать не больше 10 механизмов, которые дёргают DNS - include, a, mx, ptr, exists, redirect.
И считается это не построчно, а рекурсивно - если внутри одного include спрятан ещё include, он тоже идёт в зачёт. Круто, да? Я сам в охере.
То есть в самой записи можно хоть 100 include понаписать - терраформ смолчит, все валидации пройдут, все провайдеры (клаудфлер в данном случае) скажут ок, MR смержится, ревьюер поставит approve, всё ок. Даже на клаудфлер появится. А хлебнёшь ложку говна уже на проверке письма: получатель досчитывает до 10го lookup и такой "аригато, дальше не считаю" - permerror. Причём не сразу и не у всех - где-то письма улетают в спам, где-то тихо дропаются. Полный рандом, сука. Предполагаю из-за разных политик корректных МТА.
Ок, причину мы нашли, быстро ревертаем коммит, проверяем через https://mxtoolbox.com/ и нам показывают, что всё хорошо.
Ок, мы вернули как было, успокаиваем продажников и саппорт и думаем - "а как быть дальше?" Задачу надо решить.
Вот так сходу есть две мысли
- узнать каким-то образом - все те SPF записи в TXT нужны ли нам - не можем ли мы что-то удалить, чтобы добавить нужное? 😏
- как-то эээ по сабдоменам уровнем ниже разнести записи, ну типа того
Слава вселенной - всё в гите и можно узнать по каждому добавлению SPF кто и когда добавлял. Есть название таски, автор. Идём в личку в слак всем людям, спрашиваем "а эта запись ещё нужна? Модем ли мы дропнуть или ещё используем?".
К счастью в этом случае нашли 1 запись, которая 100% не нужна и больше не используется, дропнули её и добавили новую по задаче.
Как быть при следующем добавлении следующей SPF записи и все они нужны?
А хз, я там уже не работаю 😬
Я и правда честно - не знаю, варианты те же в голове:
- развести интеграции по поддоменам со своим SPF (типа mail.PARTNER.SOMEDOMAIN.СOM), а не тащить всё в основной домен
Тогда, предполагаю, каждый поддомен считает свои 10, а не делит один лимит на всех, но это надо проверять.
- завести привычку прогонять запись через mxtoolbox перед каждым новым includ
- тупорылые танцы со статикой IP, но это статика, шанс инцидента при смене адреса возрастает в 10 раз
Итоги:
- иногда подстава откуда не ждёшь, никакие штатные валидаторы тебе не покажут потенциальную ошибку. В этом случае нам даже впаяли инцидент 😔
- RFC это боль, сколько раз я уже в своей практике упирался в какие-либо лимиты
- если бы не гит-блейм по таскам - чистили бы SPF вслепую.
Инвестируй в IAC - трейсинг "кто и зачем добавил" окупается на все 100% ровно в такие моменты. Git+IaC=❤️
и да, иногда никакого куберентиса 😀