DDNS Failing Core 203 [SOLVED]

Network DNS
1

Latest update core 203 appears to have broken blue DNS and DDNS. Blue DNS I have worked around for now, but DDNS fails no matter how configured.

I see the method was changed which I did update with DDNS Key through no-ip. All is correct but still failing with the same error message. Any thoughts will be appreciated.

Dynamic DNS update for (redacted).com (NoIP) threw an unhandled exception: Traceback (most recent call last): File “/usr/lib/python3.10/site-packages/ddns/system.py”, line 276, in get_address return self.__addresses[proto] KeyError: ‘ipv4’ During handling of the above exception, another exception occurred: Traceback (most recent call last): File “/usr/lib/python3.10/urllib/request.py”, line 1348, in do_open h.request(req.get_method(), req.selector, req.data, headers, File “/usr/lib/python3.10/http/client.py”, line 1282, in request self._send_request(method, url, body, headers, encode_chunked) File “/usr/lib/python3.10/http/client.py”, line 1328, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File “/usr/lib/python3.10/http/client.py”, line 1277, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File “/usr/lib/python3.10/http/client.py”, line 1037, in _send_output self.send(msg) File “/usr/lib/python3.10/http/client.py”, line 975, in send self.connect() File “/usr/lib/python3.10/http/client.py”, line 1447, in connect super().connect() File “/usr/lib/python3.10/http/client.py”, line 941, in connect self.sock = self._create_connection( File “/usr/lib/python3.10/socket.py”, line 845, in create_connection raise err File “/usr/lib/python3.10/socket.py”, line 833, in create_connection sock.connect(sa) TimeoutError: timed out During handling of the above exception, another exception occurred: Traceback (most recent call last): File “/usr/lib/python3.10/site-packages/ddns/_init_.py”, line 178, in _update entry(force=force) File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 157, in _call_ elif self.has_failure or not self.requires_update: File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 202, in requires_update if self.ip_address_changed(self.protocols): File “/usr/lib/python3.10/site-packages/ddns/providers.py”, line 270, in ip_addr

2

DDNS was not changed in CU203.

The last update to DDNS was in Sept 2021.

The error message looks to be saying that there was a KeyError with the use of ipv4 as the protocol.

Maybe noip have changed how they are accepting the ddns update information.

3

DDNS was not changed specifically, but the update is what broke DDNS resolution and Blue DNS.

No-IP still does username/password AND they do DDNS Key. Neither is working now with IPFIRE.

4

:thinking:
Check whether the following addresses are accessible from your IPFire.

checkip4.dns.lightningwirelabs.com

dynupdate.no-ip.com

edit

The following commands may also be helpful

ddns -d update-all

ddns -d update-all --force

5

I got myself a free No-IP DDNS account yesterday night and set it up on my IPFire.

I had the entry shown in green so it was aligned with NO-IP.

I then changed the IP in the No-IP account and the entry in my IPFire went red, indicating an update was required.

I pressed the Instant Update button and checked the DDNS system logs and the update occurred successfully.

The TTL for No-IP is 60 seconds so I waited for a minute and then checked with dig and confirmed that the IP had been changed in No-IP and also the entry in IPFire went green again.

So the No-IP entry worked fine for me.

As suggested by @tphz check your DNS setting. Is the overall status on the WUI page showing a Green Working or a red Broken status.

If you press the Check DNS Servers button do your DNS entries show up as a Green OK?

6

DNS is working. Both google and Quad 9 show OK. One of the first things I checked and just confirmed again.

checkip4.dns.lightningwirelabs.com returns my v4 IP. I assume this is the intent.

I’ve resigned myself that something in the upgrade somehow broke the system. Not a huge deal. I’ll just have to install fresh and use a settings backup.

Thanks for the input.

7

If your doing local name resolution.
You need to use “Edit host” now

8

I’ve seen some posts where that is the case, from what I’ve seen on Blue. Local DNS works fine on Green but not Blue. With Blue, I cannot use IPFIRE for DNS, it just breaks. If I do have to set up in hosts, I’m not doing that. I’ve got over 50 devices on Blue.

9

Local DNS works for all known devices.
Names are known by DNS, if

  • the device introduces itself durig DHCP request
  • if it is defined in ‘Edit Hosts’

The workaround ‘define name in DHCP remark for fixed leases’ isn’t working in CU203 anymore.

The amount of posts about missing name resolution show that there are many devices not giving their name at DHCP request.
You can see this easily if you disable the fixed lease definition. The device gets a dynamic lease. In the DHCP WUI page the dynamic leases table shows the names received.

10

For Core Update 203, if you want DNS resolution to work correctly on the BLUE network, you must explicitly configure the IP address of the BLUE interface as the DNS server in the DHCP settings for that network.

Capture d’écran 2026-08-09 204654
Capture d’écran 2026-08-09 2046541010×643 88.5 KB

Otherwise, clients on the BLUE network may receive an incorrect DNS server (or none at all), resulting in DNS resolution failures.

Edit : With previous releases, it was possible either the GREEN or the BLUE interface address as the DNS server worked for BLUE clients

11

This is how it was configured, alaways. This no longer works, at least not on my install. I must now use an external DNS.

12

I understand this is how it’s meant to work. This is not how it is currently working. Even hosts that properly announce on DHCP will not use local DNS on Blue. Known devices with static leases also cannot use local DNS on Blue. These are all devices verified to send proper hostnames on DHCP request. There are devices that do not, and I have some of those. These though, are not those.

13

BTW, are we talking about DDNS ( a method to supply a name for the IPFire system to the global name resolution ) or about local DNS ( name resolution in the LAN(s) of IPFire) ?

The first adds information to the global name space, the second is restricted to the local name space.
Local DNS is handled by the local name resolver ( knot, since CU203 ) which works on the defined local zones GREEN and BLUE.

14

Can you be more specific about that?
Give examples of DNS requests that are failing.

15

I tried to re-install but the PC would not boot from the ISO so I left it for later. Interestingly, dynamic DNS is now working fine. Changed my IP on No-IP then performed instant update with success. Not sure if this had to do with rebooting the system multiple times which likely forced a filesystem check or what.

So far as Blue DNS the best examples I have are my Pixel phone, laptop and main desktop. All send proper hostnames on DHCP request but DNS fails when Blue DNS is set to IPFIRE 192.168.19.1. Blue is 192.168.19.0/24

16

My DHCP server also hands out the blue0 address for DNS to systems contacting through the wireless network (blue).
There are no problems in name resolution of these devices.

17

It might be an issue with your Wi-Fi access point.
What model is the access point?
Have you tried connecting your PC directly to the BLUE interface?

18

Holy crap I think you got it. It’s a TPLINK EAP770 which works fantastic Technically the issue but for a dumb reason. I have it set for DHCP with static IP in IPFIRE. The device has fallback settings in the event DHCP is not available. Fallback DNS was set to GREEN and for some reason it was using the FALLBACK DNS instead of DHCP supplied DNS when IPFIRE was set to BLUE for DNS. I updated the fallback to BLUE DNS, changed in IPFIRE as well disabled BLUE DHCP and enabled BLUE DHCP. As another measure I disconnected some wireless devices and all appear to have reconnected with internet access and no issues. Thank you!

EDIT:

After several hours allowing for natural lease expiry and renewal, all continues to work flawlessly. Thanks again.