[SOLVED] FreedomBox resolves its own external name as 127.0.1.1

Support
1

Problem Description
Good news: we still have internet.
Bad news is that my private domain CNAME to freedombox stopped working, and this is the one we use all the time.

Freedombox gets a FreedomBox Dynamic DNS name as xxx.fbx.one (A record)
My domain is set up with freedombox.yyyy.net CNAME xxx.fbx.one

xxx.fbx.one is working just fine, but freedombox.yyyy.net is no longer resolving as xxx.fbx.one address. My FreedomBox tells me that its FQDN address for freedombox.yyyy.net is 127.0.1.1

SSL certificates look okay in FreedomBox.

dig freedombox.yyyy.net: 127.0.1.1
dig @8.8.8.8 freedombox.yyyy.net:

dig xxx.fbx.one: CORRECT EXTERNAL IP ADDRESS
host 127.0.1.1: 1.1.0.127.in-addr.arpa domain name pointer freedombox.yyyy.net

Iā€™m not sure where to go with this - Iā€™m guessing this is a wrinkle in the recent named changes. Any idea on how to address this would be appreciated.

1 Like
2

Update

It looks like there are some configuration options in Name Services that I havenā€™t seen beforeā€¦

I notice that

Given that my ā€œDomain (regular)ā€ is a CNAME for the dynamic domain it feels like I should remove that from regular and put that in Dynamic Domain, but Iā€™ll wait to do this because thatā€™s not going to work with all the other Dynamic Domain plumbing.

I think Iā€™m an edge case. My use case is something like this:

I have my own domain and I have an IP address that can change. I want to provide FreedomBox services through my own domain name, but cannot automatically configure a DNS A record for my FreedomBox because its external address changes over time and my DNS provider does not offer such a tool.

3

FreedomBox stores domains names provided as static domains (ā€œDomainsā€ in Names) in /etc/hosts file with a address map to 127.0.1.1. This was changed somewhat in a recent release. The end result is that all the static domains declared in the Names app will resolve to 127.0.1.1 within FreedomBox for all programs that include resolutions /etc/hosts.

Since the programs configured to use the static domains want to resolve to localhost ultimately, it is not incorrect to resolve it to 127.0.1.1. One advantage is that these domain resolutions work even when Internet connectivity is not available and those apps will continue to work.

Are you facing problems with any problems with this approach?

4

I am having a problem. Any URL I had been using with my domain, as opposed to the fbx.one dynamic DNS name, is not working. Hereā€™s my plinth URLā€¦

Screenshot from 2025-03-10 06-39-10
Screenshot from 2025-03-10 06-39-10924Ɨ516 49.1 KB

Iā€™m also getting periodic pop-ups when the radicale client does not connect using the URL with that domain.

Connecting a web browser from a client on the internal network with different names looks like thisā€¦
https://hostname.local/ works with about a 5 second name resolution
https://hostname.fbx.one/ resolves quickly and works perfectly
https://hostname.mydomain.net/ immediately gives the unable to connect error.

5

Does the shown error happen from a machine that is connected via a shared internet connection to FreedomBox?

6

Correct, clients are on the internal network which is a shared connection. The other network interface is DHCP client to the ISP connected directly to the ISP modem.

Interestingly, Iā€™m on the outside right now and nearly the reverse appears to be true. Coming in from internet to the primary connection (DHCP client to ISP):

2 Likes
7

Thank you for this information.

I havenā€™t fully tested this situation. Sorry about this. It clearly looks like this approach needs to be changed. I will prepare a fix for this soon and it should be available in the next release.

I wonder why xxx.fbx.one was not reachable from outside. This needs separate investigation. Could you please check that DNS is pointing to same IP as your static domain name?

1 Like
8

A fix is ready. Should roll out in the next release.

2 Likes
9

Amazing. Thanks very much for that!

10

It works today. Thanks for that.
Check that, I was on the wrong side. Iā€™ll watch for the update and try again.

11

Iā€™m not resolving DNS now and have no Internet. FreedomBox is my router.

FreedomBox resolv.conf resolver is 127.0.0.53 <= looks similar to the original issue reported
Client resolver is 192.168.144.2 (fb internal address)

I had a problem with one Internet host so I tried changing DNS servers in the primary interface back to ISP default. I was unable to get DNS from FreedomBox after restarting the primary interface. A reboot did not clear this up.

Current state after reboot:

  • reboot seemed slow
  • primary nic has ISP IP address
  • secondary internal has IP address
  • plinth is not there, but I can Ssh to FreedomBox
  • I can ping 8.8.8.8
  • I can not dig www.google.com: ;; communications error to 127.0.0.53#53
  • sudo takes ages to prompt me for password
  • plinth is running, but http to internal nic gives error "unable to connect an error occurred during a connection to 192.168.144.1
  • forcing client to use 8.8.8.8 for DNS is working
  • While I have internet when I specify the Google DNS service, I cannot connect to plinth with my web browser on any of freedombox.local, 192.168.144.1, fbx.one dynamic DNS name, or from my domain name CNAME to fbx.one.
  • the fbx.one and personal domain names both have the current IP address set (dynamic DNS service is working)

@sunil

12

This is expected. This allows all the client programs on the FreedomBox to contact systemd-resolved for their DNS resolutions. systemd-resolved is still the resolver for FreedomBox.

