Один известный 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-серверы на подконтрольных машинах в разных частях света.