I use a Wi-Fi access point on my Green network, and my laptop connects to that access point via Wi-Fi.
And when I connect it via cable, it is also on the Green network.
I have another access point on the Blue network with a different subnet and SSID.
Okay, I understand.
Connecting to Green via LAN and Wi-Fi gives you different IP addresses because you’re using different MAC addresses – that’s fine.
Both connections are handled by DHCP IPFire from the Green network; communication seems fine.
Static assignment in DHCP with different names seems to have nothing to do with DNS support.
Try connecting to your PC using the IP address instead of the name.
Of course I can access my PCs via their IP addresses; that’s not the problem.
If you’re reading the title of this post, then the DNS issue is exactly what I’m raising.
It’s essential to note that Unbound itself does not directly support RFC2136. As such, DNS registration is managed behind the scenes by the bridge script using a different method. Activating the DNS Update feature without redirecting updates to a different name server that supports RFC2136 will disable this capability.
I do not believe that RFC 2136 defines which hostname should be registered in the local DNS.
However, the way CU203 handles DNS for the local network is completely different from CU202.
I explained how CU202 works here.
Based on what I observed for CU203 regarding knot-resolver
At startup
1 - It loads the addresses defined in the /etc/hosts and /var/ipfire/main/hosts files into its local cache.
Then
When a host connects via DHCP, it adds its address and client hostname in other lease.db cache DNS and overwrites the address defined in hosts
The value of the REMARK field recorded in dhcp.cgi is ignored.
This bad “hostname - address” record persists in the cache (the cache is retained on disk even after a reboot).
My test:
A Windows PC named “virtual11” has two network cards.
The fixed DHCP lease never expires
The only way I found to free up the address is to force release /usr/sbin/dhcp-lease release ADDRESS=192.168.20.20 HOSTNAME=virtual11 DOMAINNAME=localdomain
And then
I locate the correct address (host)
[root@ipfireTest ~]# nslookup virtual11
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: virtual11.localdomain
Address: 192.168.20.2
[root@ipfireTest ~]# ping virtual11
PING virtual11.localdomain (192.168.20.2) 56(84) bytes of data.
64 bytes from virtual11.localdomain (192.168.20.2): icmp_seq=1 ttl=128 time=0.437 ms
64 bytes from virtual11.localdomain (192.168.20.2): icmp_seq=2 ttl=128 time=0.493 ms
64 bytes from virtual11.localdomain (192.168.20.2): icmp_seq=3 ttl=128 time=0.805 ms
but I can’t run this command every time my PC changes its address !
I know, my explanations are always a bit long, but you have to take the time to read them to fully understand the problem.
Thanks for the idea, but that doesn’t solve the problem; the leases.db database doesn’t update if the hostname already exists, so the address never changes.
@pscar13 , have you looked into the source of dhcp-lease?
I think, the problem is that only conflicts for double addresses are handled ( a commit with a new name for a known address ). Your case is a commit transaction with a new address for a known name.
With your knowledge of sqlite3 it should be easy to check this with an modification to the file.
If my guess is true, don’t hesitate to send a bug to bugzilla.
I noticed that the commit request is rejected when the host already exists.
My recent experiences with Bugzilla have not always been straightforward, and I have sometimes found it difficult to determine whether something should be considered a bug or simply the expected behavior.
From now on, I’ll just share the results of my testing and leave it to the developers to decide whether it warrants opening a bug report.
My setup was a simple Red, Green with no potential for duplicate addresses. Dynamic entries were resolved whereas static addresses were not.
Simply put this is either a regression from CU202 or is the new expected behaviour with the knot-resolver. If the latter to resolve static leases we need to add them to “Edit Hosts”
Like you I was reluctant to call things a bug when I wasn’t sure if it was just expected behaviour.
I have stopped my trial on IPFire due to other reasons so can’t contribute further.
On reflection, I realized that even updating the address for an existing hostname can still be problematic.
For example, many of my IoT devices identify themselves using generic hostnames like wlan0, and several of my cameras simply use camera as their hostname. In these cases, only the most recently connected device appears in the local DNS.
In some situations, I don’t need to access these devices via their hostname, but I do use the hostname to identify them within the local DNS.
For now, the only practical solution seems to be the one suggested by @rjackson: manually copying the static DHCP lease entries into hosts.cgi.
I will wait for the final release to see if this new behavior is retained.
If this change is intentional, it would be helpful to mention it in the release notes or documentation so that users understand this change in local DNS behavior.
This was and is my way of using IPFire since I started using it more than a decade ago.
And, each IP reserved has multiple names associated in hosts - names being generated by the services hosted there (samba, step-ca, cups / print, monit, ups, time), services consumed by some if not all machines (cups and certificate authority are consumed by all machines).
In my case the hosts file is the most important element in address resolution for my network - it allows clients to find the services available in the network.
Name resolution is a n → 1 relation, ideally a surjective relation ( if there is a name for all IPs ), between the sets of names and IPs.
This means, a function f: IP → name can not deliver unambigous results.
The update function initiated by DHCP to supply DNS with a new relation (name,IP) maybe incomplete. DHCP builds up a set of (MAC, IP) relations, the name of a device, identified by MAC, must not be known.
The task of defining a set of names for several services in the local network, is managed best in the host configuration. This information is determined outside the network by the admin, and it is hard if not impossible to resolve with DHCP informations only.
Hope this clarifications bring some light into this topic.
If I understand correctly, these are indeed the intended rules.
However, I previously pointed out that IPFire did not always behave in accordance with them:
With version CU202, depending on how static hosts, fixed DHCP leases, and the “REMARK” field were used, it was possible to end up with either multiple IP addresses for a single hostname or multiple hostnames for a single IP address.
Based on my tests, version CU203 might also lead to incorrect associations between hostnames and IP addresses, depending on the configuration used.
I also believe—based on the start of this discussion—that CU203 alters the behavior of local DNS management.
Thanks again to everyone for taking the time to explain and share this information.
Multiple IPs for the same name is not ‘standard’ behaviour. Usage in the DNS name space does this allow, for load balancing for example. But this construct demands several servers running the same time with the same offer.
Your case is a bit different. The same physical device operates in different sub networks. But the change isn’t handled fully. A device leaving a network regulated by DHCP can release its lease. Afterwards a new request for an IP of the other network can be done.
The ‘bridging SW’ realizes both operations: a request sends a (name, IP) definition to DNS, a release invalidates this association.
In my case, the situation is slightly different.
The same physical device (Laptop) uses two network interfaces (Wi-Fi and Ethernet) on the SAME subnet.
Under Windows, when the Ethernet cable is plugged in, the Wi-Fi connection is disconnected automatically afterwards; there is no manual intervention.
During that transition, both IP addresses may temporarily be associated with the same hostname, which I believe is a valid situation.
I have observed the same behavior with Linux in some situations as well, particularly when DHCP Fixed Leases are used and all IOTs.
Contrary to what I previously wrote, after more thorough testing, migrating fixed DHCP leases to the hosts file does not solve my problem.
I have corrected my posts.
Thanks for your help.
Could you provide more details?
Which version of IPFire?
Are the IP addresses reserved in dhcp.cgi?
Are the hosts defined in hosts.cgi only?
Do all clients use the IPFire DNS to resolve the name of each service?
Have you tested CU203 with this configuration?
I wonder whether switching it off will affect the results of your tests.