This likely means that systemd-resolved is not running. What does systemctl status systemd-resolved show? Also, what does the ā€˜Resolve Statusā€™ in ā€˜Namesā€™ app show? Another way to obtain that information is resolvectl status.

This is likely due to failure to resolve machineā€™s own hostname. ā€˜libnss-myhostnameā€™ package, part of systemd, should have prevented this. This library has not dependencies on anything and should have always worked. Do commands like ping localhost, ping _gateway work?

None of the problems outlined seem anyway connected to the recent changes deployed. All they do is remove the entries for 127.0.0.2 from /etc/hosts file.

13

Here is the systemtcl status systemd-resolvedā€¦

ā— systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Thu 2025-03-27 17:23:43 MST; 11h ago
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Main PID: 1261 (systemd-resolve)
Status: ā€œProcessing requestsā€¦ā€
Tasks: 1 (limit: 19095)
Memory: 10.7M
CPU: 35.924s
CGroup: /system.slice/systemd-resolved.service
ā””ā”€1261 /lib/systemd/systemd-resolved

Mar 27 17:23:42 freedombox systemd-resolved[1261]: . IN DS 38696 8 2 683d2d0acb8c9b712a1948b27f741219298d0a450d612c483af444a4c0fb2b16
Mar 27 17:23:42 freedombox systemd-resolved[1261]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 170.0.0.192.in-addr.arpa 171.0.0.192.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa ipv4only.arpa corp home internal intranet lan local private test
Mar 27 17:23:43 freedombox systemd-resolved[1261]: Using system hostname ā€˜freedomboxā€™.
Mar 27 17:23:43 freedombox systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Mar 27 17:24:07 freedombox systemd-resolved[1261]: Switching to fallback DNS server 1.1.1.1#cloudflare-dns.com.
Mar 27 17:24:10 freedombox systemd-resolved[1261]: eno1: Bus client set search domain list to: ispdetails.com
Mar 27 17:24:10 freedombox systemd-resolved[1261]: eno1: Bus client set default route setting: yes
Mar 27 17:24:10 freedombox systemd-resolved[1261]: eno1: Bus client set DNS server list to: ispdns1, ispdns2
Mar 27 17:24:10 freedombox systemd-resolved[1261]: eno2: Bus client set default route setting: no
Mar 27 17:24:10 freedombox systemd-resolved[1261]: wg0: Bus client set default route setting: no

ā€¦ and resolvectl status

Global
Protocols: +LLMNR +mDNS +DNSOverTLS DNSSEC=yes/supported
resolv.conf mode: stub
Fallback DNS Servers 1.1.1.1#cloudflare-dns.com 8.8.8.8#dns.google
1.0.0.1#cloudflare-dns.com 8.8.4.4#dns.google
2606:4700:4700::1111#cloudflare-dns.com
2001:4860:4860::8888#dns.google
2606:4700:4700::1001#cloudflare-dns.com
2001:4860:4860::8844#dns.google

Link 2 (eno1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported
Current DNS Server: ispdns1
DNS Servers: ispdns1 ispdns2
DNS Domain: ispdetails

Link 3 (eno2)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported

Link 4 (eno3)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported

Link 5 (eno4)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported

Link 6 (wg0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS +DNSOverTLS DNSSEC=yes/supported

ā€¦ and libnss-myhostname is installed:

$ apt search libnss-myhostname
Sortingā€¦ Done
Full Text Searchā€¦ Done
libnss-myhostname/stable,now 252.36-1~deb12u1 amd64 [installed,automatic]
nss module providing fallback resolution for the current hostname

nsswitch.conf

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

14

So, systemd-resolved is running properly. systemd-resolved also acquired the DNS servers from ISP via network-manager.

You seem to have DNSSEC and DNS-over-TLS enabled globally. If your ISPā€™s DNS servers do not support these features, all name resolutions will fail as we are noticing. Please try disabling these features.

If that does not work, you can also try running: resolvectl query debian.org, dig @1.1.1.1 debian.org and dig @ispdns1 debian.org.

I think it should look a bit different as follows:

hosts:          files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns

Notice that, in my case, myhostname has high priority (appears early in the line). Before trying other methods, hostname of the machine will be resolved early. You can try changing this order to deal with hostname issues while DNS server is not working.

I donā€™t know why in your case it is ordered like this. By default, as soon as the package libnss-myhostname is installed (this is a dependency of FreedomBox), the order should be configured like in my case. Perhaps this is a packaging bug.

1 Like
15

Cool - do you happen to know how to do this from command line? I donā€™t have any plinth right now.

I commented out those options from /etc/systemd/resolve.conf.d/freedombox.conf and name resolution is working again. Thanks!

Plinth is back after reboot. My laptop is resolving through FreedomBox. The big stuff is back in order. Thanks for helping me out.

16

[quote=ā€œsunil, post:14, topic:3660ā€]
I donā€™t know why in your case it is ordered like this. By default, as soon as the package libnss-myhostname is installed (this is a dependency of FreedomBox), the order should be configured like in my case. Perhaps this is a packaging bug.
[/quote]

Iā€™m going to run with this for now. If I reinstall libnss-myhostname do you think that would get sorted, or would I change that by hand?

17

I was going to write exactly this. Awesome!

I guess this problem can be marked as solved.

Taking a backup of the file and editing by hand should be alright. I donā€™t know if reinstalling the package will fix this (but should be safe).