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