Forward DNS podle subdomény

[PatrikSamuelTauchim]

Zdarec,
mám propojené celkem 3 routery přes wireguard (2x modrák, 1x omnia). Mezi sebou mají statické IPv4 a IPv6 routy a každý má svou subdoménu pod jednou doménou. Přes IP se na sebe klienti dostanou, ale rád bych, aby se na sebe dostali i přes doménová jména.

a = Modrák
b = Omnia

Na Omnii už jsem přidal custom.conf pro Knot a do něj:

policy.add(policy.suffix(policy.FORWARD(‘10.10.0.1’), {todname(‘b.dome.na.’)}))

a vypadá to, že to funguje.

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: a-turris.a.dome.na
Address 1: 10.10.0.1
*** Can’t find a-turris.a.dome.na: No answer

Očekával jsem, že na Modrákovi bude stačit jen v Luci > Network > DHCP and DNS do políčka DNS forwardings dát /b.dome.na/10.30.0.1 a bude to fungovat, ale nepodařilo se.

Server: 127.0.0.1
Address: 127.0.0.1#53

** server can’t find b-turris.b.dome.na: NXDOMAIN
** server can’t find b-turris.b.dome.na: NXDOMAIN

Co mi chybí, co dělám blbě a jak to napravit?

Předem díky!

[vcunat]

@PatrikSamuelTauchim

Luci > Network > DHCP and DNS

Pokud vím, v tomhle tabu jde nastavit v podstatě pouze chování dnsmasq. Upstream OpenWrt prostě jiné DNS “nepodporuje” a Turris tenhle tab nemění (myslím, alespoň ne výrazně v tomto ohledu).

[PatrikSamuelTauchim]

Hmm, měl jsem takové podezření, že mi Turris bude na tohle nastavení dlabat…

Do kterýho konfiguráku mám sáhnout a co tam nasypat? Mám to k tomuhle kousku 80km daleko, tak se snažím vyhnout metodě pokus/omyl podle Google…

[vcunat]

Dle rychlého pohledu do /etc/init.d/unbound (který generuje konfigurák pro Unbound) nevidím způsob jak to udělat konfigurací. Leda forwardovat všechno DNS, což jde třeba v reForisu triviálně naklikat.

Ale detailně neznám Turris 1.x a Unbound.

[PatrikSamuelTauchim]

Hmm, nějak jsem se dopracoval k tomu, co přidat. Myslím, že by měly stačit následující řádky, ale už jen přijít na to, kam s nimi.

/etc/unbound/unbound.conf se mi přepisuje obsahem z /etc/config/resolver, který má zase úplně jiný formát.

forward-zone:
name: “b.dome.na.”
forward-addr: 10.30.0.1
forward-addr: fd10:30:cbe8::1

Netuší někdo?

Nebo je nějaká možnost naroubovat na Modráka celý Knot Resolver, kde mi to funguje?

[vcunat]

@PatrikSamuelTauchim

Hmm, nějak jsem se dopracoval k tomu, co přidat. Myslím, že by měly stačit následující řádky, ale už jen přijít na to, kam s nimi.

No ano, to je jednoduchá část. Ale v tom skriptu pro generování konfigurace pro unbound jsem nenašel způsob jak přidat vlastní kusy konfigurace (předtím, na rychlý pohled, můžete zkusit hlouběji). Samozřejmě můžete ten generátor změnit, ale co když ho bude netriviálně měnit i nějaká aktualizace…

@PatrikSamuelTauchim

Nebo je nějaká možnost naroubovat na Modráka celý Knot Resolver, kde mi to funguje?

Do toho bych se na vašem místě nepouštěl.

Historicky byl problém s LuaJIT ná téhle obskurní variantě powerpc. Později na to upstream měl nějaké patche a @Pepe to myslím zkoušel, ale nevím proč to “nedopadlo”.

[PatrikSamuelTauchim]

Jsem právě zjistil, že je možné přes direktivu include v souboru /etc/config/resolver přeci jen možné do souboru /etc/unbound/unbound.conf něco přidat (dělá to tak třeba adblock). A tak jsem tam přidal odkaz na soubor, který obsahuje řádky výše, ale nic se (ani po restartu) nezměnilo. A tak zase budu chvíli zjiťovat, co dělám blbě nebo jestli je to úplná slepá ulička.

Forwardovat vše nevím jestli se mi chce, to bych zase určitě narazil na jiné překážky…

