Turris 1.x a lokální DNS a kombinace dnsmasq/unbound

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!

Pokud jde o překlad jmen zařízení v lokální síti, tak to mám na svém Turris 1.1 rozchozeno, dle návodu ze “starého” fóra …

Lokální síť mám na rozsahu 192.168.200.0/24 … přípona domácího rozsahu je .home

obsah souboru /etc/unbound/home.conf

server:
domain-insecure: “home.”
private-domain: “home.”
do-ip6: no
do-not-query-localhost: no
stub-zone:
name: “home.”
stub-addr: “127.0.0.1@53535”

server:
domain-insecure: “200.168.192.in-addr.arpa.”
stub-zone:
name: “200.168.192.in-addr.arpa.”
stub-addr: “127.0.0.1@53535”

server:
local-zone: “168.192.in-addr.arpa.” nodefault

fragment souboru /etc/config/dhcp

config dnsmasq
option domainneeded ‘1’
option boguspriv ‘1’
option localise_queries ‘1’
option rebind_protection ‘1’
option rebind_localhost ‘1’
option expandhosts ‘1’
option authoritative ‘1’
option readethers ‘1’
option leasefile ‘/tmp/dhcp.leases’
option resolvfile ‘/tmp/resolv.conf.auto’
option localservice ‘1’
option port ‘53535’
list server ‘193.29.206.206’
list server ‘217.31.204.130’
list server ‘2001:1488:800:400::130’
list server ‘2001:678:1::206’
option dhcpscript ‘/etc/resolver/dhcp_host_domain_ng.py’
option nonwildcard ‘0’
option local ‘/home/’
option domain ‘home’

fragment souboru /etc/config/resolver - na konci mám přidáno

config resolver ‘unbound_includes’
list include_path ‘/etc/unbound/home.conf’

To je tuším vše, takto to mám cca od cca 3.8.x a nic mi to nerozbíjí (a to pravidelně testuju RC verze) …

ping na virtuál v lxc: debian2

Zkontroloval jsem co se dalo - a stále nic. Ale napadla mě jedna věc, která souvisí s mým dřívějším podezřením. Máte část adres přidělovanou staticky? Pokud ano, ve kterém souboru máte statická přiřazení definována?

Ano, prevazna cast zarizeni ma pridelovane ip adresy statickym dhcp dle mac, tyto jsem zadaval pres luci a jsou uvedeny v /etc/config/dhcp

A můžete se prosím ještě podívat:

  1. Jak vypadá Váš /etc/unbound/unbound.conf (předpokládám, že tam budou statické záznamy)? Konkrétní statické záznamy (local-*) klidně promažte, jde o princip…

  2. Jestli se správně resolvuje něco, co v /etc/config/dhcp není - typicky třeba hostname turrisu, které je jen v /etc/config/system (dnsmasq si ho tam přečte a umí ho resolvovat; unbound/resolver právě ne).

  3. Pokud máte i hostname turrisu v /etc/config/dhcp, zkuste ho prosím na chvíli zakomentovat (a uvést je namísto toho v /etc/config/system) a pak zjistit, jestli se i nadále resolvuje správně. Tedy - pokud Vám ještě nedošla trpělivost :grinning:

Díky moc!

Kdyby to případně sledoval ještě někdo jiný, objevil jsem zajímavou věc. S výše uvedenou konfigurací dostanu během několika sekund (max. 30, spíše méně) po restartu unboundu na dotaz na hostname routeru (dig turris.intra) odpověď NXDOMAIN, ale na reverzní dotaz (dig -x 192.168.1.1) správnou odpověď. Po chvíli alě (zřejmě) někde vyprší nějaká cache a hostname routeru se neresolvuje už ani reverzně.

Bez ohledu na popsanou podivnost to na mě ale pořád dělá ten dojem, že všechny dotazy resolvuje unbound (na základě strojově vytvořených local-*) a dnsmasq vesele ignoruje.

ad 1) ano, je zde sestava lokálních statických záznamů …
ad 2) ano, hostname turrisu se resolvuje správně:

Pinging tomasarouter.home [192.168.200.1] with 32 bytes of data:
Reply from 192.168.200.1: bytes=32 time<1ms TTL=64

a bohužel žádné zařízení neuvedené v /etc/config/dhcp teď v síti aktivní nemám

ad 3) hostname turrise v /etc/config/dhcp není, v /etc/config/system je “option hostname ‘TomasArouter’

