Посоветуйте, как организовать dns-сервер в локалке.

А я не осилил зачем такая конструкция? RPi - потом еще один роутер (почему еще не 10? :) ), зачем плодить сущности?

RPi потому что роутер не умеет работать с usb-модемами и hdd, а роутер потому что RPi не умеет создавать точку доступа wifi и имеет сетевой интерфейс только для 1 устройства.

RPi не умеет создавать точку доступа wifi

Умеет, делал так. Один eth можно обойти при помощи usb-сетевух (для выхода в Интернет ее производительности должно хватить, но цена сопоставима с ценой бюджетного роутера обычно).

Вопрос: как проще и надёжнее организовать получение адресов dns серверов провайдера (8.8.8.8 не предлагать) по dhcp? Предполагается что провайдер будет менять их, или меняться сам. Поднятие и перезапуск всей этой конструкции предполагается заскриптовать и повесить на подключение юсб-модема.

Так а в чем проблема? Ну повесьте дополнительный перезапуск при изменении resolv.conf (через тот же inotify можно отслеживать).

на данный момент не осилил включить кеширование dns

Тут лучше один раз увидеть конфиг с диагностикой. Вообще кэширование там, емнип, из коробки идет, но храниться около 100 адресов, может в этом дело? И «добавление 2-5 секунд» - у меня прямой запрос к гугловым dns занимает меньше секунды, видно у вас там есть какое-то узкое место, и вряд ли это dnsmasq - что-то очень долго получается, даже при учете того что ему нужно сходить на внешние сервера.

Так в чем проблема, роутер делаем обычной ap и все, не?

Тут лучше один раз увидеть конфиг с диагностикой.

root@raspberrypi:~# cat /etc/dnsmasq.conf 
no-dhcp-interface=usb0
no-dhcp-interface=ppp0
no-dhcp-interface=eth0

bogus-priv
#interface=eth0
no-resolv
server=213.87.72.155
server=213.87.75.99
cache-size=1000

Тут всё вроде бы работает примерно так, как написано. Ошибок нет. Но это не то, что мне надо: адреса dns серверов провайдера должны не прописываться в конфиге, а браться от провайдера, по dhcp, с интерфейса ppp0. По данным гугла dnsmasq так вообще не умеет.

А косяк со временем - разрешение любого dns запроса всякими браузерами, wget и т.д. занимает 1-2 сек на RPi и 3-5 сек на клиентах локалки. До этого вместо юсб-модема использовался смартфон на андроиде, роутер выдавал его IP а качестве dns-сераера и все устройства получали ответ на запрос через 1-2 сек.

роутер делаем обычной ap и все

Что имеется в виду?

Access Point. Зачем он нужен как роутер если вам от него надо только ap и свич?

Access Point от чего до чего? Это раньше RPi был просто прослойкой м/у смартфоном и роутером с функцией файлопомойки и торрентов. А сейчас он должен поднять ppp через модем и раздать его.

Он поднимает и раздаёт. Осталось только адреса dns серверов до устройств донести. Я могу их на роутер прописать, он донесёт. Но ведь провайдер их может поменять, тогда мне придётся бежать, перенастраивать, объяснять родственникам почему не работает когда надо.

Стоп, возможно я не правильно понял. rpi работает роутером и на ней крутиться dnsmasq все остальные устройства являются клиентами сети от rpi?

все остальные устройства являются клиентами сети от rpi?

Да, за исключением двух НО:

- rpi подключен патчкордом к WAN порту роутера
- dhcp поднят на роутере для локалки.

Тогда возвращаемся к тому что я писал в самом начале. Нафейхуа двойной роутинг устраивать? Исходя из описанных вами задач переводим роутер в режим ap, т.к. модели роутера мы не знаем то возможно еще переткнуть из wan в lan провод от rpi.

Тогда мне придётся поднять на rpi ещё и dhcp. Разве это упростит настройку dns на rpi? Плюсом к этому я получу мёртвую локалку если rpi зависнет, и будут ли клиенты связываться между собой? Будут ли падения скорости передачи данных когда на rpi работают несколько приложений с nice 0 (а ещё возможен свопинг)?

Роутер - tp-link нижнего уровня с dd-wrt

В продолжение: в dnsmasq cache-size пробовали увеличить?

cache-size=1000

вот только это не работает. ping например посылает отдельный запрос на каждый пакет, само время отклика небольшое, но интервал между запросами соответствующий.

Кстати, как проверить, что он вообще существует и используется?

Тогда мне придётся поднять на rpi ещё и dhcp.

dnsmasq вообще-то умеет работать dhcp сервером, это вы его отключили в конфиге, не понятно зачем. Если я правильно понял схему rpi - router - lan. То достаточно на rpi в dnsmasq поднять dhcp на локальном интерфейсе который отдаст по dhcp роутеру в том числе и dns. Если прописать маленький lease time то наверное в целом все будет работать, не думаю что пров так уж часто dns меняет.

Плюсом к этому я получу мёртвую локалку если rpi зависнет

Мертвую локалку вы получите если ваш tp-link зависнет, в случае если он и как свич работает. А вероятности зависнуть у них приблизительно равные, хотя я больше склоняюсь к тому что tp-link зависнет раньше чем малина.

и будут ли клиенты связываться между собой?

Почему нет? Пока lease time не прошел.

Будут ли падения скорости передачи данных когда на rpi работают несколько приложений с nice 0 (а ещё возможен свопинг)?

«падения скорости передачи» куда? В инет? так оно и в вашей схеме так же будет. Если между клиентами то опять причем тут dhcp сервер?

А вероятности зависнуть у них приблизительно равные

После перепрошивки ни одного зависания за 2 года. А rpi иногда ложится в своп из за скриптов бэкапа поверх ещё чего нибудь.

Да, пожалуй ваша схема логичней. Но всё таки, dnsmasq умеет брать адреса dns сервера откуда то, кроме своего конфига?

cache-size=1000

Например если активно пользуем торенты вообще не о чем. Ставьте больше.

Кстати, как проверить, что он вообще существует и используется?

перезапускаем dnsmasq
на малине tcpdump -i any -n port 53
на клиенте делаем ping -n www.ru
видим в первом запросе будут обращения к dns прова
на втором клиенте ping -n www.ru
и видим что обращений к dns прова нет
Вот как-то так должно быть.

B еще не забывайте что клиенты вообще-то сами кэширует. Что-то мне подсказывает не там вы проблему ищите.

Но всё таки, dnsmasq умеет брать адреса dns сервера откуда то, кроме своего конфига?

Если не запретить, то по умолчанию из /etc/resolv.conf :) Намек ясен :)

А rpi иногда ложится в своп из за скриптов бэкапа поверх ещё чего нибудь.

Это сильно! так пользовать малину, вы знаете толк... :)

Итого проблема почти решена через dnsmasq со следующим конфигом (осталось вернуть роутер в цепочку для работы на много клиентов):

bogus-priv

interface=eth0
dhcp-range=192.168.200.100,192.168.200.199,2h
dhcp-option=2,255.255.255.0
dhcp-option=3,192.168.200.200
log-dhcp
log-facility=/var/log/dnsmasq.log

cache-size=500
resolv-file=/etc/ppp/resolv.conf

Проблема в огромном времени разрешения вопроса скорее всего была из за роутера - там тоже есть dnsmasq и он тоже перенаправлял через себя все запросы.