[Pepe]

Historicky byl problém s LuaJIT ná téhle obskurní variantě powerpc. Později na to upstream měl nějaké patche a @Pepe to myslím zkoušel, ale nevím proč to “nedopadlo”.

Bohužel, ať jsem zkoušel jakoukoliv verzi *JIT (moonjit a teď už vlastně luajit2), tak s tím máme problémy, které nám znemožnují používat Knot Resolver na powerpc. Např.

Segfault on powerpc

Ale vypadá to, že LuaJIT repozitář ožívá a možná by to stálo za to, abychom to vyzkoušeli, ale nevidím to moc reálně. A ano, dost by nám pomohlo, když na všech routerech bychom měli Knot Resolver.

[Ondrej_Caletka]

Tahle cesta by měla fungovat. Podle mě ještě chybí v konfiguraci:

domain-insecure: "b.dome.na."

Bez toho privátní doména neprojde validací DNSSEC, takže server bude vracet chybový kód SERVFAIL.

[PatrikSamuelTauchim]

Ondřeji,
jestli na tom záleží, tak se jedná o doménu veřejnou (registrovanou).

Na dotaz (v Luci Modráka) dostanu odpověď:

Server: 127.0.0.1
Address: 127.0.0.1#53

** server can’t find hostname.b.dome.na: NXDOMAIN
** server can’t find hostname.b.dome.na: NXDOMAIN

[Ondrej_Caletka]

Dobře, to tedy vypadá na konfigurační chybu, a Unbound se zřejmě dívá do veřejného DNS. Zkontrolujte za běhu v /var/etc/unbound/unbound.conf, jestli tam je řádek include: s cestou ke konfiguračnímu snippetu.

Pokud ne, nastavení v /etc/config/resolver musí vypadat takhle:

config resolver 'unbound_includes'
 	list include_path "/etc/unbound/snippet.conf"

A startovat pomocí /etc/init.d/resolver restart (Tohle je Turris-specifická věc, kdy startovací skript resolver spouští unbound na PPC a kresd na ostatních.)

[PatrikSamuelTauchim]

Udělal jsem “cat” zmíněných souborů a všiml jsem si, že v include se místo uvozovek, mezi kterými je doména, zobrazuje jakýsi patvar. Nahradil jsem ho tedy " a po restartu se výstup změnil na:
;; connection timed out; no servers could be reached

Stále to nefunguje, ale alespoň nějaká změna.

root@a-turris:~# cat /var/etc/unbound/unbound.conf

auto-generated config file from /etc/config/resolver

server:
chroot: “”
verbosity: 0
interface: 0.0.0.0
interface: ::0
port: 53
auto-trust-anchor-file: /var/etc/unbound/root.keys
edns-buffer-size: 1232
msg-cache-size: 20M
outgoing-interface: 0.0.0.0/0
outgoing-interface: ::0/0
prefetch: yes
local-zone: “a.dome.na.” static
local-data: “a-turris.a.dome.na. IN A 10.10.0.1”
local-data-ptr: “10.10.0.1 a-turris.a.dome.na”
outgoing-range: 60
outgoing-num-tcp: 1
incoming-num-tcp: 1
msg-cache-slabs: 1
num-queries-per-thread: 30
rrset-cache-slabs: 1
rrset-cache-size: 100K
infra-cache-slabs: 1
infra-cache-numhosts: 200
cache-max-negative-ttl: 1000
access-control: 0.0.0.0/0 allow
access-control: ::0/0 allow
username: “unbound”
pidfile: “/var/run/unbound.pid”
root-hints: “/etc/unbound/named.cache”
target-fetch-policy: “2 1 0 0 0”
harden-short-bufsize: yes
harden-large-queries: yes
qname-minimisation: yes
harden-below-nxdomain: yes
key-cache-size: 100k
key-cache-slabs: 1
neg-cache-size: 10k
prefetch: yes
prefetch-key: yes
include: “/var/lib/unbound/adb_list.overall”
include: “/etc/unbound/unbound-include.conf”
python:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-use-cert: no
control-port: 8953
server-key-file: “/etc/unbound/unbound_server.key”
server-cert-file: “/etc/unbound/unbound_server.pem”
control-key-file: “/etc/unbound/unbound_control.key”
control-cert-file: “/etc/unbound/unbound_control.pem”
forward-zone:
name: “.”
forward-first: yes
forward-addr: 10.255.255.20
forward-addr: 10.255.255.10
forward-addr: 2a02:768::2
forward-addr: 2a02:768::3

