DNS & DHCP, trouble

Networking DNS
1

After many years I finally switched from old (reliable, well tuned and patched) IPcop to IPfire. My IPcop box was probably the oldest computer running IPcop 1.4, the main reason was that modern Linux distributions removed support for TLS 1.0 that is necessary to login to admin interface of IPcop 1.4… I already tried to switch from IPcop several times in the past but I always returned back.

I run IPfire for a week and I see some unknown issue with DHCP and local DNS. Hosts those receive dynamic IP address from DHCP server can be found with “host” command, these are known to local DNS server (IPfire). Host (a server) that was assigned fixed IP address in DHCP server is not known by DNS server. This is not good.

My local domain is “home”, it is only for LAN, IPfire is internet gateway, local LAN has addresses from private range (192.168.x.x/24), IPfire has RED, GREEN and BLUE interfaces, BLUE is WiFi card is PCI, it is based on Atheros chipset (2.4G only). IPfire runs on Fujitsu FUTRO S900, thin client PC.

Description of the issue:

IPfire gateway has GREEN IP address 192.168.222.1 and BLUE IP address 192.168.232.1. OS is IPFire 2.27 (x86_64) - Core-Update 174

Desktop PC, mint.home, IP address assigned by DHCP from dynamic address pool (192.168.222.100-192.168.222.250), no fixed lease, it works OK:

# host mint 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

mint.home has address 192.168.222.121

# host  192.168.222.121 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

121.222.168.192.in-addr.arpa domain name pointer mint.home.

Server server.home has IP address assigned by DHCP but it is fixed lease, it doesn’t work. It looks like DHCP server assigned address but it is not visible in DNS; the issue:

# host server.home 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

Host server.home not found: 3(NXDOMAIN)

# host 192.168.222.11 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

11.222.168.192.in-addr.arpa domain name pointer server.home.

# ping -c1 192.168.222.11
PING 192.168.222.11 (192.168.222.11) 56(84) bytes of data.
64 bytes from 192.168.222.11: icmp_seq=1 ttl=64 time=0.123 ms

--- 192.168.222.11 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.123/0.123/0.123/0.000 ms

DNS shows expired entry

Other issue is that DNS shows leased entry that already expired. There is another server on my LAN, nas.home is FreeNAS and FreeBSD systems has problem when IP address is not assigned by DHCP server, they do not retry. At the moment FreeNAS runs but it has no IP address (but I know it is up an running because it hosts several virtual machines with Linux and those are alive).

I changed nas.home configuration from dynamic lease to fixed lease. Dynamic lease (192.168.222.135) expired a day ago but it is still reported by DNS. nas.home lost IP address when I switched from IPcop to IPfire, DHCP server was down for several hours. Fixed lease is reported by DNS too, I am not sure why it works in this case, maybe it is related to “expired dynamic lease”. The issue is that address 192.168.222.135 should not be returned by DNS server:

# host nas.home 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

nas.home has address 192.168.222.22
nas.home has address 192.168.222.135

# host 192.168.222.22 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

22.222.168.192.in-addr.arpa domain name pointer nas.home.

# host 192.168.222.135 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

135.222.168.192.in-addr.arpa domain name pointer nas.home.

nas.home is “not visible” (It has no IP address, a bug/feature of FreeBSD):

# ping -c1 192.168.222.22
PING 192.168.222.22 (192.168.222.22) 56(84) bytes of data.
From 192.168.222.11 icmp_seq=1 Destination Host Unreachable

--- 192.168.222.22 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

# ping -c1 192.168.222.135
PING 192.168.222.135 (192.168.222.135) 56(84) bytes of data.
From 192.168.222.11 icmp_seq=1 Destination Host Unreachable

--- 192.168.222.135 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
1 Like
2

In the web user interface of IPFire, you can navigate to “/network/DHCP Server” to control two settings. The first setting determines the range for dynamically assigned addresses. The second setting allows you to promote a dynamic entry to a static one, meaning that the DHCP server will consistently assign the same IP to the designated MAC address. Please note that you can edit this IP address and it’s advised that you change it to a value outside the dynamic range you’ve set previously. For instance, if your range for the green network is 192.168.1.50 to 192.168.1.100, and you promote a host with a dynamic IP of 192.168.1.51 to static, you should change this to, say, 192.168.1.10. This guideline applies to all addresses—both fixed and dynamic—that are managed by the DHCP server.

