ТрудовыЕбудни #1

Mar 29, 2017 14:17


В процессе банальных трудовых будней влетел в две занятных проблемы.

... Есть широко распространённый демон DNSMasq, который очень любят в том числе и всякие производители embedded-решений в силу его легковесности и умения делать Split DNS. В том числе он используется внутри OpenWRT. И у оной софтины есть одна очень любопытная то ли фича, то ли особенность.

Допустим, имеется несколько (пусть будет два) upstream-серверов. Если хотя бы один из них доступен, то DNSMasq ресолвит доменное имя и возвращает результат клиенту. Если они оба недоступны (допустим, пакеты от демона до upstream-а теряются или drop-аются где-то по дороге), то DNSMasq не отвечает своему клиенту вообще ничего. Просто молчит. Но! Если при обращении к upstream-у DNSMasq получает какое-нибудь ICMP-сообщение типа "Port Unreachable" или "Net Prohibited", то он сам в свою очередь спускает клиенту DNS-ответ со статусом "Refused". А клиенты, знаете ли, бывают всякие.

Например тот, который встроен в МФУ имени Hewlett-Packard, получив хотя бы один раз такой отлуп, впадает в ступор и даже и не пытается заново разресолвить "проблемное" имя ни при каких обстоятельствах. Так что когда пользователи начинают жаловаться, что у них "не сканируется", единственный метод решения - физически выключить и включить устройство. Что меня довольно сильно напрягает. Особенно учитывая то, что в веб-морде этого МФУ отсутствует штатная кнопка "перезагрузить".

И вот как расово правильно можно решить этот вопрос, мне пока непонятно. Первое, что приходит в голову - тупо жестко прописать в DNSMasq-е IP-адрес файл-сервера, куда идёт сканирование. Быстро, но некрасиво. Второй вариант - поднять что-то вроде Secondary DNS. Но я не уверен, что на такой финт ушами хватит ресурсов роутера. И вообще, у меня сомнения простираются шире. Насколько вообще правомерно и RFCшно выдавать клиенту "Refused", если мы не смогли связаться с upstream-ом? Не является ли такое поведение DNSMasq-а багом? Пока что я не знаю.

... И ещё один момент, связанный с OpenWRT. Многие библиотеки из его дистрибутива (например, openssl или polarssl) жёстко привязаны к конкретной версии ядра. И если вдруг ядро окажется свежее, чем нужно, то ничего не "взлетит". Чувствуете, чем это пахнет? Допустим, у вас в руках оказалась железка, которую по каким-то причинам "не понимает" ядро из стабильного релиза. В этом случае у вас есть ровно четыре выхода.
  1. Использовать транк. Но как показывает мой личный опыт, софт в нём уж о-о-о-очень сырой и глючный.
  2. Взять ядро из snapshot-а. Но в таком случае и софт тоже придётся ставить из того же snapshot-а. И если вдруг понадобится обновиться по прошествии какого-то времени...
  3. Собирать все пакетики самому, ручками. Та ещё развлекуха, ага.
  4. Не ставить никакой сторонний софт, довольствоваться тем, что есть "из коробки".
Я пребываю в глубоких раздумьях. Так и не могу решить для себя, что хуже.

dns, администрирование, openwrt, работа, it

Previous post Next post
Up