Problem Resolving DSN -> Synology Docker + Pi-hole

[unholyhimura]

Hi, I'm having trouble to resolve the DNS from Bitwarden_rs when installed via docker, inside my synology NAs & using Pi-hole.

Is there a way to manually pass my DNS server? Would it be possible to be added as a next feature?

Why I need it? I won a Yubikey 5 NFC to play with and my bitwarden installation is working as it should, but not when I try to install Two-step Login using YubiKey OTP Security Key, it will give me this error:

Looking at the logs:

date	stream	content
2020-12-22 02:40:56	stdout	[2020-12-22 02:40:56.823][response][INFO] �[32mPUT�[0m �[34m/api/two-factor/yubikey�[0m �[36m(�[0m�[35mactivate_yubikey_put�[0m�[36m)�[0m => 400 Bad Request
2020-12-22 02:40:56	stdout	)
2020-12-22 02:40:56	stdout	},
2020-12-22 02:40:56	stdout	),
2020-12-22 02:40:56	stdout	),
2020-12-22 02:40:56	stdout	},
2020-12-22 02:40:56	stdout	error: "failed to lookup address information: Temporary failure in name resolution",
2020-12-22 02:40:56	stdout	kind: Other,
2020-12-22 02:40:56	stdout	Custom {
**2020-12-22 02:40:56	stdout	"dns error",**
2020-12-22 02:40:56	stdout	ConnectError(
2020-12-22 02:40:56	stdout	Connect,
2020-12-22 02:40:56	stdout	source: hyper::Error(
**2020-12-22 02:40:56	stdout	url: "https://api5.yubico.com/wsapi/2.0/verify?id=XXXX&nonce=XXXXXXXXX",**
2020-12-22 02:40:56	stdout	kind: Request,
2020-12-22 02:40:56	stdout	reqwest::Error {
2020-12-22 02:40:56	stdout	[CAUSE] Network(
2020-12-22 02:40:56	stdout	[2020-12-22 02:40:56.823][error][ERROR] Invalid Yubikey OTP provided.
2020-12-22 02:40:36	stdout	[2020-12-22 02:40:36.577][request][INFO] PUT /api/two-factor/yubikey

If I run the URL API yubico, I get good authentication, so everything is configured as it should, except my DNS.

Thanks for any guidance.

[bmoczulski]

It's probably a consequence of Docker network configuration. I faced a similar problem in my deployment - the root cause was the lack of routing between bitwarden_rs and the Pi-hole. Both deployed as docker containers, but Pi-hole was using macvlan driver attached directly to eth0 with manually configured IP (to be accessible on the standard UDP:53, because I also run DMS's native "DNS Server"). Linux blocks network communication between such containers for better isolation and security.

I ended up exposing the Pi-hole just and only to the other devices on my network via DHCP, but the NAS itself (and consequently all containers running on it too) bypasses the Pi-hole and talks directly to the DNS proxy on my gateway router - DNS address is configured manually in the DMS settings. It was just easier this way. Software running on the NAS is way less likely to be accessing some fishy sites compared to a human using his/her PC or mobile so forgoing the extra protection of the Pi-hole on the NAS is a compromise I can live with.

[unholyhimura]

Hi @bmoczulski , you are correct. I've manually modified the DNS of my NAS server to avoid using my internal pi-hole dns and its working as you shared. I will take your words and stop here :)

Thanks for sharing your feedback.