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 <sor...@apache.org> 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 <dylan_v...@comcast.com> > 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 > > >
