[BUG] recent Radarr images (since Nov 2022?) seem to prefer ipv6?

[yegle]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

Somehow the image starts to try ipv6 and ipv6 only without fallback to ipv4 connections. Given a domain like this:

# nslookup ds1515p.local
Server:         192.168.100.50
Address:        192.168.100.50:53

Non-authoritative answer:
Name:   ds1515p.local
Address: 192.168.100.28

** server can't find ds1515p.local: NXDOMAIN

A curl will fail with:

docker exec -it radarr curl ds1515p.local
curl: (6) Could not resolve host: ds1515p.local

While force it to use ipv4 would work:

docker exec -it radarr curl -4 ds1515p.local
// Some html

Due to this, I was unable to use the hostname when specifying the download client and had to use the ipv4 address.

Expected Behavior

At the minimum, everything should try ipv6 first and fallback to ipv4. Better, since I have not enabled ipv6 on docker daemon, no ipv6 DNS resolving and connecting should be attempted.

Steps To Reproduce

1. Run the container
2. curl a hostname in which querying A record will return the correct answer but query AAAA will return NXDOMAIN.
3. curl will fail.

Environment

- OS: Synology DSM 7.1.1-42962
- How docker service was installed: DSM built-in.

CPU architecture

x86-64

Docker creation

(nothing special here. Standard container with a couple bind-mount and environment variables. Only thing network related is `--network bridge`)

Container logs

A lot of logs about failing to resolve `ds1515p.local`.

[github-actions[bot]]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[yegle]

In the end I had to add an AAAA record for ds1515p.local on my DNS server to workaround the issue, despite that everything in the container still connect to the server via ipv4.

$ docker exec -it radarr curl ds1515p.local
// some html

I suspect the issue is with the DNS server returning NXDOMAIN for a domain with A record but no AAAA record. FWIW, the DNS server is the embedded one on my router (https://mikrotik.com) and I think the implementation is broken. But I also think this might be an issue with either the updated Alpine base image or something else on the container, because 1) the setup of using ds1515p.local as my download client hostname worked before, and 2) my Sonarr container can use the ds1515p.local as the download client hostname.

To show that the issue is not just because of the container preferring IPv6 and not falling back to IPv4, it does work with a domain name without IPv6 configured:

$ docker exec -it radarr curl ipv4.google.com
// some html

[yegle]

Holy shit. I think this is indeed a bug in Mikrotik RouterOS 7.7 (the latest version) released on 2023-01-12 and according to the post in their forum the bug will be fixed in the next version: https://forum.mikrotik.com/viewtopic.php?t=192878

I'll close this bug.