Один известный dns-хостер преподнёс неожиданный сюрприз, в результате которого b2b-площадка стала потихоньку “недоступна” клиентам потому, что указанные в описании домена NS-серверы (все пять, ага) перестали корректно резолвить имя (server can’t find example.org: REFUSED), мониторинг предупредить об опасности вовремя не смог (как известно метрики мониторинга добавляются по мере возникновения несчастных случаев). К счастью “дно кризиса” пришлось на вечер воскресенья, к несчастью “круглосуточная техническая поддержка” хостера показала себя во всей красе, объяснив что на дворе в общем-то вечер, воскресенье, а ваша проблема до понедельника только ваша.
Чудо{вищная} часть на этом закончена, основная часть заметки не о том, что Русский Сервис™ не даст вам расслабиться, а о том, shit happens, страховаться от подобных случаев можно и нужно. Но первым делом нужно узнать о том, что проблема есть. И желательно не от ваших клиентов.
Итак задача – узнать отвечают ли NS-серверы правильным адресом.
#!/bin/sh
DOMAIN=${DOMAIN:-$1}
IPADDR=${IPADDR:-$2}
NAMESERVERS=$(dig +short @8.8.8.8 NS $DOMAIN)
if [ -z "${NAMESERVERS}" ]; then
echo -999 # "Unknown domain: $DOMAIN"
else
EXPECTEDCOUNT=0
ACTUALCOUNT=0
for ns in $NAMESERVERS; do
EXPECTEDCOUNT=$((EXPECTEDCOUNT + 1))
ACTUALCOUNT=$((ACTUALCOUNT + `dig +short $DOMAIN @$ns|grep -c ${IPADDR}`))
done
echo $((EXPECTEDCOUNT - ACTUALCOUNT))
fi
Скрипт покажет количество NS-серверов, которые не вернули ожидаемый адрес. При любых ответах отличных от нуля стоит бить тревогу.
Теперь можно добавить в zabbix метрики вида external check или (как сделал я) zabbix trapper и переодически проверять “работоспособность” ваших DNS-ов. В перерывах между проверками можно основательно пересмотреть степень вашего доверия к своему DNS-хостеру, диверсифицировать DNS-хранилище, даже взять dns в свои умелые руки и разместить NS-серверы на подконтрольных машинах в разных частях света.
