What about adding code that would count the bytes dynamically and make sure it keeps under the threshold? Maybe even make that the behavior for the current default of 0.
On Mon, Dec 4, 2017 at 2:06 PM Jason Tucker <[email protected]> wrote: > Yes, this is the UDP thing. We've had customers with clients that sit > behind DNS infrastructure that has problems with large response packets. > > However, the "max" is going to be installation dependent, though. Variables > such as edge hostname convention, and CDN DNS domain suffixes are going to > cause that threshold to vary from installation to installtion. If you have > short FQDNS, you can fit many of them in a single UDP response. > > __Jason > > On Mon, Dec 4, 2017 at 9:00 PM, Phil Sorber <[email protected]> wrote: > > > You say it causes issues with "large cache groups". What is "large" in > this > > context? Maybe we should pick a default that puts us slightly below that. > > Reading a little into your comment here, I assume the "problems" stems > from > > the number of answers that fit in a UDP packet. Maybe we should just make > > the default below that threshold so we get as close to the max without > > causing said problems? > > > > Thanks. > > > > On Mon, Dec 4, 2017 at 12:52 PM Volz, Dylan <[email protected]> > > wrote: > > > > > Hi All, > > > > > > The max_dns_answers has been defaulted to 0, which is an unlimited > number > > > of answers, which causes issues for deployments with large cache > groups. > > I > > > opened a PR (1611< > > > https://github.com/apache/incubator-trafficcontrol/pull/1611>) to > change > > > the default from 0 to 5 which is hopefully a sensible value for most > > > deployments. If this doesn’t seem like a sensible default please > respond > > > with alternatives. > > > > > > Thanks, > > > Dylan > > > > > >
