Both questions have the same root, so let me take the second one first because it is the one that will keep biting you.
Anything you edit inside a running container is written to that container's writable layer, and the writable layer is destroyed when the container is replaced. Every update, every redeploy, every restart of a container that is recreated rather than resumed — gone. This is not a quirk of this app, it is how containers work, and it is why every serious image exposes its settings through environment variables or a mounted config file.
So: set the trusted hostname either as an environment variable in your deployment, or in a config file that lives on a mounted host path rather than inside the image. Those two survive. Nothing else does.
Now the first question, which is worth understanding rather than just working around.
The app is not checking DNS. It is checking the Host header on the incoming request against an allowlist, and refusing anything not on it. That is a deliberate defence: an app that trusts whatever hostname a request claims can be tricked into generating password-reset links, redirects and asset URLs pointing at an attacker's domain. The check is a nuisance exactly once, when you legitimately add a new name.
While you are in there, set the other two settings that matter behind a proxy, because you are about to hit them:
The public URL, protocol and host. Your proxy terminates TLS and talks to the app over plain HTTP on the internal network. Left alone, the app sees an HTTP request and builds every absolute link — reset emails, share links, client config — as http:// on the internal address. Users get links that do not work from outside. Setting the overwrite protocol to https and the overwrite host to your public hostname fixes it.
Trusted proxies. The app should log the real client address, not your proxy's. It will only believe the forwarded-for header if it knows the request came from a proxy it trusts, so give it your proxy's address. Get this wrong in the other direction — trusting everything — and any client can forge its own source address in your logs and in any rate limiting you do.
Set those three together, redeploy once, and the whole class of "works internally, broken externally" problems goes away.