Now, let’s consider the “static” addresses that are not handled by the DHCP server—those that originate from clients requesting a specific IP. In order for DNS to resolve these addresses, you need to enter the IP and the name in “/network/hosts.”

This is the basis of my explanation. So now, my question to you is this: Have you configured your network according to these principles?

EDIT: welcome to our community!

1 Like
3

I followed instruction, I believe my configuration is correct. I changed “dynamic IP address assignments” to static, I changed static IP address to be out of dynamic range. My hosts list was empty.

I added server to hosts, address 192.168.222.11. I tested DNS resolution from client and it was still not working, command host server.home 192.168.222.1 returned error. So I deleted entry in hosts, it is empty again. And miracle happened! I can resolve server and I can resolve nas…

Reply for nas now shows only static address, expired entry is not in the reply anymore, this is good. hosts list is empty. DNS for “home” domain now works as expected but I see a ghost, something is not correct and it randomly creates issue…

hosts is empty, it was edited today:

[root@ipfire ~]# date; ll /var/ipfire/main/hosts 
Sat Jun  3 02:01:29 PM CEST 2023
-rw-r--r-- 1 nobody nobody 0 Jun  3 13:37 /var/ipfire/main/hosts

No changes to DHCP today:

[root@ipfire ~]# ll -tr /var/ipfire/dhcp
total 16
-rw-r--r-- 1 nobody nobody    0 Oct 18  2022 dhcpd.conf.local
-rw-r--r-- 1 nobody nobody 2504 Oct 18  2022 advoptions-list
-rw-r--r-- 1 nobody nobody    0 Oct 18  2022 advoptions
-rw-r--r-- 1 nobody nobody  886 Jun  2 12:27 settings
-rw-r--r-- 1 nobody nobody   89 Jun  2 12:43 fixleases
-rw-r--r-- 1 nobody nobody    0 Jun  2 12:43 enable_green
-rw-r--r-- 1 nobody nobody    0 Jun  2 12:43 enable_blue
-rw-r--r-- 1 nobody nobody  959 Jun  2 12:43 dhcpd.conf

No changes to DNS:

[root@ipfire ~]# ll -tr /var/ipfire/dns/
total 8
-rw-r--r-- 1 nobody nobody 191 May 28 21:54 servers
-rw-r--r-- 1 nobody nobody 106 May 28 21:55 settings

or DDNS:

[root@ipfire ~]# ll -tr /var/ipfire/ddns/
total 12
-rw-r--r-- 1 nobody nobody    0 Oct 18  2022 settings
-rw-r--r-- 1 nobody nobody    0 Oct 18  2022 ipcache
-rw-r--r-- 1 root   root   3486 Oct 18  2022 ddns.conf.sample
-rw-r--r-- 1 nobody nobody   61 May 28 21:47 config
-rw-r--r-- 1 nobody nobody  127 May 28 21:49 ddns.conf

But changes are in unbound configuration:

[root@ipfire ~]# ll -tr /etc/unbound/
total 44
-rw-r--r-- 1 root root  1463 Dec 27 14:09 unbound.conf
drwxr-xr-x 2 root root  4096 Dec 27 14:09 local.d
-rw-r--r-- 1 root root  3312 Dec 27 14:09 root.hints
-rw-r--r-- 1 root root 13026 Dec 27 14:09 icannbundle.pem
-rw-r--r-- 1 root root   233 May 28 20:14 tuning.conf
-rw-r--r-- 1 root root   278 Jun  3 13:37 forward.conf
-rw-r--r-- 1 root root   266 Jun  3 13:37 hosts.conf
-rw-r--r-- 1 root root  2938 Jun  3 13:37 dhcp-leases.conf

The interesting file is dhcp-leases.conf, unfortunately I do not have version from the time when DNS was not working as expected… :frowning:

There is one more related file to DHCP, it is /var/state/dhcp/dhcpd.leases, it track dynamic IP leases.

