Make DNS records and queries case-insensitive

[arkodg]

RFC434 states that DNS Servers should be case insensitive
This commit makes sure that all DNS queries will be translated
to lower ASCII characters and all svcRecords will be saved in
lower case to abide by the RFC
Fixes - https://github.com/moby/moby/issues/21169

Signed-off-by: Arko Dasgupta arko.dasgupta@docker.com

[selansen]

@arkodg as per your comment on moby, it will be a problem if we create container Foo and foo and attach in the same network. so we need to make sure it doesn't break existing functionality.

Below is what the test I tried on 19.03

 docker run -itd --network=nw1 --name=COnt1 busybox
docker container ls | grep -i cont1
d32c30ffa045 busybox "sh" 37 seconds ago Up 35 seconds COnt1
4d8a9cd286f4 busybox "sh" About a minute ago Up About a minute cont1```
Moby comment:
=============
Make sure we return a err.Conflict if two containers with different names but same case-insensitive names try to connect to the same network (eg. containers FOO and foo connecting to network bar should NOT be permitted) . 

[thaJeztah]

Should this take some round-robin approach if multiple containers share the same hostname (in different case), but prioritise "exact match" over "match, but different casing"?

I think that was the proposal in; moby/moby#28689 (comment)

1. For non-colliding names, let's just return the case insensitive match.
2. For colliding names, favor the one that matches case.
3. For full collision, return both records pseudo-randomly.

Oh, could you remove Fixes - moby/moby#21169 from the commit-message? (or change to "addresses" / "relates to")

[arkodg]

@thaJeztah the round-robin approach introduces non deterministic behavior so I would not want to implement that

[selansen]

@thaJeztah the round-robin approach introduces non deterministic behavior so I would not want to implement that

Agree. Thats will cause wired behavior.

[thaJeztah]

True, this can be ambiguous, but round-robin is currently supported, and definitely has valid use-cases;

example 1: "blue(ish) / green(ish) deployments"

mkdir case-sense &&cd case-sense
docker network create -d overlay --attachable myoverlay

cat > docker-compose.yml -<<'EOF'version: "3.5"services: web: image: nginx:alpinenetworks: default: external: true name: myoverlayEOF

docker stack deploy -c docker-compose.yml stackblue
docker stack deploy -c docker-compose.yml stackgreen
docker run --rm --network myoverlay alpine nslookup web
nslookup: can't resolve '(null)': Name does not resolveName: webAddress 1: 10.0.1.10Address 2: 10.0.1.13

Example 2: docker compose with aliases and scaling

cat > docker-compose.yml -<<'EOF'version: "3.5"services: web: image: nginx:alpine networks: default: aliases: - foobarnetworks: default: external: true name: myoverlayEOF

docker-compose --project-name=example up -d --scale web=3
docker run --rm --network myoverlay alpine nslookup foobar
nslookup: can't resolve '(null)': Name does not resolveName: foobarAddress 1: 10.0.1.20 example_web_1.myoverlayAddress 2: 10.0.1.21 example_web_2.myoverlayAddress 3: 10.0.1.22 example_web_3.myoverlay

[thaJeztah]

Oh, looks like you made a typo in your commit message; RFC434 should be RFC4343

[thaJeztah]

Reading the RFC to check if case should be preserved, which seems to be the case (RFC4343 section 4);

While ASCII label comparisons are case insensitive, [STD13] says case
MUST be preserved on output and preserved when convenient on input.

Also of note; RFC4034, section 6.2;

all uppercase US-ASCII letters in the owner name of the RR are
replaced by the corresponding lowercase US-ASCII letters;

Which might be different than tolower (if non-US-ASCII characters are present); wondering if some form of strings.ToLowerSpecial() would be needed (during resolve)) otherwise strings.EqualFold could be used

[arkodg]

With the current changes this is the o/p

docker network create bar
docker run -d --name FOO --net bar nginx:alpine
docker run -d --name foo --net bar nginx:alpine
docker run -it --rm --net bar alpine nslookup foo
nslookup: can't resolve '(null)': Name does not resolve
Name: foo
Address 1: 172.20.0.2 foo.bar
Address 2: 172.20.0.3 foo.bar

I guess what you're saying is we need to preserve the name for FOO.bar, but the way we build the DNS name is an implementation detail in libnetwork right ?

[arkodg]

PTAL @thaJeztah@selansen

with the latest changes the behavior looks like the following

docker network create bar
docker run -d --name FOO --net bar nginx:alpine
docker run -d --name foo --net bar nginx:alpine
docker run -it --rm --net bar alpine nslookup fOo
nslookup: can't resolve '(null)': Name does not resolve
Name: fOo
Address 1: 172.20.0.3 foo.bar
Address 2: 172.20.0.2 FOO.bar

[selansen]

This looks good @arkodg

[selansen]

LGTM