replace getaddrinfo_a() with c-ares about envoy HOT 14 CLOSED

@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.

from envoy.

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.

from envoy.

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

from envoy.

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).

from envoy.

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

from envoy.

@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?

from envoy.

@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.

from envoy.

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

from envoy.

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

from envoy.

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

from envoy.

@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.

from envoy.

fixed thanks @htuch !

from envoy.

not done yet

from envoy.

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

from envoy.