Most modern DHCP client report hostname to DHCP server, and I prefer to not entry hostnames to hosts for such clients; I am lazy and I prefer auto configuration of my network… :wink:

1 Like
4

When hosts are edited, unbound configuration is rebuild, details in file /srv/web/ipfire/cgi-bin/hosts.cgi
When dhcp is edited, unbound configuration is not rebuild and I assume this is source of trouble I observed… Script /srv/web/ipfire/cgi-bin/dhcp.cgi is troublemaker, it should rebuild unbound configuration when static entry (fixed lease) is added, modified or removed.

I still see some issue. I added entry for server.home to hosts list but the issue was not fixed, it was fixed when I deleted server.home from hosts list… Maybe that even hosts.cgi is not perfect…

2 Likes
5

What happens if you follow this “hack” procedure?

EDIT: a useful tip: just for an easy visual access of the entire table of clients, you can have all your network IPs, including the hosts fixed IP, in the “Current Fixed leases” of the DHCP page of the WUI, just do not activate the “enabled” checkbox for the hosts entries. This can be a way to have everything documented in one place. Unfortunately I do not remember to whom should I give credit to for this tip. I think it was @bonnietwin but I am not 100% sure.

1 Like
6

did you activated “Enable DNS Update (RFC2136):” checkbox? This checkbox will make sure that any change in the DHCP allocated IP addresses will be reflected in the DNS server by having the DHCP client communicating to unbound the change. However, probably to have this working you need to configure the key name, shared secret, and HMAC-MD5 algorithm settings that match those configured in IPFire’s DNS server with the ones in the dhcp client. This part is not documented in the wiki, unfortunately.

This is my guess: you enter these values in the WUI and you will set unbound. Next, on the clients side using Linux you will need to edit /etc/dhcp/dhclient.conf (or equivalent):

key keyname {
    algorithm hmac-md5;
    secret "base64encodedsecret==";
};

zone example.com. {
    primary dns.example.com;
    key keyname;
};

In this example, “keyname” is the name of your key, “base64encodedsecret==” is the corresponding Base64-encoded secret, “dns.example.com” is the IP address of your DNS server (replace with your IPFire’s IP), and “example.com” is the domain you’re updating. To create a secure random string and encode it in base64 this is how it can be done :

openssl rand -base64 32

where 32 is the number or random bytes will be uesed to generate the string.

I did not understand what was exactly the nature of the first problem you reported that should require a rebuild of unbound entries when DHCP changes. If it is an automatic DNS entry based on the hostname, this checkbox with the required settings will allow the client to send a signed message to the DNS server and this should take care of updating the DNS entries when the IP is served to the client by the DHCP server.

Please let me know if this is what you were trying to achieve and if it works, so I can add this part to the DHCP documentation.

7

Checkbox "Enable DNS update (RFC2136) is not active in my setup. I will try to experiment with it…

It is more tricky than I expected yesterday. There is one more script in this game, /usr/sbin/unbound-dhcp-leases-bridge. Program /usr/local/bin/rebuildhosts that is called from hosts.cgi just updates /etc/hosts and it is not really important for this issue; more imporatnt is that unbound receives reload command. rebuildhosts is a C code, binary blog on the gateway, it will be nice to rewrite such tools to PERL, it will be easier to troubleshoot/maintain (no compilation required, readable code on the gateway).

On my IPcop install, I updated list of host with fixed lease but my experience is that after some time it doesn’t match reality, so I try to eliminate human actions from this process… :wink:

1 Like
8

Two notes. First, DHCP GUI, static leases has different column order than dynamic leases, MAC address and IP address. Could be this united? I prefer order MAC address, IP address, like is used by dynamic updates but that is just my point of view.

Second. Another prove that something is not working correctly. I have host test1, it has dynamic IP address from DHCP server, 192.168.222.123. When I try host test1 192.168.222.1 it works, no problem at all.

I add entry to host list, entry that assign IP address 192.168.222.123 to hostname test1. And this is a problem, I cannot resolve test1 anymore, I receive error Host test1 not found: 3(NXDOMAIN). When I disable entry in the host list, I can resolve test1. Once I enable entry, I get an error; there are no records with test1 in file /etc/unbound/dhcp-leases.conf. 100% repeatable. IPfire cannot solve conflict when IP address is defined in host list and it is assigned from DHCP server; not good idea but why not… When I define different hostname in host for IP address 192.168.222.123, then there is no issue, it works OK.

