[BUG] Latest update seems to break DNS when --dns parameter specified

[tomrwaller]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I use the extra arguement of --dns=x.x.x.x for all of my LSIO containers. This works well and is continuing to work well for all other services such as Sonarr, Transmission, HA etc. Radarr seems to have stopped accepting this parameter.

If I launch a console and do an nslookup address.domain.com, the result is the default Docker DNS entry of 172.0.0.11, as opposed to my custom specified DNS server.

As a result, I cannot resolve any of my custom addresses for indexers, download clients etc.

As a test, I swapped out to binhix Radarr and it works as expected.

Expected Behavior

DNS resolution should work with custom DNS server specified.

Steps To Reproduce

Launch container with --dns arguement present.
Open console.
Run nslookup against a domain.

Environment

- OS: UnRAID latest

CPU architecture

x86-64

Docker creation

docker run
  -d
  --name='Radarr'
  --net='br2.40'
  --ip='10.40.3.2'
  -e TZ="Europe/London"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="nas-a"
  -e HOST_CONTAINERNAME="Radarr"
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='https://radarr.redacted.com'
  -l net.unraid.docker.icon='https://camo.githubusercontent.com/35533bcac396e6a5b23ee314e1c6a001313aa963ddac0a4dcd77d84bed16e957/68747470733a2f2f63646e2e7261776769742e636f6d2f4a6f75726e65794f7665722f63686f636f6c617465792d7061636b616765732f343735656466323166376139613531633862633561616266623132336264386534313130316637332f69636f6e732f7261646172722e706e67'
  -v '/mnt/user/docker/radarr/config':'/config':'rw'
  -v '/mnt/user/media/films/':'/movies':'rw'
  -v '/mnt/user/downloads/':'/downloads':'rw'
  --dns=10.40.0.1 'linuxserver/radarr' 

Container logs

root@f45f935ab828:/# nslookup jackett.redacted.com
Server:         127.0.0.11
Address:        127.0.0.11:53

Non-authoritative answer:
Name:   jackett.redacted.com
Address: 10.10.3.1

** server can't find jackett.redacted.com: NXDOMAIN


[Warn] DownloadMonitoringService: Unable to retrieve queue and history items from Transmission 

