[dns] what should go into DNS when a container has multiple weave IPs?

[rade]

Currently, when a container has multiple weave IPs - e.g. we've run weave attach on it several times, we tell DNS about each of the IPs and DNS returns one of them (we leave it unspecified which one, and whether that answer changes over time). Is that sensible?

What other options are there?

• return all addresses
• return all addresses in random order
• return one of the addresses, picked randomly

Anything else?

I suspect ultimately this will become a moot point due to issue #218.

[bboreham]

As noted in #218, one of the reasons you might have two IP addresses is to talk to clients on two subnets that are isolated from each other. So, if one of these clients requests your IP address via DNS, the answer they get should be one that is reachable from their weave IP address. The API for weavedns was designed with this in mind, though the feature is not implemented.

[rade]

Containers talk to weaveDNS via the docker bridge, so the request will always come from a container's docker network IP. weaveDNS could correlate that to a container ID, find out its weave subnets, and filter results based on that.

This is a rather unusual thing to do for a DNS server though, i.e. return different results based on who is asking.

The more standard solution is to ensure that the topologies for naming and networking are aligned. e.g. use one sub-domain per sub-net.

[inercia]

This is a rather unusual thing to do for a DNS server though, i.e. return different results based on who is asking.

Maybe not in this environment, but this is just geolocation...

Containers talk to weaveDNS via the docker bridge, so the request will always come from a container's docker network IP. weaveDNS could correlate that to a container ID, find out its weave subnets, and filter results based on that.

That filtering is kind of hackish. We could do a proper geolocation mechanism: we could implement CNAMEs in WeaveDNS, so a client could geolocate the client and resolve X.weave.local. to CNAME X.subnet1.weave.local with a long TTL. We could add automatically the subnet1 prefix to all the HTTP API calls from subnet1, so the ZoneDb would have a fully geolocated database. WeaveDNS would then return all the IPs introduced through the API for X.subnet1.weave.local...

But I don't know if this is really worth all the trouble: maybe we should just return all possible answers and let the client try to connect to all of them...

[tomwilkie]

I believe this is fixed by #1065.

If a container has multiple IPs, they will all get returned in a random order by WeaveDNS.

[rade]

Due to #1245, resolvers will actually prefer addresses on their own network. For once this is a good thing.