Script /usr/sbin/unbound-dhcp-leases-bridge removes dynamic leases when these are defines in hosts:

                # Skip any leases that also are a static host
                leases = [l for l in leases if not l.fqdn in self.hosts]

I assume that hosts should have higher priority then information from clients. Maybe this is just a bug, that DHCP leases should be handled first and after that merged with information from hosts, so these actions should be in opposite order and static hosts should be processed unconditionally:

                        # Update hosts (if needed)
                        if update_hosts:
                                self.hosts = self.read_static_hosts()

                        # Update leases (if needed)
                        if update_leases:
                                self.update_dhcp_leases()

!!! This is a bad bug. It applies for my server.home box, I started this topic with that issue. When I define and enable server.home in hosts list, I receive error Host server not found: 3(NXDOMAIN). server.home is defined with fixed DHCP lease. When I disable server.home at hosts list, I resolve server.home to 192.168.222.11. Troublemaker is python script unbound-dhcp-leases-bridge…

Demo, server.home entry is DISABLED in host list, I can resolve server.home:

[root@ipfire bin]# grep server /var/ipfire/main/hosts 
,192.168.222.11,server,home,on

[root@ipfire bin]# grep server /etc/hosts 

[root@ipfire bin]# grep server /var/ipfire/dhcp/fixleases 
00:07:e9:17:41:aa,192.168.222.11,on,,,,server

[root@ipfire bin]# grep server /var/state/dhcp/dhcpd.leases

[root@ipfire bin]# grep server /etc/unbound/dhcp-leases.conf 
local-data: "server.home 60 IN A 192.168.222.11"
local-data: "11.222.168.192.in-addr.arpa 60 IN PTR server.home"

[root@ipfire bin]# host server 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

server.home has address 192.168.222.11

[root@ipfire bin]# host 192.168.222.11 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

11.222.168.192.in-addr.arpa domain name pointer server.home.

server.home entry is ENABLED in host list, I cannot resolve server.home, the bug:

[root@ipfire bin]# grep server /var/ipfire/main/hosts 
on,192.168.222.11,server,home,on

[root@ipfire bin]# grep server /etc/hosts 

[root@ipfire bin]# grep server /var/ipfire/dhcp/fixleases 
00:07:e9:17:41:aa,192.168.222.11,on,,,,server

[root@ipfire bin]# grep server /var/state/dhcp/dhcpd.leases

[root@ipfire bin]# grep server /etc/unbound/dhcp-leases.conf
 
[root@ipfire bin]# host server 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

Host server not found: 3(NXDOMAIN)

[root@ipfire bin]# host 192.168.222.11 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

Host 11.222.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

I DISABLEd server.home fixed DHCP lease entry when server.home was enabled in hosts list but I still received NXDOMAIN error. But when I DISABLED and ENABLED server.home in hosts list, I received valid reply from DNS server. This is interested observation and should be checked, why.

1 Like
9

In previous post I noted that I would like to see unified way how to display leases in DHCP server page. I was checking how difficult is such fix and it is “easy”. I checked some screenshots of IPcop and I see that even old IPcop shoes dynamic and fixed leases in different way (IPcop 1.4.1) screenshot, maybe even Smoothwall did it in such way, so this “chaos” was not introduced by IPfire, it comes from the past…

IPcop 2.0 already fixed this issue and has columns in similar order. IPcop version 1.4.21 that I was running for years had columns in correct order too…

Other interesting point is that dynamic leases are handled in script /var/ipfire/header.pl. I expected that those function be in /srv/web/ipfire/cgi-bin/dhcp.cgi. Anyway, to swap order of columns for MAC address and IP address in dynamic leases is easy, this is a patch, easy to try:

