Hi Lukas, On Tue, Nov 10, 2020 at 11:55:33PM +0100, Lukas Tribus wrote: > 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,
Note, there is a huge difference between supporting and being accessible. I've seen plenty of DNS servers behind a firewall making sure that TCP was *not* exposed, just due to the very long history of remote exploits on a number of them :-/ And given that regular resolvers always use UDP by default, such setups work perfectly well like that and are not easily spotted. However I agree that it's unlikely that anyone will rely on a partially accessible DNS server for production purposes (i.e. outside of a lab where tests are conducted). > 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). I agree on both points (using only TCP and need to make it visible). Maybe that going through the usual two-steps process would be enough, i.e. first have a "tcp" option in resolvers and warn when not used, second make it the default and drop the old one. Only those skipping two versions at once would miss it. Other suggestions are welcome of course. > 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. I like this, this is more in line with the philosophy of the rest of the options in other areas. > 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). This sounds like quite a sane approach. > 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). I totally agree. And the automatic address family switch alone has been a big trouble to deal with. I remember that there are some special cases regarding the compatibility between the server's address and the "source" address family for example. Given that you can specify only one source, you can face stupid situations where one family works and not the other, and that's typically a situation where you don't want that to randomly change. And on a more personal note, I'd say that I don't feel comfortable with a DNS server under someone else's authority telling my machine what address family it's supposed to use to reach any other machine given that this server knows nothing about my machine's ability to use that address family. And just for this, having this "resolve-family" would make me more comfortable. Emeric and I will have a discussion tomorrow around these subjects, all your points above are extremely useful and will certainly help fuel the discussion! Thanks! Willy
