On Mon, Oct 4, 2021 at 5:15 PM Guillaume Quintard
<email@example.com> wrote: >
> On Mon, Oct 4, 2021 at 9:49 AM Dridi Boukelmoune <firstname.lastname@example.org> wrote:
>> One problem I have (and that you should be familiar with) is that
>> portable interfaces we have that *respect* the system configuration
>> (hosts file, nsswitch configuration etc) are not providing enough
>> information. For example it becomes cumbersome to resolve SRV records
>> or even get the TTL of individual records for a DNS resolution in a
>> *portable* fashion.
>> When you put it like this, it sounds simple enough (dare I say
>> simplistic?) but what I see is a sizeable can of worms.
> That sounds like a bit of a strawman to me. getaddrinfo and connect are standard, and that's about all we should need. Applications are supposed (in general) to just use whatever gai give them. We can call them every time we need a new connection so we don't worry about TTL, and we just disregard SRV records.
> The vast majority of users don't need SRV (yet?), and don't expect the application to optimize DNS calls, but they do complain that giving a hostname to VCL doesn't work.
The "portable" interface I was referring to includes getaddrinfo, and
I guess your suggestion would be to always resolve and leave A/AAAA
records caching to your stub and/or recursive resolver.
Fair enough, simplicity.
That still doesn't seal the can of worms: once there are more than one
address per family or addresses change, it's our connection and
pooling models that need to be revisited, how many different addresses
to try connecting to, how to retry, and how we account for all of that
(stats for example). Again, it's a bit more complex that just saying
"change the connect callback to one that combines resolve+connect".
I'm not against a holistic management of connections, there are
actually more aspects that I think should be at the core of our
connection management like certificates attached to a session (and in
particular their domains) once we have TLS support.
I just think it needs to be better defined and not give the impression
that messing about a new set of backend callbacks that will
systematically resolve endpoints is as simple as it gets.
varnish-misc mailing list