A zase kresd :-(

Zdravim,
Jak (spolehlive) funguje policy.add(policy.suffix(policy.STUB()… v kresd verze 4.3.0?

O co jde. Mam rozbehnuty RBL na IP adrese 192.168.100.11:

dig @192.168.100.11 A 1.2.2.1.dnsbl.doma
root@percival:/etc/init.d# dig @192.168.100.11 A 1.2.2.1.dnsbl.doma

; <<>> DiG 9.12.4-P2 <<>> @192.168.100.11 A 1.2.2.1.dnsbl.doma
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46644
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;1.2.2.1.dnsbl.doma.		IN	A

;; ANSWER SECTION:
1.2.2.1.dnsbl.doma.	2100	IN	A	127.0.0.2

;; AUTHORITY SECTION:
dnsbl.doma.		3000	IN	NS	dnsbl.doma.

;; Query time: 0 msec
;; SERVER: 192.168.100.11#53(192.168.100.11)
;; WHEN: Wed Feb 26 12:07:52 CET 2020
;; MSG SIZE  rcvd: 66

Konfigurace kresd je nasledujici:

/tmp/kresd.config
--Automatically generated file; DO NOT EDIT
modules = {
    'hints > iterate'
  , 'policy'
  , 'stats'
  , predict = {
        window = 30 -- 30 minutes sampling window
      , period = 24*(60/30) -- track last 24 hours
  }
}
hints.use_nodata(true)
hints.config('/tmp/kresd/hints.tmp')
trust_anchors.add_file('/etc/root.keys')
net.bufsize(16384)
net.ipv4=true
net.ipv6=true
cache.open(20*MB)
cache.clear()

--- Included custom configuration file from: ---
--- /etc/kresd/custom.conf 
-- Lokalni upravy

policy.add(policy.suffix(policy.STUB('192.168.100.11'), {todname('dnsbl.doma.')}))
-- Konec

A kdyz nastartuju kresd(na Omnii[192.168.100.1]), tak v zasade vse funguje az na dotaz pro “…dnsbl.doma”:

dig @192.168.100.1 A 1.2.2.1.dnsbl.doma
root@percival:/etc/init.d# dig @192.168.100.1 A 1.2.2.1.dnsbl.doma

; <<>> DiG 9.12.4-P2 <<>> @192.168.100.1 A 1.2.2.1.dnsbl.doma
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50854
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 16384
;; QUESTION SECTION:
;1.2.2.1.dnsbl.doma.		IN	A

;; AUTHORITY SECTION:
.			86394	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2020022601 1800 900 604800 86400

;; Query time: 1 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Wed Feb 26 12:14:18 CET 2020
;; MSG SIZE  rcvd: 122

Debug kresd obsahuje toto:

kresd verbose
2020-02-26 12:14:18 info kresd[17102]: > [00000.00][plan] plan '1.2.2.1.dnsbl.doma.' type 'A' uid [50854.00]
2020-02-26 12:14:18 info kresd[17102]: [50854.00][iter]   '1.2.2.1.dnsbl.doma.' type 'A' new uid was assigned .01, parent uid .00
2020-02-26 12:14:18 info kresd[17102]: [50854.01][cach]   => trying zone: ., NSEC, hash 0
2020-02-26 12:14:18 info kresd[17102]: [50854.01][cach]   => NSEC sname: covered by: dog. -> domains., new TTL 86394
2020-02-26 12:14:18 info kresd[17102]: [50854.01][cach]   => NSEC wildcard: covered by: . -> aaa., new TTL 86394
2020-02-26 12:14:18 info kresd[17102]: [50854.01][cach]   => writing RRsets: +++
2020-02-26 12:14:18 info kresd[17102]: [50854.01][resl]   AD: request NOT classified as SECURE
2020-02-26 12:14:18 info kresd[17102]: [50854.01][resl]   finished: 0, queries: 1, mempool: 114744 B

Nejak se nemuzu zbavit dojmu na na to “STUB” pravidlo uplne kasle.

Ale kdyz si ted u kresd vynutim vyplach cache (echo “cache.clear()” | socat - /tmp/kresd/tty/*) a pak se zeptam:

dig @192.168.100.1 A 1.2.2.1.dnsbl.doma po vyplachu cache
root@percival:/etc/init.d# dig @192.168.100.1 A 1.2.2.1.dnsbl.doma

; <<>> DiG 9.12.4-P2 <<>> @192.168.100.1 A 1.2.2.1.dnsbl.doma
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62192
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 16384
;; QUESTION SECTION:
;1.2.2.1.dnsbl.doma.		IN	A

;; ANSWER SECTION:
1.2.2.1.dnsbl.doma.	2100	IN	A	127.0.0.2

;; Query time: 1 msec
;; SERVER: 192.168.100.1#53(192.168.100.1)
;; WHEN: Wed Feb 26 12:18:15 CET 2020
;; MSG SIZE  rcvd: 63

a debug log ted obsahuje:

kresd verbose po vyplachu cache
2020-02-26 12:18:14 info kresd[17102]: cache.clear()
2020-02-26 12:18:14 info kresd[17102]: [count] => 706
2020-02-26 12:18:14 info kresd[17102]: 
2020-02-26 12:18:15 info kresd[17102]: > [00000.00][plan] plan '1.2.2.1.dnsbl.doma.' type 'A' uid [62192.00]
2020-02-26 12:18:15 info kresd[17102]: [62192.00][iter]   '1.2.2.1.dnsbl.doma.' type 'A' new uid was assigned .01, parent uid .00
2020-02-26 12:18:15 info kresd[17102]: [     ][nsre] score 21 for 192.168.100.11#00053;	 cached RTT: -1
2020-02-26 12:18:15 info kresd[17102]: [62192.01][resl]   => id: '05272' querying: '192.168.100.11#00053' score: 21 zone cut: '.' qname: '1.2.2.1.DNSbL.doma.' qtype: 'A' proto: 'udp'
2020-02-26 12:18:15 info kresd[17102]: [62192.01][cach]   => stashed 1.2.2.1.dnsbl.doma. A, rank 021, 20 B total, incl. 0 RRSIGs
2020-02-26 12:18:15 info kresd[17102]: [62192.01][cach]   => stashed dnsbl.doma. NS, rank 001, 28 B total, incl. 0 RRSIGs
2020-02-26 12:18:15 info kresd[17102]: [62192.01][resl]   <= server: '192.168.100.11' rtt: 1 ms
2020-02-26 12:18:15 info kresd[17102]: [62192.01][resl]   AD: request NOT classified as SECURE
2020-02-26 12:18:15 info kresd[17102]: [62192.01][resl]   finished: 0, queries: 1, mempool: 65568 B

No a toto se pravidelne opakuje kazdym restartem kresd (anebo kdyz to zapomene).

Delam neco spatne ja nebo kresd?

Chápu že to zní překvapivě, ale je to zdokumentovaná vlastnost. I policy.STUB defaultně používá cache a ta je sdílená pro všechny dotazy, takže pokud se do cache dostane záznam dokazující neexistenci .doma top-level domény, tak ho použije pro vygenerování odpovědi aniž by se znovu ptal upstream serverů. (V tomto případě jde o NSEC dog. -> domains.)

Předpokládám, že chcete pro ty dnsbl.doma dotazy navíc vypnout čtení z cache, jak je uvedeno na příkladu v příslušné části dokumentace: https://knot-resolver.readthedocs.io/en/v4.3.0/modules.html#replacing-part-of-the-dns-tree

Tohle mi muselo nejak uniknout (popravde ona ta dokumentace je taky zazitek, do ted jsem v ni nenasel zpusob jak pozadat kresd o dump configu co prave pouziva. Jako ne ten soubor, ale to podle ceho zrovna jede).
Kazdopadne dekuju za nakopnuti.
Ano specielne u tohohle pravidla se hodi i nekesovani.

Ale neda mi to. Z myho pohledu je zrovna u takovyhleho pravidla zadouci aby ignoroval strom, stejne jako to dela u lokalnich jmen (nadloubanych pomoci “hints.*”).
Takhle mam jeste jedno STUB pravidlo, ktery evidentne funguje jen zazrakem a to proto, ze tataz domena existuje i venku.
Proste by clovek ocekaval ze kdyz udelam takovyhle pravidlo, tak bude kesovat a bude ignorovat korenovy strom (jednou mam receny ze domena “fnfnbzbzblbl” je tady na tomhle konkretnim DNS serveru a korenovejm DNSkum je putna ze venku neni).
Ta definice by z principu mela prebijet to co tvrdi nekdo jinej (nekde jinde).

S kresd mam proste boj od zacatku. Uz od zacatku, od zjisteni ze v Omnii bude namisto unboundu tlacenej kresd (a pokud si tam clovek vnuti unbound, tak zase bojuje/bojoval proti updateru - nebo souvisejicim scriptum ktery neocekavaly nic jineho nez kresd), tak az do dneska na to mam reakci “Jeezis :-(” namisto “Jaj :-)”. Jako nerikam ze je naprd, ale nektery veci bejvaj fakt “jdi na mne z boku” :-(.

Taková věc je mimo koncept kresd. Konfigurace je lua skript který může udělat cokoliv – jakkoliv změnit stav služby a jak sám používáte, jde přidávat dynamicky (libovolné) příkazy. EDIT: no, vidím že by tedy šlo odděleně někam ukládat takto vznikající seznam vstupních konfiguračních řetězců, ale nevím…

Tenhle imperativní design je taky to co dle mého názoru v důsledku vede k těm nepochopením… také ty příkazy byly od začátku navrženy spíše okolo toho jak funguje resolving (v kresd) než okolo nějaké intuice většiny uživatelů. Jako stavební bloky pro lidi co kresd rozumí to je asi lepší, díky tomu mohou být ty příkazy mnohem jednodušší, ale pro psaní konfigurace běžnými lidmi se to prostě neosvědčilo.

No a tyhle akce jako STUB, FORWARD a FORWARD_TLS jsou konkrétní takový případ. Mění na jaké servery dotazy jdou. Ale ani nemají jak poznat jestli je to akce “posílej všechny dotazy CloudFlare” (pak jistě cachování chcete) anebo něco jako tento případ kdy “zřejmě” cachovat nechcete. To je prostě oddělené… a podmínky jsou dělané flexibilně přes nezávislé sady funkcí (velmi často policy.suffix).

Ano, potud dobry. policy.suffix() ale neresi nic z toho co tu resim (krome toho ze to orizne na tu domenu, tak nejak logicky podle toho “suffix”). To zajimavy je to co bude v tom prvnim parametru, v “action”.
Treba osobne kulham v definicich. Kdyz vidim

  • STUB(ip) - similar to FORWARD(ip) but without attempting DNSSEC validation. Each request may be either answered from cache or simply sent to one of the IPs with proxying back the answer.

A pak se dozvim, ze mi to zazdil “NSEC” z korenovych serveru? Soucast DNSSECu, ktera u je vyslovne uvedena u STUBu ze ji bude ignorovat?
Existuje vubec cesta jak se v kresd dopracovat ke kesujicimu STUBu ktereho nevyvede z miry ze dotycna domena neni k nalezeni pres korenove servery?

Nebo takovy:

FLAGS(set, clear) - set and/or clear some flags for the query. There can be multiple flags to set/clear. You can just pass a single flag name (string) or a set of names.

Tot vse. Jaky flagy existuji, tezko rict, vyhledavani v dokumentaci nijak nepomaha. Pouze v jednom prikladu se clovek dozvi ze jeden z flagu je “NO_CACHE” (jediny vyskyt v cele dokumentaci, kdyz vynecham sekci " [c:function]: resolve", kde je to, jen tak mimodek, taky pouze v prikladu).

Kdyz nepomaha ani logika, ani dokumentace, tak co pak s tim?

EDIT: Aha, ono predevsim nefunguje vyhledavani v dokumentaci :-/. A na nektery veci se musi do oddeleni vyvojaru libknot(?).

No pro dotazy se STUB akcí skutečně k validaci DNSSEC nedojde. Ale jiné dotazy do cache uložily zvalidované NSEC záznamy. A v tuto chvíli nejde jednotlivé featury cache přímo zapínat a vypínat – pokud má zvalidované NSEC* záznamy, bude se je pokoušet používat při odpovídání. No, popis té vnitřní logiky jistě nebude zajímavý… důležité je to, že pro většinu lidí ta kombinace není přirozená. Mám pocit, že by si stejně lidi spíš představovali že na nějaké sady pravidel by měli oddělené cache.

V uživatelské dokumentaci jsou jen nejčastěji užitečné možnosti. Ta pravidla (a celý lua kód) má přístup k většině vnitřního stavu resolveru, takže neexistuje ostrá hranice mezi uživatelskou a vývojářskou dokumentací. To je další aspekt “neintuitivního designu” současného přístupu ke konfiguraci.

Jinak plány jsou velké, navrhnout “od nuly” konfigurační přístup pro tyhle věci, vzatý z opačného směru, tedy tak aby byl co nejvíce intuitivní. Ale to bude trvat a samozřejmě to bude mnohem méně flexibilní (umět méně věcí). Číst myšlenky to také pořád nebude, ale snad se to podaří udělat tak, aby to pro co nejvíce typických použití bylo přirozené.

Tady nevím co tím myslíte. Nevidím problém ve vyhledávání v dokumentaci.

A to je IMHO chyba. De facto priotravena cache. Paradoxne dotazama ktery nemaji opustit barak (ale protoze to v kresd nejde pry jinak, tak musi byt domaci nazvy pres hints. Trochu pech kdyz se nekdo zepta v domaci siti na neexistujici jmeno).

Zatim mam dojem ze zrovna takovy unbound tuto definici, v porovnani s kresd, popira. Vlastne i dnsmasq.
Tedy pokud to u kresd nema zajit az na uroven “Napiste si resolver sami”.

Myslim tim to, ze kdyz hledam “NO_CACHE” ve snaze se dopatrat k definic, a predevsim zbytku moznych flagu, tak vyhledavani najde jen:


Vic ani tuk.
Napr. pri hledani “ALWAYS_CUT” nenajde pro jistotu vubec nic.
Pokud se v dokumentaci slovo vyskytuje a vyhledavani jej nenajde, jak to mam nazvat jinak nez ze vyhledavani nefunguje?

Hmm, vidím, že to vyhledávání není nic moc a kolegové potvrzují dlouhodobě horší hledací zkušenosti, obecně se Sphinx generátorem. Tohle zrovna bude myslím (pro nás) obtížné výrazně zlepšit.

Seznam všech těchto flagů v dokumentaci je (vygenerován z komentářů v kódu), ale obecně bych nedoporučil uživatelům se řídit podle věcí které nejsou zdokumentované “v běžném textu”.