Surely it means that if you use a fixed lease, it automatically uses the name from there. If it is in the hosts file, then that takes precedence over the name from the fixed lease.
That is how it suppose to operate, however, the netbios or client-name is enabled so address reservation turns into an extra A name entry when dhcp enumerates the netbios name. Because the host name already has an ip. However, since the client does not have this as a static entry, it will only get the address that the dhcp request is sent and mapped.
If you look at a different distribution, you will see client-name commented out on purpose or not listed in the options quotient part of the statement. In their DHCP-DNS bridge
The only reason why IPFire is different is because the dhcp is setup for the VPN services which is not really designed to be used for a wifi services that requires a different dhcp setup all together because of the netbios incompatibility with wifi. Which is one of the reasons why that protocal is depreciated. Netbios has unsolvable issues with address reservations.
I think my translator is malfunctioning. 
It does, however, if the dhcp request has a name not already predefined it will map it and the dhcp ip will be given to that name and reservation will be ignored as it assumes the client has registered the ip address in the client.
Its not a bug, its a reason why its not normally configured that way. However, the dhcp query from the client will only get one ip and it will be the last results from the pick from options routine. since C++ options fallows order of operations, its going to assign an ip address to a name not in the lists from the dhcp client query. That is why client-name is commented out or deleted in everyone else’s router’s operating systems.
Either WIFI or VPN needs to get a separate DHCP server instance, but a DHCP server for the VPN might be the correct direction since the rest of the network should have a different dhcp setting so address reservation works without it getting impeded by netbios or client-name.
I don’t use address reservation. I always use static ip addresses when I need it to have the same ip every time it connects. Since this dhcp server will hand out an ip for the netbios name, you have to add the static ip into the interface properties in windows so the client will always have that ip. Or disable netbios, which should have been disabled by default in windows.
The problem isn’t DHCP on either the client or the server, whether Windows, Linux, Android, or…
Nor is it WiFi or VPN.
It’s IPFire’s Local DNS, which registers both names for the same IP address when a client connects by DHCP.
maybe, but you need to disable netbios on windows machines when they are used with IPFIre or deal with this anomily caused by the windows machine.
When I ask Google AI:
“dhcp server hands out ip address to netbios instead of localhost windows”
it responds:
When a DHCP server assigns an IP address to NetBIOS instead of the localhost (127.0.0.1), it’s likely due to a misconfiguration or conflict in your network settings. To fix this, ensure that NetBIOS over TCP/IP is disabled on your DHCP server and client, or configure your DNS server to properly resolve your local hostname.
Here’s a more detailed breakdown:
1. NetBIOS over TCP/IP:
What it is:
NetBIOS over TCP/IP is a legacy protocol that allows computers to communicate using NetBIOS names (like computer names) instead of IP addresses. It was commonly used in older Windows networks but is generally not recommended for modern networks.
Why it’s a problem:
NetBIOS can interfere with DNS resolution, especially for localhost. If NetBIOS is enabled and your DHCP server is assigning an IP address to a NetBIOS name, it can override the correct localhost resolution.
How to disable it:
DHCP Server: Configure your DHCP server to disable NetBIOS. You can usually find this setting within the DHCP scope settings on the DHCP server.
Clients (Windows): On each client computer, you can disable NetBIOS over TCP/IP by following these steps:
- Open Control Panel > Network and Internet > Network Connections.
- Right-click on your network connection and select Properties.
- Select “Internet Protocol Version 4 (TCP/IPv4)” and click Properties.
- Click Advanced.
- Go to the WINS tab.
- Select “Use NetBIOS settings from the DHCP server.” or disable NetBIOS directly.
2. DNS Configuration:
What it is:
DNS (Domain Name System) translates domain names (like your computer name) into IP addresses.
Why it’s important:
DNS is crucial for resolving hostnames, including localhost, on your network. If your DNS server is not properly configured, it might not be able to resolve the correct IP address for localhost, leading to issues.
How to configure DNS:
DHCP Server: Ensure your DHCP server is configured to provide DNS server addresses to your clients.
DNS Server: Configure your DNS server to correctly resolve your local hostname (e.g., “localhost”). You can usually do this by creating a host record (A record) in your DNS zone, pointing your hostname to 127.0.0.1.
3. Troubleshooting:
Check your DHCP server settings:
Verify that your DHCP server is correctly configured to assign IP addresses and DNS servers. Ensure that you have enough available IP addresses in your scope.
Check your network bindings:
If you have multiple network adapters, make sure that the correct adapter is at the top of the bindings list.
Use ipconfig /all:
This command can help you see your current IP configuration, including the DNS servers and NetBIOS settings.
Test with ping:
Use the ping command to test connectivity to localhost (ping 127.0.0.1). If it’s not working, there might be a firewall issue or a problem with your IP configuration.
Review event logs:
Check your DHCP server’s event logs for any errors or warnings related to IP address allocation or DNS configuration.
By carefully reviewing these steps and troubleshooting your network configuration, you should be able to resolve the issue where your DHCP server is handing out IP addresses to NetBIOS instead of localhost.
Let it go…
You need to understand ipfire is not built for windows networking and any windows machine that is added to the ipfire network must conform to standard networking setting and not any outdated windows network settings.
I’ve been using IPCOP and its successor, IPFire, for over 20 years with Windows without any problems.
I’m not sure all IPFire users are all Linux users.
1 Like
Just wondering if the following information can be helpful
Regards
1 Like
Test and give verified answers instead of assuming them or asking Google AI
2 Likes
I just gave you the 3rd party treatment. I know how all of this is configured, and tried to explain it to you how this system is different than a standard router.
And showed you the response I get from AI about it, since you don’t understand the 8 ways I tried to describe the situation and the solution is to disable the netbios in Windows if you want IP reservation to work properly with that machine.
Now you going to have to clean out those extra leases out of the file after disabling netbios.
The default option is incorrect.
NetBIOS over TCP should always be disabled.
So I will raise a DEV ticket in Microsoft even though I hate dealing with them and not interested into fixing their problems. Especially with their outdated networking they supposed to have removed a decade ago.
Thanks for this fascinating discussion, but I had already solved my problem a long time ago.
1 Like
Oh its no problem, if I ever get the opportunity to rewrite that section I will just program it so if the client machine does not get an ip address until it conforms to proper networking practices. Namely, if it has netbios, it doesn’t get an ip.
There is more than one way to force standards.
excellent 
it is a pity one do not find this inside the documentation.
as it seems the few community users here all use !win systems.
however this is a good writeup why ipf
is not able to manage internal dns/dhcp
reliably in standard win environments. 
IMO, there are many Windows systems in IPFire networks.
Most laptops in home networks run with Windows. This is just a fact!
My local networks ( green and blue ) contain exactly 2 Linux systems, IPFire and a print server. All other laptops run Windows. And I have no problems with internal name resolution.
My green and blue network use separate domains.
BTW: Dr AI ( dr_techno ) is silenced till tomorrow. His posts don’t really help, and pretending great knowledge without assistance in development isn’t in the sense of Open Source.
Back to the topic.
If there are deficiencies in unbound-dhcp-bridge, we should this discuss in the development list. Or file a bug in bugzilla.
Core Devs are easier reachable on these channels.
There are multiple ways a device name is published:
- host definition ( IP <—> name ) in file hosts
- name field in DHCP protocol ( not necessary )
- name definition in DHCP server directly
- …
So, it is not trivial the organise a consistent transfer to unbound.
Just let us talk about this!
1 Like
funny imo but a fact … 
despite the fact there can be
crucial different requirements
it could be assumed that most win users
do not even notice the lack of reliability
in ipf as they do not rely on these services.
hence: not reliable 
because of the enormous pressure to the dev
it is clear that this flaw has no high prio.
https://community.ipfire.org/search?q=unbound-dhcp-leases-bridge 
time flies by … 