OPNsense NAT Reflection (kérdések)?

Bevallom, sohasem jutott (és eztán sem fog szerintem) eszembe jutni, hogy a DNS rekordok TTL-jével variáljak. Így sohasem foglalkoztam azzal, hogyan lehetne.

Minden DNS bejegyzésnek (remélhetőleg jó okkal) annyi a TTL-je, amennyi. Nem is értem, miért kellene ezt változtatni, pláne növelni. Nyilván a zóna üzemeltető tudja, milyen gyakran változhat az RR, ehhez van TTL választva. Miért tudnám én jobban, hogy elég azt ritkábban frissíteni... Mi értelme a gyorstárnak akkor, ha készakarva érvénytelen tartalom van benne? Mert ugye nem tudhatom, hogy a zóna üzemeltetője váltzotatott-e az adaton, így akár érvénytelen is lehet az én cache-embe lévő megnövelt TTL-es RR, ami akár működési gondot is okozhat annál, aki erre támaszkodik.
Ha egy rekordot lekérdezel, akkor bekerül a helyi resolver cache-be, és ez a helyi resolver onnantól a TTL figyelembe vételével frissen tartja az értéket (a cache törléséig - pl. szolgáltatás restart) az internetről az authoratív szerverről (vagy ha forwarder-e van saját cache-sel, akkor onnan). Szóval a helyi resolver kliensei az adott bejegyzésre a választ mindig is a helyi gyorstárból kapják TTL-től függetlenül, a kérés az első lekérés után "sohasem" jut ki a publikus netre újból - tehát a gyorstár ellátja a feladatát. Egy filerendszer gyorstár is így működik, ha változás van a fájlrendszeren, akkor a cache is frissül, nem az adat előző verzióját adja random ideig... Ráadásul az automatikus frissítés miatt mindig érvényes választ kapnak a kliensek (akik helyben gyorstárazzák a választ, így a TTL alatt még csak a helyi resolvert sem kérdezik meg újra általában...). A frissítés egyébként nem TTL időnként, hanem annál sűrűbben történik, DNS resolver/kliens default vagy egyéáni beállítás függvényében.
Emiatt nincs olyan, hogy a cache értelmetlen, mert kicsi a TTL. Ha kicsi a TTL, akkor számítani lehet arra, hogy gyakran váltzik a rekord, nem értemes tovább érvényesnek tekinteni. A resolver szépen frissítgeti a TTL alapjána sajáét gyorstárát, a kliens meg midnig jó választ kap plusz internet forgalom genrálása nélkül. Ha ritkán változik, akkor hosszabb is szokott a TTL lenni (ez ugye nem zónánként, hanem RR-enként állítható...). A cache itt azt szolgálja, hogy a már egyszer keresett rekordok helyből megválaszolhatóak legyenek (és azok is). A DNS cache azért van, hogy az egyes DNS kérések ne fussanak végig a teljes érintett DNS struktúrán minden egyes alkalommal amikor valakit értedel a tartalma...

Az OPNsense doksija lehetne alaposabb valóban, de sokszor látom azt, hogy olyan hiányokat rónak fel sokan, ami hekkelés kategória, nem normál funkcionalitás/működés köre. Az OPNsense (ahogyan a pfSense meg a DDWRT, TrueNAS, OpenMediaVault, Proxmox VE és társaik) szerintem inkább appliance-ok, nem egy alap, szabadon piszkálható OS, rátelepítve némi GUI-val. Emiatt, amit nem tud a GUI-n, azt úgy kell tekinteni, hogy nem tudja... Lehet az issue tracker-ben feature-t kérni, amit ha kellően sokak éreznek hasznosnak, akkor megvalósul. Vagy meg lehet írni saját kezűleg, és egy PR keretében be lehet adni a közösbe.
Ilyen közösségi igényre való reakció volt pl. az, hogy az ACME plugin automatizációjába bekerült a frissített cert-ek másik gépre másolásának, és másik gép szolgáltatásának újraindítási lehetősége (mert sokan csinálják azt, hogy az OPNsense kezeli az LE certeket és teríti a belső hálózaton az érintett gépekre, amik valamiért nem tehetők HAproxy mögé). Szóval ha van olyan igényed, ami úgy tűnik többeknél felmerült de jelenleg nem megoldható a GUI-n keresztül, akkor ennél a projektnél van esélye a megvalósulásnak (sok szerencsét ugyan erre a pfSense esetében...).

A pfSense annyival jár előrébb doksi terén (látszólag), hogy nagyobb a követői bázisa, és nagyságrendekkel több "megoldás" kerül fel a netre a felmerülő problémákkal kapcsolatban. Namost tapasztalatom szerint ennek jó része vagy kapásból hibás (egy rossz megoldást szajkóz sok ember kipróbálás nélkül különböző felületeken), vagy csak bizonyos verzióra működő hekkelés. Összességében 6 év pfSense majd 8 év OPNsense használat után nem jelenteném ki kategorikusan, hogy utóbbi doksija érezhetően rosszabb/hányosabb lenne az előzőénél. (Ez egymáshoz viszonyítás, abszolut értékben azért hiányosak mindketten, vagy benne van csak nem elég érthetően/részletesen leírva.)

Én még eddig mindenre kaptam választ a doksiból, ami pedig ott nem volt elég részletes számomra (több plugin esetében van ilyen pl.), azt az eredeti szoftver doksija és az OPNsense felületen kint lévő opciók alapán meg tudtam oldani.

A konfig állományok kézi átirkálása valami cél érdekében egyik ilyen middleware által menedzselt rendszernél sem szokott jóra vezetni, nem csak az OPNsense esetén.

De, hogy a kérdésedre érdemi választ/megoldási lehetőséget mondjak, az OPNsense System/Settings/General lapon be lehet állítani, hogy "Do not use the local DNS service as a nameserver for this system", és akkor maga az OPNsense (és így a DDClient plugin) nem a helyi Unbound-ot használja DNS feloldásra, hanem a (ugyanezen lapon) beállított, vagy az ISP-től kapott névszervereket. Így el tudod érni azt az állapotot, hogy a klineseid az Unbound-tól a megtrükközött extra TTL-lel kezelt válaszokat kapják, ellenben maga az OPNsense hiteles DNS válaszokkal dolgozzon, a valódi TTL-ek alapján történő frissítésekkel.