Hello Willy, On Fri, 6 Nov 2020 at 10:59, Willy Tarreau <w...@1wt.eu> wrote: > > > hate the noise that some people regularly make about "UDP support" > > > > I am *way* more concerned about what to tell people when they report > > redundant production systems meltdowns because of the traps that we > > knew about for a long time and never improved. Like when the DNS > > response size surpasses accepted_payload_size and we don't have a TCP > > fallback, > > This one should be addressed once TCP support is implemented. But here > again, I'm not interested in implementing fallbacks. We're not supposed > to be dealing with unknown public servers when it comes to discovery > (which is the case where large responses are expected), so I'd rather > have resolvers configured for a simple resolving use case (e.g. server > address change, UDP) or discovery (TCP only).
All DNS servers are supposed to support TCP, in my opinion using *only* a TCP DNS client would be fine (I'm not sure about using different code paths regarding address change and discovery). A part from the code changes though, this would be a big change that the user needs to know about. I'm not sure if a big item in the release notes is enough. I'm always concerned about changes that are not immediately obvious (because they don't cause configuration warnings or errors). > > or we don't force the users to specify the address-family > > for resolution, which is of course very wrong on a load-balancer. > > Are you suggesting that we should use IPv4 only unless IPv6 is set, and > that under no circumstance we switch from one to the other ? I remember > that this was a difficult choice initially because we were trying to deal > with servers migrating to another region and being available using a > different protocol (I'm not personally fan of mixing address families > for a same server in a load balancer, but I'm pretty certain we clearly > identified this need). But again while it's understandable for certain > (older?) cases, it's very likely that it makes absolutely no sense for > discovery. I'm suggesting: zero assumptions. Currently we have "resolve-prefer" to set a *prefered* address-family. I suggest keeping this keyword as is. However I also suggest that we introduce a keyword to restrict the resolver to a specific address-family. "resolve-family" [ipv4|ipv6] to only send either A or AAAA queries. But more importantly I suggest: reject a configuration that has neither "resolve-prefer", nor "resolve-family" (if implemented). This is a hard breaking change that can easily be fixed by adjusting the configuration. It could also be just a config warning for one major release and only become an error in the subsequent release (although I don't think that is needed, since the fix for the user is so easy). I'm confident that the only way to get out of this address-family mess is by stopping the assumptions altogether and forcing the user to make the decision. A load-balancer is not a browser, we must not do happy eyeballs and the current default behavior is pretty close to "undefined" (first valid response is accepted, on errors switching from one AF to another). Regards, Lukas
