https://github.com/haproxy/haproxy/issues/341
On Thu, Oct 24, 2019 at 11:44 AM Lukas Tribus <[email protected]> wrote: > Hello, > > On Thu, Oct 24, 2019 at 5:53 PM Jim Freeman <[email protected]> wrote: > > > > Yesterday we had an ELB scale to 26 IP addresses, at which time ALL of > the servers in that backend were suddenly marked down, e.g. : > > > > Server www26 is going DOWN for maintenance (unspecified DNS error) > > > > Ergo, ALL requests to that backend got 503s ==> complete outage > > > > Mayhap src/dns.c::dns_validate_dns_response() bravely running away when > DNS_RESP_TRUNCATED (skipping parsing of the partial list of servers, > abandoning TTL updates to perfectly good endpoints) is not the best course > of action ? > > > > Of course we'll hope (MTUs allowing) that we'll be able to paper this > over for awhile using an accepted_payload_size >default(512). > > I agree this is basically a ticking time-bomb for everyone not > thinking about the DNS payload size every single day. > > However we also need to make sure people will become aware of it when > they are hitting truncation size. This would have to be at least a > warning on critical syslog level. > > > Reliable DNS resolution for everyone without surprises will only > happen with TCP based DNS: > https://github.com/haproxy/haproxy/issues/185 > > For the issue in question on the other hand: can you file a bug on github? > > > > Thanks, > > Lukas >
