Hello Everyone,

As the title says, I am having issues reaching my internally hosted resources via reverse proxy on my Fedora KDE install. I found little info about this, and I am wondering if I am on a wild goose chase.

Any help would be greatly appreciated, and sorry for the wall of text in advance!

Here’s the anonymized setup:

192.168.1.10 is the docker host with web services on different ports 192.168.1.20 is the server that acts as a reverse proxy via caddy2, so I can use app.domain.example instead of ip:port and it handles certs from let’s encrypt via DNS challenge. No ports are open to the internet. I VPN in when remote access is needed.

192.168.1.30 is the Pihole set up as the DHCP assigned local DNS. It has local DNS entries: A record for caddy.domain.example mapped to 192.168.1.20 CNAME record for app.domain.example mapped to caddy.domain.example

This works perfectly fine on other devices and distros, windows, android etc. On Fedora KDE live images 42 and 43 beta, and the installed OSs have this problem (currently have 42 installed so this is not a beta thing) Access works via IP:Port. It looks like it just doesn’t want to take the reverse proxy route.

If I do an nslookup from the fedora device, it reaches pihole, and can resolve app.domain.example to caddy.domain.example, then that to 192.168.1.20.

nslookup app.domain.example
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
app.domain.example  canonical name = caddy.domain.exampe
Name:   caddy.domain.example
Address: 192.168.1.20
caddy.domain.example canonical name = 192.168.1.20.

resolvectl link 3 is the relevant one.

resolvectl
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp3s0f0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 3 (wlp1s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.30
       DNS Servers: 192.168.1.30
        DNS Domain: domain.local
     Default Route: yes

I can see it’s using the stub resolver which I found some docs about but I am unsure what to change at this stage.

If I run traceroute for app.domain.example i get “No address associated with hostname”

I guess this is because here isn’t any public records for this subdomain, only the wildcard pointing to my local Caddy IP for the certs.

Thanks for reading!

    • GetAwayWithThis@lemmy.dbzer0.comOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      5 hours ago

      I have a domain registered that I use, just didn’t feel the need to mention it exactly. Hence why I anonymized my results. I did not change anything that would alter the troubleshooting steps, only the domain name and ip addresses are generic but otherwise consistent.

      The domain and records are set up correctly on the provider end because I receive valid let’s encrypt certs for my subdomains through caddy. The issue is only with Fedora. I checked a live of ubuntu and fedora iso on a second computer. Fedora consistently cannot resolve the domains on the default configuration while ubuntu and anything else I tried can.

      I just tried adding the local IP:Port and the app.domain.example to the /etc/hosts file as the examples show. Restarted systemd-resolved but no dice. Ideally, I’d like to make this family friendly and avoid having to make client specific configurations anyway. So far only I run fedora at home, so my device has this issue only. I am partial to the OS otherwise, so I was hoping I could solve this.

      EDIT Sorry about that it dawned on my what you asked for really. From the resolvedctl results DNS Domain: domain.local would be mydomainname.local. Yes I kept .local in the search domain fields for most of my things. Is this something that matters, or could this be a workaround if I changed it to my actual mydomainname.tld? As far as I undertand this would work if mDNS was on. Not sure if LLMNR makes use of it the same way.