Hi Tim, On Wed, Mar 30, 2022 at 09:14:42PM +0200, Tim Düsterhus wrote: > Willy, > > On 3/26/22 10:22, Willy Tarreau wrote: > > be the last LTS version with this. I'm interested in opinions and feedback > > about this. And the next question will obviously be "how could we detect > > Can you clarify what *exactly* is expected to be removed and what will > remain? Is it just SRV DNS records or more?
What I believe is causing significant trouble at the moment in the DNS area is the assignment of randomly delivered IP addresses to a fleat of servers. Whether it's from SRV or just from a wide range of addresses returned for a single request, it's basically the same. For example if you configure 10 servers with the same name "foo.example.com", the DNS will have to check in each response if there are addresses already assigned to active servers, and just refresh them, then find if there are addresses that are not assigned and see if some addressless servers are available, in which case these addresses will be assigned to them, then spot any address that has disappeared for a while, and decide whether or not the servers that were assigned such addresses finally ought to be stopped. In addition to being totally unreliable, it's extremely CPU intensive. We've seen plenty of situations where the watchdog was triggered due to this, and in my opinion the concept is fundamentally flawed since responses are often partial. As soon as you suspect that all active addresses were not delivered, you know that you have to put lots of hacks in place. What I would like to see is a resolver that does just that: resolving. If multiple addresses are returned for a name, as long as one of them is already assigned that's OK otherwise the server's address changes. If you have multiple servers with the same name, it should be written clearly that it's not the resolver's role to try to distribute multiple responses fairly. Instead I'd rather see addresses assigned like they would at boot when using the libc's resolver, i.e. any address to any server, possibly the same address. This would definitely clarify that the resolver is there to respond to the question "give me the first [ipv4/ipv6/any] address corresponding to this name" and not be involved in backend-wide hacks. This would also make sure that do-resolve() does simple and reliable things. Also I would like to see the resolvers really resolve CNAMEs, because that's what application level code (e.g. Lua or HTTP client) really needs. If I understand right, at the moment CNAMEs are only resolved if they appear in the same response, thus I strongly doubt they can work cross-domain. It's important to keep in mind that the reasons such mechanisms were put in place originally was in order to adopt new emerging trends around Consul and similar registries. Nowadays all these ones have evolved to support way more reliable and richer APIs due to such previous limitations, and the DNS as we support it should really really really not be used. I hope this clarifies the situation and doesn't start to make anyone worry :-) Anyway there's no emergency, the code is still there, and my concern is more about how we can encourage such existing users to start to think about revisiting their approach with new tools and practices. And this will also require that we have working alternatives to suggest. While I'm pretty confident that the dataplane-api, ingress controller and such things already offer a valid response, I don't know for sure if they can be considered as drop-in replacement nor if they support everything, and this will have to be studied as well before starting to scare users! Cheers, Willy
