Unbound cache default reset time for 404 or upstream failovers
Hello, As I already stated before on my machine I'm using Unbound local cache mechanism with its pros and cons. One of the few cons that I mentioned to you lately was the prb, sometimes occurring of faulty sites configuration that entering in the Unbound cache lock me out during my subsequent retries fixed things as required.. Playing with a new website I now noticed that although I'm using the default values for Unbound cache ttl settings the cache after some hours of inactivity reset itself almost in the dns entries with problems (404 or upstream failovers).. I just wonder if this is the expected behavior and if yes if you can let me know the default reset time for this kind of "resets" ? Using OpenBSD 7.2 Thnks a lot, appreciated! -- Daniele Bonini
Re: Weird pf NAT failure on apu2
On 6/24/23 13:14, Stuart Henderson wrote: On 2023-06-24, Stephan Neuhaus wrote: I now think that either the documentation is wrong, or pf is wrong. At any rate, there seems to be a rather serious disconnect between the two. The FAQ clearly says: When a packet is selected by a match rule, parameters (e.g. nat-to) in that rule are remembered and are applied to the packet when a pass rule matching the packet is reached. Yes that's wrong. Address changes take effect at the time the match rule is processed when traversing the ruleset; rules processed later "see" the rewritten address. As pf.conf(5) says, Translation Translation options modify either the source or destination address and port of the packets associated with a stateful connection. pf(4) modifies the specified address and/or port in the packet and recalculates IP, TCP, and UDP checksums as necessary. If specified on a match rule, subsequent rules will see packets as they look after any addresses and ports have been translated. These rules will therefore have to filter based on the translated address and port number. OK, that's clear and unambiguous, thanks! So it's a bug in the FAQ, not in pf itself. Cheers Stephan
Re: error when pkg_add'ing
On Sat, Jun 24, 2023 at 06:44:11PM +0200, Pau A.S. wrote: > thanks so much, Marcus; pkg_check helped to identify a LOT of corrupted > files, which I deleted; after that I ran pkg_add -vu and it looks that one > file survived: Having A LOTS of problems in pkg_check usually means something in your process is REALLY BAD. As the guy who wrote (most of) pkg_add/pkg_check, I don't need pkg_check all that often. And it's mostly because of flakiness in the base system!!! if you end up fixing A LOT through pkg_check, it means that SOMETHING ELSE is usually wrong.
PF: (max-src-conn 1, max-src-conn-rate 1/1, overload )
Hello, I’m not part of this maillist, so rply me directly if necessery. (Sent this pf@ which seems do not exists any more) Following is given in pf.conf: ### int pass in on int from any to any keep state \ (max-src-conn 1, max-src-conn-rate 1/1, overload ) pass out on int from any to keep state \ (max-src-conn 1, max-src-conn-rate 1/1, overload ) This ever slows down traffic or gives none at all. Idea is to to track all IOT and connections. PF ever take to long to process this or even refuses(time out). Rest of rules are old enough to state that those are working. Above is new modd I’d like to introduce. Not working. Prev. rule: pass on int all keep state. ← working all good. Any one seen this before. Br //mxb -- Maxim -- Maxim
