Znova jsem to řešil dnes, protože na modrákovi v1.0 někde mezi Turris OS v3.11.19.1 a v3.11.23 došlo k nějaké změně a Unbound opět přestal resolvovat lokální záznamy skrze Dnsmasq. Takže to zkusím celé sesumírovat:
krok 0) [nepovinný] ve Forisu v sekci DNS vypneme volbu Enable DHCP clients in DNS. Změna se projeví v souboru /etc/config/resolver v sekci config resolver 'common' nastavením option dynamic_domains '0' (viz krok 2)
POZN: tohle ničemu nevadí, nastaveno na 1 Unbound resolvuje DHCP dynamicky přidělené adresy. Pro naše účely to nemá na nic vliv (stejnou funcionalitu zastane následně nakonfigurovaný Dnsmasq), jen lokální doménu budete moci nastavovat na 2 místech - ve Forisu i v LuCI. Preferují čisté řešení a nastavením na 0 to vypnout, stejně se Unbound bude dotazovat Dnsmasq a tato jeho funkcionalita zůstane nevyužita.
krok 1) soubor /etc/config/dhcp
do sekce config dnsmasq přidat/změnit:
option port '5353'
option local '/mojelan/'
option domain 'mojelan'
POZN: port na kterém poběží lokální resolver Dnsmasq (bude resolvovat všechny DHCP dynamicky přidělené adresy, staticky nastavené DHCP adresy přes LuCI a záznamy z LuCI v Network / Hostnames). Stejného výsledku dosáhneme přes LuCI v Network / DHCP and DNS [Advanced Settings] / DNS server port
Stejně tak přes LuCI v Network / DHCP and DNS [General Settings] / Local server a Local domain nastavení jména lokální domény
krok 2) soubor /etc/config/resolver
- v sekci
config resolver 'common' změnit:
option static_domains '0'
option dynamic_domains '0'
POZN: option static_domains '0' vypne generování statických záznamů skriptem při startu Unboundu natvrdo do /etc/unbound/unbound.conf. Pro option dynamic_domains viz krok 0).
- na konec souboru přidat cestu k našemu konfiguračnímu souboru:
config resolver 'unbound_includes'
list include_path '/etc/unbound/mojelan.conf'
krok 3) vytvořit soubor /etc/unbound/mojelan.conf s následujícím obsahem:
server:
private-domain: "mojelan."
domain-insecure: "mojelan."
domain-insecure: "1.168.192.in-addr.arpa."
local-zone: "168.192.in-addr.arpa." nodefault
do-not-query-localhost: no
forward-zone:
name: "mojelan."
forward-addr: 127.0.0.1@5353
forward-zone:
name: "1.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@5353
POZN1: žádné jiné parametry (např. local-zone: "mojelan." nodefault nebo private-domain: "1.168.192.in-addr.arpa." nebo private-address: ...), jak je tady ve vlákně občas chybně uvedeno, nejsou třeba (viz dokumentace https://nlnetlabs.nl/documentation/unbound/unbound.conf/), naopak (např. private-address: ...) jsou chybou a vypnou resolvování daného rozsahu atd.
POZN2: jak avizuji výše, mezi verzemi Turris OS v3.11.19.1 a v3.11.23 se něco změnilo a přestaly fungovat stub zóny. Dříve bylo místo forward-zone a forward-addr použito stub-zone a stub-addr. Podle dokumentace je mezi stub a forward rozdíl v authoritative/resolving použití, v našem případě by to tedy ničemu nemělo vadit:
Stub -zone is only used to point queries to an authoritative server like a NSD dns server. The forward -zone directive can only be used to point queries to a resolving dns server like OpenDNS.com or you local ISP’s caching server.
POZN3: Možná někdo zkušenější a věci znalý (@Ondrej_Caletka??? 
) osvětlí co mám špatně — Unbound se zjevně zeptá Dnsmasq správně, odpověď ale zahodí info: query response was THROWAWAY, možná špatně nakonfigurovaný Dnsmasq (výchozí autoritativní nastavení)???
Nějaké info např. tady https://wiki.archlinux.org/index.php/Unbound, mimo jiné:
Note: There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a BIND DNS server if it is providing authoritative DNS - but if you are referring queries to an unbound server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.
krok 4) ověření funcionality z konzole turrisu:
root@turris:~# dig +short @127.0.0.1 -p 53 turris.mojelan
192.168.1.1
root@turris:~# dig +short @127.0.0.1 -p 53 -x 192.168.1.1
turris.mojelan.
ověření statického “hostname” záznamu (možno zadat např. přes LuCI v Network / Hostnames):
root@turris:~# dig +short @127.0.0.1 -p 53 testhost.mojelan
192.168.1.222
root@turris:~# dig +short @127.0.0.1 -p 53 -x 192.168.1.222
testhost.mojelan.
… mea culpa a ještě jednou veliké díky, opět nasazujete laťku supportu zatraceně vysoko 