Na úpravy a pokusy dneska bohužel nemám prostor, pokud bude potřeba, snad někdy jindy.

Díky moc. Já jsem zatím zjistil, že problém je jednoznačně v unboundu - ignoruje uživatelskou konfiguraci a na lokální zónu se nikde neptá.

Až budete mít čas a náladu, mohl byste prosím ještě postnout Váš /etc/unbound/unbound.conf? Klidně zase bez lokálních záznamů. Děkuji!

Já to používám také na 1.0 od samého počátku
v /etc/config/resolver skoro na konci v sekci config resolver ‘unbound_remote_control’ mám
list include_path '/etc/unbound/lan.conf’
a v tomto souboru (kolega tomas.andrasko to má skoro stejně v home.conf) je zadáno

stub-zone:
name: "MistniDomena."
stub-addr: “127.0.0.1@5353”

stub-zone:
name: "10.in-addr.arpa."
stub-addr: “127.0.0.1@5353”

(používám lokální adresy 10.x.y.z tak to reverzní je trochu jiné)
Možná bych připomenul, že ty jména domén končí “.” bez ní to tuším nefunguje

(dokonce si nechávám úplně mimo defaultní forwarding některé domény forwardovat na konkrétní DNS server - zapsáno v Luci jako “Přeposílání DNS”)

s lokálními fixními záznamy to mám obdobně jsou dhcp.conf (přidávám/opravuji je pomocí Luci, nyní bez problémů), jen jsem si pro překlady i krátkých jmen vytvořil shell skript který z dhcp.conf vytváří “Dodatečný Hosts soubor” (označení v Luci - Soubory resolv a hosts) /tmp/hosts.fixed a ten spouštím každých 5 minut cronem
struktura toho souboru je jednoduchá IP jmeno jmeno.“Mistnidomena” (Mistnidomena je to co je zapsáno v Luci - obecné v kolonce Místní doména)
takže ten záznam pro cron /etc/cron.d/hosts_fixed
MAILTO=""
*/5 * * * * root /root/sh/hosts.fixed.sh /etc/config/dhcp > /tmp/hosts.fixed
a ten script /root/sh/hosts.fixed.sh
awk -F’ ‘/name / {jmeno=$2}
/ip / {print $2,jmeno,jmeno".Mistnidomena"}’ $1

Jo ještě jedno, tuším, že unbound si konfiguraci načítá při startu, takže po změně se musí restartovat, jinak to vypadá, že “se nic neděje”

V podstatě jediný důvod, proč jsem zprovozňoval to resolvování lokálních jmen, bylo resolvování jména Turrise kvůli certifikátu pro lighthttp, bez toho to nefungovalo korektně. Tohle mi funguje a žádné jiné fíčury jsem od toho neočekával. To jen na okraj, pokud tam nefungují jiné věci (např. ty “testy” přes dig apod. ), tak to fakt neřeším - ale jako studijní materiál je to pro mně k nezaplacení :slight_smile:

Ten unbound.conf pošlu odpoledne z domu, ač mám funkční OpenVPN, tak z práce si ani neu… :disappointed_relieved:

Nemusíte, nepomůže to…

Zkoušel jsem samozřejmě všechno možné i nemožné, ale problém je nakonec opravdu v kombinaci resolver/unbound, která vše tak dlouho vylepšovala …až to nakonec rozbila.

Hned na začátek upozornění pro všechny, kterým to “funguje”. Pokud jsem se zásadně nezmýlil, tak základní schéma (unbound jako rekurzivní resolver s delegováním lokální domény na dnsmasq poslouchající na vyšším portu) funguje - ale jen pro zónu, kterou nemáte v /etc/config/dhcp.

Pokud ji tam totiž máte, inicializační skripty resolveru/unboundu doplní o své vůli do konfigurace unboundu sadu záznamů local-*, které mají (asi) přednost před jakýmikoli záznamy typu stub-zone, forward-zone, apod. Unbound tedy na základní jednoduché dotazy odpoví, ale ve skutečnosti bohapustě lže a dnsmasq se na nic neptá, i když tak byl adminem nakonfigurován. <flame> Nepříjemně mi to připomíná přístup některých nechvalně známých tvůrců SW</flame>

