Greetings,
On Mon, 17 Jun 2024 19:08:22 +0100,
J Carter wrote:
>
> It's caused by DNS Cache poisoning (either intentionally, or
> unintentionally), from a recursive resolver that caches CD bit but
> does not zero it if a non dns-sec query hits that cached response.
>
> I see unbound also has
On Mon, 17 Jun 2024 00:21:27 +0100,
J Carter wrote:
>
> Well *I* quite agree.
>
> I would also suggest that as DNS functionality in nginx is strictly
> limited to resolving as client in quite a simplistic fashion, and nginx
> does not support DNSSEC, it makes little sense to hyper-strict about
>
On Sun, 16 Jun 2024 02:45:15 +0100,
J Carter wrote:
>
> Sounds familiar :)
>
> https://mailman.nginx.org/pipermail/nginx-devel/2022-May/YQ3MYP4VNQYWEJS3XYLPMU4HZUKS4PYF.html
Unfortunately, the AD bit is set by the libunbound-based resolver when it is
configured to use an upstream forwarder
Greetings,
Here a trivial patch which allows DNS responses with enabled AD bit
from used resolver.
Index: src/core/ngx_resolver.c
--- src/core/ngx_resolver.c.orig
+++ src/core/ngx_resolver.c
@@ -1774,7 +1774,7 @@ ngx_resolver_process_response(ngx_resolver_t *r, u_cha
On Mon, 10 Jun 2024 09:56:05 +0100,
Martin Kjær Jørgensen via nginx wrote:
>
>
> Is this possible without hacking nginx sources or manipulative intermediate
> proxies?
>
As you may see in ngx_http_header_filter_module.c such string is hardcoded.
--
wbr, Kirill
Greetings,
Here is a patch that exposes the constructed cache key as
$upstream_cache_key variable.
Sometimes it's quite useful when debugging complicated setups and fighting
some typos.
I've attached two patches:
1. from me to add that variable
2. from Maxim Dounin to update docs
--
wbr,
On Thu, 09 May 2024 18:11:18 +0100,
Christos Chatzaras wrote:
>
> if ($http_cookie ~* "_mcnc|PHPSESSID") {
> set $no_cache "1";
> }
>
Try to use map instead if.
--
wbr, Kirill
___
nginx mailing list
On Fri, 19 Apr 2024 10:02:00 +0200,
Sébastien Rebecchi wrote:
>
> As I understand we better replace all proxy_pass to pass when upstream
> server is localhost, but pass does not work with remote upstreams.
> Is that right?
>
It depends on your use case I guess.
Frankly speaking I don't see any
On Fri, 19 Apr 2024 03:14:44 +0200,
Fabiano Furtado Pessoa Coelho wrote:
>
> Please, can you spot these overheads in proxying?
>
Establishing and accepting a brand new connection, writing and reading of
requests. Maybe buffering. A lot of useless context switching between
user and kernel
Greetings,
Let assume that I would like behavior on LB from the backend and force it to
cache only resposnes that have a X-No-Cache header with value NO.
Nginx should cache a response with any code, if it has such headers.
This works well until the backend is unavailable and nginx returns a
10 matches
Mail list logo