root@turris:~# cat /etc/unbound/unbound-include.conf
forward-zone:
name: “b.dome.na.”
forward-addr: 10.30.0.1
forward-addr: fd10:30:cbe8::1

[Ondrej_Caletka]

Teď je potřeba se podívat do logu, proč ten Unbound havaroval. Velice pravděpodobně je v některém z těch snippetů syntaktická chyba.

[PatrikSamuelTauchim]

Nevím, kde přesně bych měl hledat. Když dám restart, tak si to moc nestěžuje:

root@budweis-turris:~# /etc/init.d/resolver restart
Called /etc/init.d/unbound stop
set dhcp script
ls: /etc/resolv.conf.vpn.*: No such file or directory
Check generated config /var/etc/unbound/unbound.conf:
unbound-checkconf: no errors in /var/etc/unbound/unbound.conf
Called /etc/init.d/unbound start
set dhcp script
Called /etc/resolver/dhcp_host_domain_ng.py

Zapnul jsem si logování samotného unbound, kde se objevuje:

[1644270981] unbound[18026:0] info: 127.0.0.1 b-turris.b.dome.na. A IN
[1644270981] unbound[18026:0] info: 127.0.0.1 b-turris.b.dome.na. AAAA IN

[Ondrej_Caletka]

Takže pro normální resolving to funguje, jen nefunguje privátní doména?
Tak to vypadá, že jde o druhotný problém - unbound se zřejmě nedokáže spojit se servery pro danou forward zónu. Zkuste, jestli na dotaz na ty adresy, kam se forwarduje, skutečně funguje.

[PatrikSamuelTauchim]

No, ten dotaz by měl být forwardován na 10.30.0.1, kde sedí Omnie s Knotem a zná všichny hosty na b.dome.na

Stejný dotaz na Omnii projde:

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: hostname.b.dome.na
Address 1: 10.30.100.1
*** Can’t find hostname.b.dome.na: No answer

Na ping mi odpoví. Nevím, že by to zařízl třeba firewall? Nebo Knot nechce odpovídat dotazy, které chodí přes Wireguard?

Opačně (z Omnie na Modráka) mi to funguje:

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: hostname.a.dome.na
Address 1: 10.10.0.172
*** Can’t find hostname.a.dome.na: No answer

[vcunat]

No já nevím, tak třeba dotaz ručně z místa kde běží ten unbound? dig @fd10:30:cbe8::1 hostname.a.dome.na

[PatrikSamuelTauchim]

Díky, to je to co jsem potřeboval. Vrátilo to:

;; reply from unexpected source: fd42:42:42::3#53, expected fd10:30:cbe8::1#53

fd42:42:42::3 je adresa Omnie z WG rozsahu, v lanu má tu fd10:30:cbe8::1

Nevím, proč se odpoveď vrací z této druhé adresy, ale klidně budu DNS dotazy forwardovat na ni.

dig @fd42:42:42::3 hostname.b.dome.na

; <<>> DiG 9.16.23 <<>> @fd42:42:42::3 hostname.b.dome.na
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54782
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;hostname.b.dome.na. IN A

;; ANSWER SECTION:
hostname.b.dome.na. 5 IN A 10.30.20.1
hostname.b.dome.na. 5 IN A 10.30.100.1

;; Query time: 40 msec
;; SERVER: fd42:42:42::3#53(fd42:42:42::3)
;; WHEN: Tue Feb 08 10:35:58 CET 2022
;; MSG SIZE rcvd: 85

Změnil jsem tedy adresy v souboru unbound-include.conf na adresy z WG rozsahu:

forward-zone:
name: “b.dome.na.”
forward-addr: 10.10.20.3
forward-addr: fd42:42:42::3

A už to funguje!

Server: 127.0.0.1
Address: 127.0.0.1#53

Name: hostname.b.dome.na
Address 1: 10.30.20.1
Address 2: 10.30.100.1
*** Can’t find hostname.b.dome.na: No answer

Díky moc za pomoc

[vcunat]

Aha, no tohle je nedostatek Knot Resolveru za určité kombinace podmínek. Komplikované detaily se lze dočíst okolo resolver-conf: Please disable open resolver in the config (#20) · Issues · Turris / Turris OS / Turris OS packages · GitLab