On Tue, Oct 29, 2019 at 8:18 PM David Birdsong <[email protected]> wrote:
> I should have put the haproxy version in the mail too: > > haproxy 2.0.8 > > On Tue, Oct 29, 2019 at 3:07 PM David Birdsong <[email protected]> > wrote: > >> I've narrowed down a behavior that I think might be a bug, but is >> definitely not ideal. >> >> This minimal configuration copies header: X-Host into Host and performs a >> dynamic DNS query against that field name, stores the output in a txn var, >> and then uses a backend whic sets the dest ip to that txn var. >> >> For any requests with an X-Host header that matches a name already >> tracked by DNS in a backend, I see that haproxy spends 4-9 seconds reading >> the request from the client while any X-Host values which are not currently >> tracked by a backend show haproxy spending 1ms reading in the request from >> the client (normal.) >> >> unnamed, fast: curl -v -H "X-Host: google.com" http://127.0.0.1:8080/foo >> >> named, very slow: curl -v -H "X-Host: mixpanel.com" >> http://127.0.0.1:8080/foo >> >> Config: >> https://gist.github.com/davidbirdsong/1c3ec695fdbab10f64783437ffab901c >> haproxy -vv >> https://gist.github.com/davidbirdsong/d4c1c71e715d8461ad73a4891caca6f1 >> >> cat /etc/lsb-release >> DISTRIB_ID=Ubuntu >> DISTRIB_RELEASE=16.04 >> DISTRIB_CODENAME=xenial >> DISTRIB_DESCRIPTION="Ubuntu 16.04.6 LTS" >> >> >> david@david-VirtualBox:~/tls_demo/CA$ uname -a >> Linux david-VirtualBox 4.15.0-65-generic #74~16.04.1-Ubuntu SMP Wed Sep >> 18 09:51:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux >> >> Hi David, I confirm I can reproduce the issue and from my first quick look, it is related to DNS code in HAProxy. Basically, there is a cache of the valid responses and from what I observed, your do-resolve session is registered to the resolution and instead of pulling info from the cache, it's waiting until the next request is sent and gets updated with the next response. Let me fix this. Baptiste
