DnsResolver v4/v6 selection

[hennna]

In adding v6 support to DnsResolver (https://github.com/lyft/envoy/blob/master/source/common/network/dns_impl.cc#L123), what would be the best way to handle v4/v6 address selection.

1. Default to v4/v6
2. Configurable option

For (1) something like try v6. If failed, try v4
For (2) something like a json parameter or CLI option that gets plumbed through to DnsResolver

[hennna]

Proposal: We can introduce the boolean fallback_v6_ in DnsResolver. When true, return the v4 address if available and the v6 address if not. When false, return the v6 address if available, and the v4 address if not.

This should be set when the DnsResolver is created (https://github.com/lyft/envoy/blob/master/source/server/server.cc#L70)

However, should this be a CLI option or configurable via json?

[mattklein123]

@hennna I think definitely configurable on a per cluster basis. IMO I would probably just have an enum of different options, basically v4only, v6only, auto (default).

[hennna]

@mattklein123 Do you mean add an additional optional json field to every host? (https://github.com/lyft/envoy/blob/master/test/config/integration/server.json#L285)?

Also, should the default behavior be programmable or fixed? Prefer to try v4 or v6 first?

[mattklein123]

No, I would probably add it as something on each cluster, kind of like this: https://github.com/lyft/envoy/blob/master/source/common/json/config_schemas.cc#L1208

Maybe "dns_fetch_type" or something? Not sure of best name. Theoretically it's possible that it could be done on a per host basis, but I find it hard to believe that people would actually use that, and this fits into the config model better.

What do you mean programmable or fixed? I think if we have options for v4 only, v6 only, and auto, where maybe we prefer v4, I think that should be ok?

[hennna]

Yes, I was wondering whether splitting auto into prefer_v4 and prefer_v6 would be useful. Ok this sounds good. I'll starting working on this.

[mattklein123]

IMO I would just do one version of auto since it's simpler and if people ask for the other version it can be added later, but either way.

[dnoe]

I'd call it dns_lookup_type, seems to match typical DNS terminology better than "fetch"

[htuch]

Do we want to prefer IPv4 in auto or IPv6? It seems that https://tools.ietf.org/html/rfc3484 has "The default policy table gives IPv6 addresses higher precedence than
IPv4 addresses. This means that applications will use IPv6 in
preference to IPv4 when the two are equally suitable. ", but I think that's a pretty complex set of rules in the full RFC that we won't implement.

[htuch]

The reason I point to that RFC is it's how getaddrinfo is supposed to work, and that's what we're implementing here. Principle of least surprise would suggest we are consistent with it.

[htuch]

Actually, thinking about this further getaddrinfo returns a list of addresses. We probably should do this as well, and allow the consumer to fallback to IPv4 if connect() fails as suggest in the RFC.

[mattklein123]

I don't have a super strong opinion on this. I guess my vote would be:

• Prefer v6 over v4 in auto mode per RFC, but for now just return a single type of address.
• File a follow up issue to have a mode where we return multiple types of addresses, and actually allow the calling code to do fallback processes if connect() fails. This is super non-trivial so would rather not conflate in the initial effort.