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

dns

#1

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!


#2

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


#3

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?


#4

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


#5

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!


#6

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.


#7

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.


#8

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!


#9

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”


#10

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:


#11

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!


#12

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


#13

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?

#14

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