Can't resolve names of containers in the same docker network if their names contain dots

[tkowpt]

Version

v18.17.1

Platform

Linux ca539b8b4950 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2 x86_64 GNU/Linux

Subsystem

dns

What steps will reproduce the bug?

# Create docker network `test`
docker network create test

# Run containers attached to the same network `test` so that they can resolve their names
docker run -d --name test3.0 --network test node:18.17 bash -c 'while true; do date; sleep 10; done'
docker run -d --name test3.4 --network test node:18.17 bash -c 'while true; do date; sleep 10; done'

# Switch to container test3.0
docker exec -it test3.0 bash

# This should show that the name of test3.4 is properly resolvable
apt-get update
apt-get install inetutils-ping
ping -c 1 -i 1 test3.4

# This should show that test3.4 is not properly resolvable for node
node

const dns = require('dns');
dns.resolve('test3.4', (err, data) => console.log(err, data));

How often does it reproduce? Is there a required condition?

The problem is reproducible if the name of the docker container ends with .4 for example. In contrast, I can resolve names of docker containers like test3.z correctly.

What is the expected behavior? Why is that the expected behavior?

The names of the docker containers in the same docker network should be resolvable even if they contain dots.

What do you see instead?

> dns.resolve('test3.4', (err,dat) => console.log(err,dat));
QueryReqWrap {
  bindingName: 'queryA',
  callback: [Function (anonymous)],
  hostname: 'test3.4',
  oncomplete: [Function: onresolve],
  ttl: false
}
> Error: queryA ENODATA test3.4
    at QueryReqWrap.onresolve [as oncomplete] (node:internal/dns/callback_resolver:47:19)
    at QueryReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
  errno: undefined,
  code: 'ENODATA',
  syscall: 'queryA',
  hostname: 'test3.4'
} undefined

Additional information

Interestingly, the problem is not reproducible with node:18.16 but with node:18.17 and the usual name resolution inside the docker container is working properly as one can verify with ping for example. Furthermore, the problem is not reproducible, if the name of the docker container doesn't contain any dots.

I'm using docker engine version 24.0.5

The people from the docker-node repository already verified, that there isn't anything they could do to solve this problem. (Refer to: nodejs/docker-node#1954)

Here is some information from wireshark about the DNS request, that node has sent. It doesn't seem to be the proper request here. At least node is not asking for test3.4.

Frame 17: 61 bytes on wire (488 bits), 61 bytes captured (488 bits) on interface any, id 0
Linux cooked capture v1
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.11
User Datagram Protocol, Src Port: 41089, Dst Port: 49445
Domain Name System (query)
    Transaction ID: 0x93c7
    Flags: 0x0100 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        <Root>: type A, class IN
            Name: <Root>
            [Name Length: 6]
            [Label Count: 1]
            Type: A (Host Address) (1)
            Class: IN (0x0001)

[bnoordhuis]

This is almost certainly caused by the c-ares upgrade in v18.16.1.

That said... does "test3.4." (note the trailing dot) work? c-ares parses /etc/resolv.conf and if you have e.g. a search domain set, that will make it look up something different from what you intend unless you use a FQDN.

[tkowpt]

I would like to add, that I can't reproduce the problem with node v18.16.1.

Furthermore, I have a search domain set in my docker container, but using a dot at the end of the hostname doesn't help.

[bnoordhuis]

Does removing the search domain help? Can you try reducing your resolv.conf to just a single nameserver <ip> stanza?

[tkowpt]

I've changed /etc/resolv.conf to

nameserver 127.0.0.11

with the same result as before.

Before this change I also had an options ndots:0 in my /etc/resolv.conf which should mean, that DNS requests should be directly sent without trying any search domains.

[tkowpt]

I think that this issue could be related to a change of parse_host in deps/ada/ada.cpp from version 18.16.1 to 18.17.0.

A comment in this function says:

If asciiDomain ends in a number, then return the result of IPv4 parsing asciiDomain.

I think that this would not work for test3.4. However, this should not lead to a DNS request for "".

#49330 is an issue where the change in ada is mentioned as well.

[bnoordhuis]

Sounds plausible. @anonrig (and presumably @lemire) can you take a look?

[anonrig]

This is already fixed with #48873. It is a part of the next v18 release.

[anonrig]

Might be a duplicate of: #49203

[bnoordhuis]

I believe this was fixed in v18.18.0. Closing but LMK if there is reason to reopen.