[root@ipfire ipfire]# diff -u /var/ipfire/header0.pl /var/ipfire/header.pl 
--- /var/ipfire/header0.pl	2023-04-17 17:31:16.299182757 +0200
+++ /var/ipfire/header.pl	2023-06-07 02:25:42.073631986 +0200
@@ -410,7 +410,7 @@
 
 sub CheckSortOrder {
 #Sorting of allocated leases
-    if ($ENV{'QUERY_STRING'} =~ /^IPADDR|^ETHER|^HOSTNAME|^ENDTIME/ ) {
+    if ($ENV{'QUERY_STRING'} =~ /^ETHER|^IPADDR|^HOSTNAME|^ENDTIME/ ) {
         my $newsort=$ENV{'QUERY_STRING'};
         &General::readhash("${swroot}/dhcp/settings", \%dhcpsettings);
         $act=$dhcpsettings{'SORT_LEASELIST'};
@@ -433,8 +433,8 @@
     print <<END
 <table width='100%' class='tbl'>
 <tr>
-<th width='25%' align='center'><a href='$ENV{'SCRIPT_NAME'}?IPADDR'><b>$Lang::tr{'ip address'}</b></a></th>
 <th width='25%' align='center'><a href='$ENV{'SCRIPT_NAME'}?ETHER'><b>$Lang::tr{'mac address'}</b></a></th>
+<th width='25%' align='center'><a href='$ENV{'SCRIPT_NAME'}?IPADDR'><b>$Lang::tr{'ip address'}</b></a></th>
 <th width='20%' align='center'><a href='$ENV{'SCRIPT_NAME'}?HOSTNAME'><b>$Lang::tr{'hostname'}</b></a></th>
 <th width='25%' align='center'><a href='$ENV{'SCRIPT_NAME'}?ENDTIME'><b>$Lang::tr{'lease expires'} (local time d/m/y)</b></a></th>
 <th width='5%' align='center'><b>$Lang::tr{'dhcp make fixed lease'}</b></th>
@@ -515,16 +515,16 @@
 		
 		if($entries{$key}->{expired}) {
 			print <<END
-<td align='center' $col><input type='hidden' name='FIX_ADDR' value='$entries{$key}->{IPADDR}' /><strike><i>$entries{$key}->{IPADDR}</i></strike></td>
 <td align='center' $col><input type='hidden' name='FIX_MAC' value='$entries{$key}->{ETHER}' /><strike><i>$entries{$key}->{ETHER}</i></strike></td>
+<td align='center' $col><input type='hidden' name='FIX_ADDR' value='$entries{$key}->{IPADDR}' /><strike><i>$entries{$key}->{IPADDR}</i></strike></td>
 <td align='center' $col><input type='hidden' name='FIX_REMARK' value='$hostname' /><strike><i>$hostname_print<i><strike></td>
 <td align='center' $col><input type='hidden' name='FIX_ENABLED' value='on' /><strike><i>$entries{$key}->{endtime_print}</i></strike></td>
 END
 ;
 		} else {
 			print <<END
-<td align='center' $col><input type='hidden' name='FIX_ADDR' value='$entries{$key}->{IPADDR}' />$entries{$key}->{IPADDR}</td>
 <td align='center' $col><input type='hidden' name='FIX_MAC' value='$entries{$key}->{ETHER}' />$entries{$key}->{ETHER}</td>
+<td align='center' $col><input type='hidden' name='FIX_ADDR' value='$entries{$key}->{IPADDR}' />$entries{$key}->{IPADDR}</td>
 <td align='center' $col><input type='hidden' name='FIX_REMARK' value='$hostname' />$hostname_print</td>
 <td align='center' $col><input type='hidden' name='FIX_ENABLED' value='on' />$entries{$key}->{endtime_print}</td>
 END

Better patch will move code related to dynamic leases from header.pl to dhcp.cgi…

10

I have know idea how this would look in the WUI.
But you can submit a patch.
If this makes it better in some way.

11

@pslpsl , for exchange of columns it is sufficient to change the lines 433,8 ff. The patch in lines 410,7 is identical in both versions ( the ‘codewords’ match the Fano condition ).

12

I know, that the first change is just regular expression. Whatever, I am not programmer anymore and I have learnt that most experienced programmers produce better patches than I do… :wink: That patch was just a “feasibility study”… From my point of view, more changes are required, to cleanup code, to move it from header.pl to dhcp.cgi… The most difficult part on my patch was to find where is the magic that prints dynamic leases… :wink:

13

I know, there is a lot of cleaning up of code to do. But the implemented solution is effective. :wink:
Regarding your initial problem. As stated in wiki, you can define a host name with the fixed leases declaration ( remark section ). I didn’t check the actual source, but looking up some entries of my fixed leases list shows the mechanism works.

14

IPfire 2.27-x86_64, level 175

I still have this issue and I do not understand it. When I enable “server.home” in “hosts”, than I cannot resolve it. But I have found that records are in /etc/unbound/hosts.conf but unbound doesn’t see them. I have found that when I force unbound to reload configuration with killall -HUP unbound, then I can resolve server.home. I can see it in these commands too:

“server.home” entry was just enabled in hosts, but it is not in unbound local data:

[root@ipfire unbound]# grep server /var/ipfire/main/hosts 
on,192.168.222.11,x-server,home,on
on,192.168.222.11,server,home,on

[root@ipfire unbound]# host server.home
Host server.home not found: 3(NXDOMAIN)

[root@ipfire unbound]# host 192.168.222.11
Host 11.222.168.192.in-addr.arpa. not found: 3(NXDOMAIN)

[root@ipfire unbound]# grep server /etc/unbound/hosts.conf 
local-data: "x-server.home 60 IN A 192.168.222.11"
local-data: "11.222.168.192.in-addr.arpa 60 IN PTR x-server.home"
local-data: "server.home 60 IN A 192.168.222.11"
local-data: "11.222.168.192.in-addr.arpa 60 IN PTR server.home"

[root@ipfire unbound]# unbound-control list_local_data | grep server.home
x-server.home.	60	IN	A	192.168.222.11

I ask unbound to reload data and issue is fixed:

[root@ipfire unbound]# unbound-control reload
ok

[root@ipfire unbound]# host server.home
server.home has address 192.168.222.11

[root@ipfire unbound]# host 192.168.222.11
11.222.168.192.in-addr.arpa domain name pointer x-server.home.
11.222.168.192.in-addr.arpa domain name pointer server.home.

[root@ipfire unbound]# grep server /etc/unbound/hosts.conf 
local-data: "x-server.home 60 IN A 192.168.222.11"
local-data: "11.222.168.192.in-addr.arpa 60 IN PTR x-server.home"
local-data: "server.home 60 IN A 192.168.222.11"
local-data: "11.222.168.192.in-addr.arpa 60 IN PTR server.home"

[root@ipfire unbound]# unbound-control list_local_data | grep server.home
11.222.168.192.in-addr.arpa.	60	IN	PTR	x-server.home.
11.222.168.192.in-addr.arpa.	60	IN	PTR	server.home.
server.home.	60	IN	A	192.168.222.11
x-server.home.	60	IN	A	192.168.222.11

I think that source of my trouble is /srv/web/ipfire/cgi-bin/hosts.cgi or /etc/init.d/unbound but I cannot see it… :frowning:

Another interesting observation is that I do not need to reload unbound from CLI. I can enable or disable any entry in “hosts”. That entry could be in trouble (when it was enabled and it had hostname in dhcp) but all other entries will be ok. I can replicate it easily but I just cannot explain it…

UPDATE. Troublemaker is /usr/sbin/unbound-dhcp-leases-bridge. There is statement time.sleep(5) in the script. When I change the sleep value from 5 to 50, I see that removal of server.home from unbound local data is delayed. I believe this is an evidence what script clears local data from unbound…

15

Other issue with script /usr/sbin/unbound-dhcp-leases-bridge is that logging doesn’t work. It looks like script has good support for logging and debugging but I cannot find those messages in any log file, so I assume that logging is not working :frowning:

UPDATE, parameter -vv to /usr/sbin/unbound-dhcp-leases-bridge activates logging

I can see that when I enable host “server.host”, it is removed from DNS:

...
Removing records for server.home
Removing records for 11.222.168.192.in-addr.arpa
Wakeup of main loop

And when I disable “server.home”, it is added to DNS:

...
Adding new record server.home 60 IN A 192.168.222.11
Adding new record 11.222.168.192.in-addr.arpa 60 IN PTR server.home
Wakeup of main loop
1 Like
16

My ipfire gateway has name ipfire.home. I use this hostname in my LAN to access my gateway, until today. I connected new box to my LAN, name was “ipfire” and it was configured over DHCP (it was a test box, I upgraded it from core 174 to 176). Once that box was upgraded, I switched it off. I found I cannot access my gateway with “ipfire.home”, I assume that my test box “stole” DNS name for main ipfire and once the entry expired, “ipfire.home” was removed from the DNS. I assume that once I will restart the DNS server or reboot my gateway, this will be fixed. I just want to highlight how easy it is to kidnap hostname of gateway in LAN, just another issue with DHCP/DNS…

DEMO

My IPfire gateway has IP address 192.168.222.1 and hostname is ipfire.home. I connected test gateway with the same hostname to GREEN LAN, It received IP address 192.168.222.216 on WAN interface. I can see this:

$ host ipfire.home
ipfire.home has address 192.168.222.1
ipfire.home has address 192.168.222.216

$ host 192.168.222.1
1.222.168.192.in-addr.arpa domain name pointer ipfire.home.

$ host 192.168.222.216
216.222.168.192.in-addr.arpa domain name pointer ipfire.home.

The issue is, client in LAN can easily hijack hostname of the gateway, it is DoS attack… This should not be possible because IPfire gateway knows it own hostname and should detect collision with client hostname and not allow this.

When I switch off the test ipfire, I cannot resolve hostname ipfire anymore:

$ host ipfire.home
Host ipfire.home not found: 3(NXDOMAIN)

$ host 192.168.222.1
1.222.168.192.in-addr.arpa domain name pointer ipfire.home.

Reload unbound at the gateway, issue is fixed:

[root@ipfire ~]# unboundctrl reload

$ host ipfire.home
ipfire.home has address 192.168.222.1

$ host 192.168.222.1
1.222.168.192.in-addr.arpa domain name pointer ipfire.home.

The issue is fixed when gateway is rebooted but can be triggered again, I just has to start test ipfire that will hijack hostname again…

1 Like
17

Question:
Would this happen too, if you use ipfire.localdomain insted of ipfire.home ?

BR
Trash

18

I tried to replicate (with core 176 running at RPI3) but in this case I cannot trigger the issue. When rpifire.localdomain is the main gateway with IPfire and I connect client with hostname rpifire.localdomain, this client doesn’t receive DNS record, only IP address is assigned. I test on BLUE interface. BLUE interface is hostapd connected to USB WiFi dongle (RT5370, driver rt2800usb).

UPDATE: I missed something, I can replicate the issue even on BLUE interface (device with IP address 192.168.112.100 is another RPI running Raspbian with hostname rpifire.localdomain; attack was successful…):

$ host rpifire.localdomain 192.168.111.1
Using domain server:
Name: 192.168.111.1
Address: 192.168.111.1#53
Aliases: 

rpifire.localdomain has address 192.168.111.1
rpifire.localdomain has address 192.168.112.100

I can replicate the issue on GREEN interface…

$ host rpifire 192.168.111.1
Using domain server:
Name: 192.168.111.1
Address: 192.168.111.1#53
Aliases: 

rpifire.localdomain has address 192.168.111.101
rpifire.localdomain has address 192.168.111.1

Device with IP address 192.168.111.101 is RPI3 running Raspbian and hostname was changed from “raspberrypi” to “rpifire”, to simulate the “attack”.

I shutdowned device with IP address 192.168.111.101 and after some time (1 or 2 hours), DHCP lease expired and “rpifire” hostname was removed from DNS:

$ host rpifire 192.168.111.1
Using domain server:
Name: 192.168.111.1
Address: 192.168.111.1#53
Aliases: 

Host rpifire not found: 3(NXDOMAIN)

$ host rpifire.localdomain 192.168.111.1
Using domain server:
Name: 192.168.111.1
Address: 192.168.111.1#53
Aliases: 

Host rpifire.localdomain not found: 3(NXDOMAIN)
19

@pslpsl
By using ipfire.localdomain at your main IPFire, you cannot trigger the issue. Either when the hijacker is further set to ipfire.home … And/or also set to ipfire.localdomain .
Right?

BR
Trash

20

I understand what you are saying and I find it to be really problematic. I can relate to the situation you described in a way, but from the point of view of my knowledge, I look for other ways to solve the problems I come across. What you described above coincides with me at the point where the unbound dhcp.hosts file was not updated when I changed the name of my computer (endpoint, not the ipfire computer), in a step prior to the chronological point prior to the reinstallation of ipfire on the same machine. Strangely enough, even with the host.conf file in the unbound folder unreconfigured, I had normal access to the Internet I mean by this: my computer endpoint name first was A then I changed to B - unbound here had A and kept A after change. But with me, everything in the field of information technology has to be very assertive. For example, if I ask A about B, I expect A to answer me about B and not about something else. Meanwhile before this I was also noticing the constant changes in the gateway names between my modem/router and the ipfirewall, sometimes it assumed the name of the IPS, sometimes the domain of the ipfire (for example, ipfire.nnb), but as I sometimes switched between bridge, dmz, and DHCP modes of the modem/router, I finally considered these definitions as normal. It got worse was when I started using WIO. With the use of wio the gateways did not update and even with a disconnected status, the internet remained, this including changing the gateway*1, keeping the same IP and had 2 active gateways! Ok I thought I have a gateway virus or someone is listening to the gateway (MITM). After concluding that I needed to find a solution to the gateway problem, Suricata (IPS) also detected a network trojan malware, surely used and without false positives by attackers. Well, at this point and after some reflections I considered the connection of my ISP old and complained. I have recently been using fiber optics, a much more recent technology and whose copper cables do not emit radio frequency debris through the building and where they pass. This included a router that was difficult to configure and only gave access via Ethernet and for very basic settings! In addition, if we consider the advances in network security, a SIEM connected to the router with a trojan easily accesses the ipfire and the LAN structure. Now with a superior network technology being served by my ISP, the issue of unbound arises again, but namely at the level of DHCP and updating of zones. But let’s go by parts. 1 To be or not to be a gateway trojan virus? In particular, I confirm that I did not reinstall ipfire or the OS on the terminals after changing the ISP technology. Then this could have stayed on standby until it found me! What is certain is that today it did still changed the IP, automatically, from example 192.168.1.2 to 192.168.1.66!!! without me instructing to do it. That was in DHCP to another, in addition to a permanent connection to cloudflare. Had to diasable here the webproxie and dhcp, beside blocking *.clouflare.net and .com at the DNS level I know that my antivirus connects to cloudflare, openai also connects to cloudflare, it will probably also be able to host unknown SIEMS and use the servers to remotely access DNS information for example. Now I ask why the unbound.config file at the end where it says remote control: enabled is not disabled, where it says to use TLS certificate, what used to say yes now says no and why the threadshold for DNS poisoning is set to 1000000 shouldn’t this value be 3 or 5? Is it now a bug? Or is some unknown trojanzite messing with the gateways? Unfortunately after this, my Ipaddress blocklist stopped updating as well, as well as all outgoingforward connections (RED1) were no longer logged (monitored yes). I think it’s really the difficulty in updating files. Not because it’s a bug but because it’s a viral activity. Noticed too that the rnpc (initial throwdice entropy checker) was malfunctioning unless it released static electricity after every restart in the morning when turning on the computers. Well keeping walking as for the moment just want to believe it’s the RED1 and ipadress blocks not working and logging , but I am changing ipfire domain name to my old nnb.ipfire, as you noticed in you last post and wait to see what didn’t update inside ipfire.
Feel free to share your thoughts, if recognize somewhere in the between of this?
Regards
G70P

PS. Keeping in mind that at least with ipfire we can see what’s happening inside the router and can take actions. a closed one is impossible and we have to play along or make it a legacy device.
*1 I used to do testing change of gateways at the modem/router ISP level. If I was using 100.64.0.1 (10) as a modem gateway and change it to eg. 100.0.0.1 (8) the wio showed 2 active gateways on the same IP and didn’t close even after refreshes, reboots, shutdowns.