Hello, i have a problem with DNS Resolving. I have a Rocky Linux 9 server which is running PowerDNS and also Nginx Proxy Manager. When i try to access Cockpit using IPv4 address everything works fine, but when i use DNS name it gives me an PR_END_OF_FILE_ERROR error in Firefox. In Twingate the resource is called *.zeus.local and in my PowerDNS i have a record also *.zeus.local but it’s not working.
Hi Daniel,
I’d never come across PR_END_OF_FILE as an error until today. It looks like it’s specifically a Firefox thing related to encryption ciphers.
There are some suggestions that VPN software can cause this particular issue, however I can think of no reason Twingate should be interfering in the communication to cause this in any way.
Do you get the behaviour (or similar) out of any other browsers?
The other thing I see in your connection logs is that for whatever reason, when the connector attempts to resolve zeus.local it’s not getting a proper IP and is coming back with 0.0.0.0 which could also be an issue.
Are you able to add an entry for something like cockpit.zeus.local that resolves to the same IP and see if that address works correctly? I know there can be some shenanigans specific to trying to access domain.local rather than sub.domain.local so I wonder if that’s what’s going on.
Give that a try and let me know!
-arthur
I added cockpit.zeus.local resource and also a cockpit.zeus.local A record and still i get the same error. I tested this on Chromium and got and error saying that response is empty
I did some more digging and checked with my team, and it looks like the connector is not getting a response back, and is getting a DNS error.
Is the container or device your connector is running on using that same PowerDNS server to do its lookups? Something may be preventing the DNS server from answering properly.
If this is the case, there’s a chance the EOF/errors you’re seeing are because we’re trying to facilitate a connection but can’t see it all the way through, so the browser thinks things are going well and then we say “nope sorry, we cant actually reach where you want to go” and things then “fail”.
Are you running the connector in the same spot as the DNS server and such? If you do a nslookup cockpit.zeus.local from the CLI of whatever’s running the container, do you get an accurate response?
Thanks,
-arthur
I actually found a solution (sort of), i thought that maybe there is some sort of routing problem that connector container can’t do a dns request to a another container (i run my PowerDNS in a container) so i removed a docker connector and installed a native Linux version. It actually works but i stil get EOF error. I can get rid of that error by just refreshing a page few times and i can login to whatever service i want to access. Its little irritating but at least it works now.
After migrating to RHEL it stopped working again, even when i installed native Linux Version.
Is it failing in the same way as it did previously?
If you do the nslookup cockpit.zeus from the machine running the connector, what do you get back for a response?