replace getaddrinfo_a() with c-ares

[PiotrSikora]

getaddrinfo_a() is not portable (it exists only in glibc) and Envoy already uses libevent's features quite heavily.

I'd be fine with a build-time alternative, if you prefer to use getaddrinfo_a() on Linux.

[mattklein123]

Yeah, and the API interface for getaddrinfo_a() is also terrible.

In my mind this is related to #125. AFAIK evdns is not considered production grade and it doesn't have SRV support. I think it would be better to start depending on a resolver library such as https://c-ares.haxx.se/ (though I haven't done that much research) and then we can get rid of getaddrinfo_a() and get SRV resolver support at the same time.

[PiotrSikora]

C-ares might be indeed a better choice, I just didn't want to suggest yet another dependency.

[mattklein123]

I've had multiple people ask for SRV support at this point, so I think we will do this relatively soon (potentially via non-Lyft contribution).

[vanillahsu]

getaddrinfo_a() is linux only api, it's terrible when I like to port envoy to FreeBSD.

[PiotrSikora]

@mattklein123 you mentioned that this might be contributed from outside of Lyft. Do you know status of this effort? Is anyone actively working on this?

[mattklein123]

@PiotrSikora no one is currently working on this. If you want to take this, that would be great. It's all yours. Let me know.

[PiotrSikora]

@mattklein123 please consider this being worked on (not by me, but someone else at Google).

[mattklein123]

OK great, thanks. LMK if there are any questions/issues. The interface that needs to be implemented is pretty straightforward.

[htuch]

@mattklein123 I'll be working on this as a Google contributor, will reach out if any questions arise.

[htuch]

@mattklein123 Any objections to changing the DnsResolver::resolve() return type to ActiveDnsQuery* from ActiveDnsQuery&? If a DNS query is resolved immediately during the call to ares_gethostbyname(), and hence the callback has already been invoked, we don't have any cancellation to return to the caller.

Also, I'm thinking in the initial implementation we can keep it relatively simple and use a single ares_channel per query. This comes at some tail latency cost, as you can't share DNS server TCP connections or have the ability to persist them, but it makes it somewhat easier to marry the select-oriented event model in c-ares with libevent.

[mattklein123]

@htuch re: return value sgtm

re: ares implementation, tbh I don't know anything about the c_ares API, I did enough research to determine that seemed like the library to use but that's about it, so what you are proposing sounds fine to me.

[mattklein123]

fixed thanks @htuch !

[mattklein123]

not done yet

[mattklein123]

Change deployed to canary at Lyft and looks good so far so closing this out.