[v4.5.2.7388] System.Net.Http.HttpRequestException: Name does not resolve (transmission.redacted.com:443)
 ---> System.Net.Sockets.SocketException (0xFFFDFFFF): Name does not resolve
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Sockets.Socket.<ConnectAsync>g__WaitForConnectWithCancellation|277_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)
   at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.attemptConnection(AddressFamily addressFamily, SocketsHttpConnectionContext context, CancellationToken cancellationToken) in ./Radarr.Common/Http/Dispatchers/ManagedHttpDispatcher.cs:line 285
   at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.onConnect(SocketsHttpConnectionContext context, CancellationToken cancellationToken) in ./Radarr.Common/Http/Dispatchers/ManagedHttpDispatcher.cs:line 271
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(HttpRequestMessage request)
   at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellation(CancellationToken cancellationToken)
   at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellationAsync(Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.GetHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken)
   at System.Net.Http.HttpMessageHandlerStage.Send(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.DiagnosticsHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpMessageHandlerStage.Send(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.SocketsHttpHandler.Send(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpMessageInvoker.Send(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.Send(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationToken cancellationToken)
   at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponse(HttpRequest request, CookieContainer cookies) in ./Radarr.Common/Http/Dispatchers/ManagedHttpDispatcher.cs:line 101
   at NzbDrone.Common.Http.HttpClient.ExecuteRequest(HttpRequest request, CookieContainer cookieContainer) in ./Radarr.Common/Http/HttpClient.cs:line 124
   at NzbDrone.Common.Http.HttpClient.Execute(HttpRequest request) in ./Radarr.Common/Http/HttpClient.cs:line 59
   at NzbDrone.Core.Download.Clients.Transmission.TransmissionProxy.AuthenticateClient(HttpRequestBuilder requestBuilder, TransmissionSettings settings, Boolean reauthenticate) in ./Radarr.Core/Download/Clients/Transmission/TransmissionProxy.cs:line 222
   at NzbDrone.Core.Download.Clients.Transmission.TransmissionProxy.ProcessRequest(String action, Object arguments, TransmissionSettings settings) in ./Radarr.Core/Download/Clients/Transmission/TransmissionProxy.cs:line 259
   at NzbDrone.Core.Download.Clients.Transmission.TransmissionProxy.GetTorrentStatus(IEnumerable`1 hashStrings, TransmissionSettings settings) in ./Radarr.Core/Download/Clients/Transmission/TransmissionProxy.cs:line 191
   at NzbDrone.Core.Download.Clients.Transmission.TransmissionProxy.GetTorrentStatus(TransmissionSettings settings) in ./Radarr.Core/Download/Clients/Transmission/TransmissionProxy.cs:line 155
   at NzbDrone.Core.Download.Clients.Transmission.TransmissionProxy.GetTorrents(TransmissionSettings settings) in ./Radarr.Core/Download/Clients/Transmission/TransmissionProxy.cs:line 43
   at NzbDrone.Core.Download.Clients.Transmission.TransmissionBase.GetItems() in ./Radarr.Core/Download/Clients/Transmission/TransmissionBase.cs:line 38
   at NzbDrone.Core.Download.TrackedDownloads.DownloadMonitoringService.ProcessClientDownloads(IDownloadClient downloadClient) in ./Radarr.Core/Download/TrackedDownloads/DownloadMonitoringService.cs:line 90

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[awonglk]

I have the same issue. I didn't need to specify --dns before and it used to pickup local DNS server automatically and resolve domains. The container support team on Discord doesn't think this is an issue though.

[j0nnymoe]

@awonglk as mentioned in the discord, it worked fine when you were using a normal bridged network (non macvlan) - which to us seems like your macvlan could be configured incorrectly.

Was suggested to continue conversation in #other-support but I didn't see you continue it there.

[awonglk]

The result is the same on bridged network or macvlan (does not resolve domains from local DNS server)

Similar to [tomrwaller]
I switched to binhex/arch-radarr
And it works fine with macvlan

I think this issue here deserves to be looked at though. Something in the image is using a fixed external resolver.

Happy to bring this up on #other-support if it helps.

[Roxedus]

There is no evidence of any hardcoded dns, I also cannot repro the OP

[awonglk]

Happy to supply anything else you need to help reproduce the issue..
I've ran these commands to show why Radarr isn't able to "talk" to hostnames that only exists on my local DNS server
It resolves via nslookup

$ docker exec -it radarr bash
root@radarr2:/# nslookup -type=a deluge2.whereisant.com
Server:         172.30.0.1
Address:        172.30.0.1:53

Non-authoritative answer:
Name:   deluge2.whereisant.com
Address: 192.168.12.38

But it fails when I ping the same host above..

root@radarr2:/# ping deluge2.whereisant.com
ping: bad address 'deluge2.whereisant.com'

It seems to be happy with pinging any external domains, and nslookup (using "cnn.com" as an example)

root@radarr2:/# ping cnn.com
PING cnn.com (151.101.3.5): 56 data bytes
64 bytes from 151.101.3.5: seq=0 ttl=60 time=3.755 ms
64 bytes from 151.101.3.5: seq=1 ttl=60 time=3.374 ms

root@radarr2:/# nslookup -type=a cnn.com
Server:         127.0.0.11
Address:        127.0.0.11:53

Non-authoritative answer:
Name:   cnn.com
Address: 151.101.195.5
Name:   cnn.com
Address: 151.101.131.5
Name:   cnn.com
Address: 151.101.67.5
Name:   cnn.com
Address: 151.101.3.5

That's the reason why I suspected it's somehow picked up some external DNS resolver.

[aptalca]

For op, the dns parameter is a docker argument and not something that is interpreted by our init.

For the other reporter, random nslookup results aren't helpful without proper context. They're showing different dns servers, which suggests containers in different networks so not directly comparable. Please continue to ask for support on our discord in #other-support as requested. Macvlan networks are very different than bridge networks and they may interact differently with your custom dns server (whatever it may be, which we don't know).

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[wesleykirkland]

I've been troubleshooting DNS all night and wanted to add some context here as this is the only GitHub issue I could find.

I'm running the arr's and I've noticed this behavior in radar when it couldn't connect to prowlarr.

(IPs and DNS changed)
My network config is a pihole running on a separate host in a different vlan (192.168.2.15). The unraid host can communicate just fine to it, and all containers except the arrs from Linuxserver can communicate just fine. Now here is the interesting thing, within the arr containers I have 2 internal DNS zones. One on the pihole (house.myowndomain.land and one on AD (home.local). I can communicate with home.local just fine and it resolvers perfectly! But as soon as I use my own external domain that I own I can't resolve anything. It's an ICANN registered TLD (.land) and I run split brain DNS with PiHole. Unraid (docker host) is configured to use the PiHole DNS. And I can see that this is working through a flaresolverr container which is not LinuxServer and in the same ipvlan as the other arr's.

I'm coming to an initial conclusion that there is something hard coded in the arr containers that isn't a DNS server, but some type of logic to validate common internal DNS zones and use those otherwise ignore them for public DNS zones. I can validate this by creating stub zones everywhere in my stack and they still won't validate. Though what's odd is the Linuxserver plex container doesn't contain any of this logic.

I hope this helps, I personally would love to get this resolved.

Edit: Ok I have no idea what's going on now, my conclusion above is still correct. Though everything was configured and validated with the .land domain and days later it's broken with no container version change or network changes. I'm investigating that more but the above still stands.

[sethjones]

While I haven't solved this.

In my k8s cluster forcing the following dns setting in the pod has worked around the issue:

dnsConfig:
  options:
    - name: ndots
      value: "1"

[wesleykirkland]

@sethjones This seems to be the answer, question for those not on K8s at home. Is there a docker-compose equivalent?

Ok so after much research this is a K8s specific option, dns_opts is implemented in docker-compose but only use-vc and no-tld-query which is frustrating. This is documented at https://docs.docker.com/compose/compose-file/compose-file-v2/#dns_opt

I worked around it by creating /etc/docker/daemon.json and adding (5 because my domain is home.mydomain.tld and 5 was n+1 with absolute resolution of record.home.mydomain.tld. This failed so I added DNS search suffixed via docker and that worked on my other domain of mydomain.local but not for my other domain. Something about this is all pissed off and I can't find it.

{
  "dns-opts":[
    "ndots:5"
  ]
}

But my case has vered into different territory, I operate a separate VLAN that is restricted and I tried a bazarr container on both subnets and once I bring it internal it works. IDK what's up with this as the restricted VLAN can resolve my other internal zone. I wonder if there is a cool config on the router. So to add to this, ndots 0 is fine with my config and appears to be something different. I'm going to leave my comments here for the next person, maybe I can be the next DenverCoder9.

Final Edit: Past me is an idiot, the restricted VLAN has a different DHCP config, and I never realized that ipvlan didn't use host based DNS since it's abstracted away to 127.0.0.11 which isn't a real IP I can easily validate against. I need to make a troubleshooting container.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[xadves]

I am having the same issue. From within the container I am able to nslookup and dig my DNS and resolve the host (local domain name) but using ping/curl/wget returns a "bad address". Seems others have this issue after searching for a while with the Alpine 3.13 - 3.18 image

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[tomrwaller]

Just mentioning this is still an issue for me. Also, it has now started happening on the Lidarr and Sonarr images too :( I switched to BinHex a few months ago and they worked fine up till last week and now exhibit the same issue. I'd like to switch back to LSIO with a fix but still can't get this working.

[j0nnymoe]

If you're experiencing the same issue with a different container, it could be a problem with your host/setup?

[tomrwaller]

If you're experiencing the same issue with a different container, it could be a problem with your host/setup?

I had thought that but nothing has changed host/network side, and all other containers work just fine, such as LSIO Plex and Jackett. This is just affecting the *arr suite.

As one of the comments above alluded to, I also point to internally resolvable DNS names, such as sonarr.domain.click. These do have an external registration with a provider but records only exist for my internal DNS service so they aren't resolvable externally.

This all worked for years until I opened this issue when it just stopped working. I switched to BinHex for a few months as that didn't exhibit the issue, with the exact same config, but again, that broke last week.

[todaywasawesome]

I was able to fix this by changing my network router Local Zone Type from Transparent to Static. After that DNS works smoothly everywhere.

More info here:
https://www.reddit.com/r/kubernetes/comments/duj86x/help_understanding_how_dns_works_and_what_ndots/
https://docs.netgate.com/tnsr/en/latest/dns/local-zone.html

[homerr]

I'd like to try and work this one but I can't figure out what you're all using now. There's some mentions of k8's above and then some unraid.

I can only test with Debian hosts, but can replicate network segregation.