Продолжение статьи про NIC RU DNS API
Ну вот и вышла версия 1.3. Код полностью портировал на Python благодаря пакету cx_Freeze, который позволяет с помощью утилиты patchelf скомпилировать скрипты в бинарник (конечно впихиваются и интерпретатор и иблиотеки, но это лучше чем тащить GO).
Из нового было исправление Top Level Domain. Есть у нас сервак в Новой Зеландии, у которого Top Level Domain это ".co.nz" (в России это .ru) и поскольку скрипт не учитывал TLD, то выдавал ошибку думая, что TLD является ".nz".
По резолвингу DNS все таки обратно вернулся к 8.8.8.8. Объясняю почему...долго шерстил гугл пытаясь понять как работает валидация TXT записей в certbot. Понятное дело, что валидацией занимается не сам certbot, а ACME-сервер. Пытался найти какие-то подсказки в коде certbot, но тщетно. На официальных форумах были предположения, что ACME-сервер либо рандомно выбирает один из DNS обслуживающих зону (список можно получить запросив NS запись), либо находит адрес DNS через SOA запись. Но когда создавались TXT записи они моментально появлялись в DNS-серверах обслуживающих зону, а ACME-сервер так и не мог провести валидацию записей, что говорит о том, что используемый им DNS-сервер имеет другое значение TTL. Методом тыка выяснил, что валидация успешно проходит в течении 120 секунд, если опрашивать гугловский сервер. Собственно отсюда и параметр SLEEP. Поскольку есть вероятность блокировки гугловский DNS, то не стал хардкодить значение, а вынес в конфигурационный файл.
Ускорил время валидации TXT записей. Раньше при проверке записи, если ее не было, то скрипт залипал на 120 секунд. А certbot вызывает хук (скрипт auth.py) для каждого доменного адреса т.е. если выписываю сертификат для igro.tech и it.igro.tech, то SLEEP будет уже составлять 240 секунд (дальше хуже). Сейчас при резолвинге TXT записи скрипт залипает на 10 секунд, если нет записи. И только потом, когда auth.py отрезолвит все записи в DNS скрипт залипнет на 120 секунд, что значительно ускоряет работу приложения.
Для безопасности хранения данных аутентификации теперь используется симметричное шифрование. Ключ шифрования при каждой сборке генерируется заново и заменяет предыдущий. С помощью ключа "-a" можно добавлять/заменять данные аутентификации. Таким образом не придется каждый раз пересобирать приложение когда пароль или ключи меняются, а сами данные надежно защищены. Чтобы убедится в надежности после компиляции попробовал отреверсить приложение, но ключ шифрования так и не смог найти. Главное после сборки удалить исходный код или заархивировать с паролем. Исходил из той логики, что лучше потерять данные, чем они попадут третьим лицам. Но только сейчас задумался, что возможно стоило добавить возможность включить подтверждение паролем при добавлении/замене данных аутентификации на этапе компиляции. Может в следующей версии завезу данный функционал, но пока спорно ведь приложение могут и просто удалить и в таком случае смысла от такого функционала ровно ноль.
Добавил возможность отправлять нотификации через slack и telegram помимо почты, но забыл в slack добавить возможность нотификации с тегом @here. Чтож, завезу в следующей версии, а на этом пока что все.
P.S. Как обычно зафакапился ) вот ссылка на скачивание.