Automatická registrace DHCP hostů nefunguje

Software [CZ] SW chyby-diskuze [CZ]
,
1

Ahoj.

Rád bych měl automaticky funkční registrace DHCP jmen, která na síti žádají o adresu. Snažím se používat reforis nastavení, kde to jde. Registrovat DHCP klienty v DNS mám zapnuté, bohužel nevidím, že by to fungovalo. V Reforis Nastavení sítě/DNS.

dnsmasq tohle dělá sám od sebe, aniž by se cokoliv muselo nastavovat. Mám doménu ko.home.arpa. Jména z /tmp/dhcp.leases jsou, ale ani přímo na turrisu resolvovat nejdou. Nefunguje ani registrace jména turris serveru samotného.

Zdá se mi, že to zařezává knot samotný, protože home.arpa nemá být posíláno dál. To je správně, nicméně lokálně vážně chci možnost to resolvovat… Také s funkčními reverzními záznamy.

; <<>> DiG 9.18.24 <<>> menturris.ko.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41561
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 21 (Not Supported): (CR36)
;; QUESTION SECTION:
;menturris.ko.home.arpa.		IN	A

;; AUTHORITY SECTION:
menturris.ko.home.arpa.	10800	IN	SOA	menturris.ko.home.arpa. nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.	10800	IN	TXT	"Blocking is mandated by standards, see references on https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Sep 01 10:39:48 CEST 2024
;; MSG SIZE  rcvd: 284

Dalo by se to zprovoznit posloucháním dnsmaqu na alternativním portu na localhostu, kde by kresd přeposílal requesty pro tuhle doménu na něj. Netuším, jak přesně mají být ty adresy registrovány do kresd, ale alespoň u mě to teda nefunguje.

Samotná doména ko.home.arpa taky vrací, že neexistuje.

; <<>> DiG 9.18.24 <<>> ko.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34778
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 21 (Not Supported): (CR36)
;; QUESTION SECTION:
;ko.home.arpa.			IN	A

;; AUTHORITY SECTION:
ko.home.arpa.		10800	IN	SOA	ko.home.arpa. nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.	10800	IN	TXT	"Blocking is mandated by standards, see references on https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Sep 01 10:50:55 CEST 2024
;; MSG SIZE  rcvd: 274

Může být problém v tom, že jsem použil home.arpa na něco, k čemu je určená?

2

Default je .lan a s tím by to mělo fungovat.

Jen že home.arpa. se má defaultně zařezávat (dle RFC) a výběr v reForisu tohle nevyřeší. Taková kombinace různých nastavení v Knot Resolveru 5.x moc dobře nefunguje; s 6.x to bude lepší, až bude dobře integrován do Turrisu.

3

Mno. Nemá se posílat dál. Což se s výchozím .lan, který v RFC řádně definovaný není, asi neděje. Nějak úplně nerozumím, proč je v nich významný rozdíl :slight_smile:

U unboundu se podobné built-in domény dají deaktivovat, aby šly forwardovat. Neznám dostatečně knot resolver, abych to uměl najít v něm. Navíc, já to zatím nikam forwardovat nepotřebuji. V podstatě mi stačí, aby ty záznamy byly lokálně v knotu. Alespoň tak to dělá bind9, který jenom definuje prázdnou home.arpa doménu. explanation.invalid. by byla pěkný hint, kdyby to šlo vypnout. To nejde? ko.home.arpa. je víc specifické, než home.arpa..

Našel jsem jen Query policies — Knot Resolver 5.7.4 documentation, ale ani z toho nepoznám, jak vypnout speciální chování k home.arpa doméně (a jeho pod-doménám). Jde to alespoň ručně, když už se to neděje automaticky z použité domény?

4

V unboundu by stačilo přidat local-zone: home.arpa nodefault do konfigurace. Nemůžu ale najít žádné nastavení k home.arpa. Jediná zmínka je v Release notes — Knot Resolver 5.7.4 documentation, ale to není dostatečně konkrétní. Mám Knot Resolver, version 5.7.4, takže bych danou změnu měl mít u sebe.

