Stručně: marně se snažím o návrat ke kombinaci, která kdysi na Turrisu 1.x fungovala: totiž unbound, který se ptá na “lokální záležitosti” dnsmasq na nestandardním portu. Rozbilo to v podstatě zavedení resolveru a následující úpravy.
Podrobně: aktuálně mám v /etc/config/resolver napsáno
config resolver 'unbound_includes'
list include_path '/etc/unbound/user.conf'
a v /etc/unbound/user.conf
server:
domain-insecure: "intra."
private-domain: "intra."
private-address: 192.168.1.0/24
domain-insecure: "1.168.192.in-addr.arpa."
private-domain: "1.168.192.in-addr.arpa."
local-zone: "1.168.192.in-addr.arpa." nodefault
do-not-query-localhost: no
do-ip6: no
stub-zone:
name: "intra."
stub-addr: 127.0.0.1@5353
stub-zone:
name: "1.168.192.in-addr.arpa."
stub-addr: 127.0.0.1@5353
Jenže ono to nefunguje, i když na 5353 poslouchá správně nakonfigurovaný dnsmasq (ověřeno, na přímo položené dotazy odpovídá jak má).
Záměrně píši do české části fóra, protože se to týká Turrisu 1.x (a nechci mást uživatele Omnií). Pokud jsem to postřehl správně, lze podobnou konfiguraci (tedy kresd+dnsmasq na vyšším portu pro lokální doménu) použít i na Omnii - a údajně funguje.
Zatím mám podezření na to, že záznamy typu local-zone, local-data a local-data-ptr, které automaticky a natvrdo do konfigurace unboundu vnutí resolver, resp. init-skript unboundu mají “vyšší prioritu” než stub-zone a tím uživatelskou konfiguraci rozbijí.
Mohl by se prosím ozvat někdo, kdo rozumí konfiguraci unboundu, nebo případně někdo, komu výše popsané schéma funguje?
V ideálním případě bych uvítal reakci od někoho z týmu, protože asi není problém to zprovoznit nějak “hrubou silou” - jenže se chci vyhnout situaci, kdy mi to rozbije každý druhý update.
Díky!
