DNS bad address on alpine image

[joelbong]

Describe the bug
I had 400 error when trying to access Bitwarden public api url. Upon investigating, I found out that pinging google.com was not possible -> bad address. This issue is related to alpine having DNS issues, so the it's not an issue on your part.
Some solution that make it work:

• ping google.com. with an extra dot at the end
• nslookup did also work on google.com without an extra dot.
• putting in /etc/resolv.cont this content only: nameserver 10.152.183.10

To Reproduce
Steps to reproduce the behavior:

1. ping google.com
2. receive bad address

Expected behavior
Should resolve DNS

Additional context
I run a kubernetes talos cluster on proxmox. In the /etc/resolv.conf the DHCP handed out the my pihole instance for the nameserver.

Solution Proposal
I would use a fixed alpine base image where DNS has no issues.

[Skarlso]

Hello. I'm not exactly sure how this is related to this project?

[joelbong]

Hi @Skarlso,

First of all, thanks for the project.

The problem does not lies with bitwarden-sdk-server, but it affects the project. When I upgraded the external secret operator, it did also update bitwarder-sdk-server image, which has a dependency on the latest alpine image at the time you build your image. The latest alpine images have known DNS issues, so I think it might be important to consider/test this when upgrading your images.

As the project is part of the same organization as the external secret operator, I just wanted bring this to attention. I think I could resolv(.conf)e (pun intended) the problem by updating in the chart, 'image.tls.volumes' with a new entry for resolv.conf. For the moment I choose to go back to your previous image.

If you think this is a non-issue, you can close this issue. All the best.

[Skarlso]

Ah. So wouldn't this be a none issue if I just don't use alpine?

[joelbong]

Yes that's my assumption. I found on the web several complain about DNS issues on alpine when using a custom DNS server. My hypothese was confirmed by doing the same test ('ping google.com'), on a base alpine image and a the latest debian:bookworm-slim image. Ofcourse, you would have to see if a new base image would not break the setup.

[joelbong]

I found my exact issue. However i found a manageable solution by configuring the apiURL and identityURL with and extra dot on the end:

apiURL: https://vault.bitwarden.eu./api
identityURL: https://vault.bitwarden.eu./identity

On my part you can close this issue, however maybe put this in the readme.

[Skarlso]

Oh damn. That is super interesting. Thank you. I will update the README. Also going to see about switching distros.