Pro úplnost: na výše uvedené usuzuji na základě jednoduchého pokusu. stub-addr jsem nastavil na jiný stroj v síti (s puštěným tcpdumpem), abych měl jistotu, zda se unbound na něco ptá jiného serveru nebo ne. A nic. Ovšem jakmile jsem do konfigurace přidal další stub-zone (pro neexistující doménu) a zeptal se na ni, dotazy najednou přišly…

Otázka je, co s tím. Napadá mě:

  • přidat do resolveru předvolbu, která by potlačila generování statických záznamů (local-*) do unbound.conf
  • vyhodit konfiguraci statického DHCP z /etc/config/dhcp a napsat ji přímo do /etc/dnsmasq.conf (a tím se také zbavit local-*)
  • zkusit nahlásit bug do unboundu, pokud je to popsané chování špatně
  • přestat generovat local-*, protože teď máme option dynamic_domains v /etc/config/resolver, která by vlastně měla právě tohle zajistit

Samozřejmě počítám s tím, že tam mám někde chybu. Právě proto bych ale uvítal, kdyby se k tomu mohl vyjádřit i někdo z Turris týmu - určitě tam budou lidé, kteří se v unboundu (a v DNS obecně) vyznají mnohem lépe než já.

Díky!

taky mi to nechodilo korektne, tak jsem zmenil v /etc/init.d/unbound

z:
echo " local-zone: “$DOMAIN.” static" >> “$CONFIGFILE”

na:
echo " local-zone: “$DOMAIN.” nodefault" >> “$CONFIGFILE”

a nyni to funguje

Díky za zprávu!

Předpokládám, že jde o konfiguraci, kde jsou jednotlivé stroje v lokální doméně nakonfigurovány běžným způsobem pomocí /etc/config/dhcp a jinak tam není kromě zmíněné úpravy /etc/init.d/unbound nic neobvyklého.

Aktuálně nemám možnost si to ověřit, takže prozatím mě napadají jen dva dotazy k upřesnění pojmu “funguje to”:

  • fungují reverzní dotazy?
  • fungují dotazy na MX záznamy?

ano, stroje jsou v /etc/config/dhcp, jina uprava neni, pouze v init scriptu.

user@debian:~# host ups.home
ups.home has address 192.168.1.59
user@debian:~# host 192.168.1.59
59.1.168.192.in-addr.arpa domain name pointer ups.home.

lokalni MX zaznamy nemam (na verejne to samozrejme funguje).

Pokud by to ještě po letech někoho zajímalo … Teď jsem to po letech řešil znova a máte úplně ve všem pravdu…Jak to řešit? V /etc/config/resolver nastavit option static_domains '0' a statické local-* záznamy se nebudou generovat a vše funguje jak má.

Nechtelo by se nekomu shrnout co vsechno je potreba upravit?
At delam, co delam, tak se mi hostname turrise a dalsi staticke hostnames (nakonfigurovane pres luci) neprekladaji.
Snazil jsem se napodobit navod dnsmasq na nestandartnim portu.

Kdyz restartuji resolver, tak prekladani statickych zaznamu na chvili funguje.

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

  1. 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).

  1. 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??? :smiley:) 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.

1 Like

Odpověď, co se změnilo, jsem našel v Changelogu programu dnsmasq, konkrétně verze 2.79, která je v aktuální verzi TOS3 má tuto novou vlastnost:

Always return a SERVFAIL answer to DNS queries without the recursion desired bit set, UNLESS acting as an authoritative DNS server. This avoids a potential route to cache snooping.

V režimu stub-zone se unbound ptá s vypnutým příznakem RD a dostává tedy od dnsmasq pouze chybovou zprávu. To se dá otestovat třeba přidáním flagu +nord k příkazu dig. Nicméně varianta s forward-zone by podle mě měla fungovat bez problémů. Mimochodem výše uvedená novinka byla hned ve verzi 2.80 zase odstraněna, resp. upravena tak, aby nepáchala tolik škody.

4 Likes

Veliké díky a svůj širák smekám a odhazuji v dál před takovouhle (ďábelsky rychlou a v tuto hodinu) reakcí a vše vysvětlující odpovědí. Já prošel změny v Unboundu mezi verzemi a logy, nic nenašel kromě zahozené odpovědi, nějaká fóra a vyřešil to sedlácky pomocí forwardování. Na změny v Dnsmasq jsem už neměl sílu, ač jsem zradu někde tam tušil :confused: … mea culpa a ještě jednou veliké díky, opět nasazujete laťku supportu zatraceně vysoko :laughing:

1 Like