5

Nejjednodušší nejspíš bude použít knot-resolver6 balík. Protože tam jsou tyhle věci přepracované tak, že se taková nastavení kombinují rozumnějším způsobem a tohle konkrétně by tam mělo prostě fungovat (pokud jsem nezapomněl na něco).

6

knot-resolver6 já v opkg list vůbec nemám.

sudo opkg list knot-resolver\*
knot-resolver - 5.7.4-1
7

Je na to specialni package list, musi se zapnout v reforisu.

8

No ale jestli dobře rozumím syntaxi na Forwarding — Knot Resolver 6.0.8 documentation, tak to bude tímto neslučitelné s nastavováním z reforisu. Syntaxe konfigurace je úplně jiná. Nastavení openwrt si s tím nějakým zázračným způsobem dokáže poradit?

9

Tím myslím, pokud tím získám pouze ručně konfigurované nastavení, pro mě osobně by dávalo smysl dát si tam rovnou unbound. Ten alespoň umím nastavovat…

10

Nastavení z reForis co fungovalo s knot-resolver by mělo samo fungovat i s knot-resolver6,

11

Dobře, aktualizoval jsem. Hláška se změnila, nxdomain pro jméno turrisu zůstalo.

Počítá se správně s tím, že hostname nastavuji pouze relativní (menturris), k tomu doménu ko.home.arpa a očekávám, že menturris.ko.home.arpa si to složí samo?

Protože pro ostatní hosty to tímto funguje dobře. DHCP hosty z /tmp/dhcp.leases.dynamic to resolvuje včetně reverze. Hostname turrisu samotného to ovšem stále nezná. Sice na něj stejně chodívám přes menturris.local, ale bez toho mi už zbývá jenom adresa. Má být hostname v reforisu FQDN, nebo stačí jméno bez tečky? Interface nedoporučuje konkrétní podobu.

; <<>> DiG 9.18.24 <<>> P110.ko.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36053
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;P110.ko.home.arpa.		IN	A

;; ANSWER SECTION:
P110.ko.home.arpa.	300	IN	A	192.168.88.195

;; Query time: 10 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Sep 01 19:15:45 CEST 2024
;; MSG SIZE  rcvd: 62

; <<>> DiG 9.18.24 <<>> menturris.ko.home.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42165
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;menturris.ko.home.arpa.		IN	A

;; AUTHORITY SECTION:
home.arpa.		3600	IN	SOA	localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sun Sep 01 19:16:21 CEST 2024
;; MSG SIZE  rcvd: 110
12

Popravdě netuším, jakým mechanismem by se jméno samotného routeru mělo dostat do DNS.

Pro ostatní: *.local je mDNS (=Avahi), ne DNS. Tedy jiná služba, trochu jiný protokol, jiný port.

13

Statická jména je alespoň snadné přidat, třeba
https://wiki.turris.cz/en/public/dns_knot_misc#by_populating_the_hosts_file

14

Podle mě by pushovat změnu do DNS mohl přímo spouštěcí skript, který zařizuje přidávání DHCP jmen. Pokud chci přidat běžné hosty, pravděpodobně chci ochránit jméno gatewaye, aby ho DHCP klienti nemohli přebít. V podstatě nějaký hook ifup by mohl tyhle jména přidávat do DNS poté, co se nahodí interface a resolver. Alespoň v případě, že mám povolené přidávání DHCP hostů, budu asi chtít i přidat adresu gatewaye. Teda alespoň já si to tak určitě představuji.

Ale to už by bylo asi na jiné vlákno. Je místo na gitlabu, kam hlásit podobné requesty?

15

Tyhle skripty a balíky jsou v Turris / Turris OS / Turris OS packages · GitLab tak nejspíš issues tam. Dost podobných už tam i je.

16

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.