Name allias cannot be defined

[pslpsl (Petr Slansky)]

I just realized that I would like to define alias for device names but I cannot do that with IPfire. An item to a wishlist. I think “host names” list should have an option to define alias; current version only allows to map IP address to hostname. (records of type A and PTR but no CNAME or AAAA record). Another nice to have feature will be “remark” field in host list, to add extra information or to explain the entry. I can add comments to /etc/hosts but I cannot have comments in “hosts list” (hosts.cgi)…

I have several Android devices on my network on these identify like “android-4b5f82982c6b9b18”. Similaris valid for Amazon devices, those identify as “amazon-123beef768”. I would like to define alias for Android device, something like CNAME in DNS, to map “android-4b5f82982c6b9b18” to “boss-tablet”, etc. My devices use DHCP to receive IP address.

A workaround could be that I will assign fixed IP lease to each of my Android devices and then use “hosts” to define new hostname. But I have two networks, BLUE and GREEN and devices can switch between these networks (another AP is connected to GREEN network). So static assignment will not work well. I have to create two fix leases for each device (GREEN and BLUE) and I am not sure if DHCP server in IPfire is smart enough to assign correct IP address to device in such case; I have not tried this experiment…

I just think I have some trojan proxyware in my network and I try to find it. I found that IPfire doesn’t offer me real help… Other weak point is “active connection statistics”, I cannot filter by IP address/device, I cannot see DNS names (IP->DNS), all I have to do all that manually. I cannot see what DNS requests are served by IPfire (that could help me to define webfilter blacklist)…

[cfusco]

@pslpsl

A workaround could be that I will assign fixed IP lease to each of my Android devices and then use “hosts” to define new hostname. But I have two networks,

This is a workaround I compiled with ChatGPT help that could potentially address your issue. It involves assigning a fixed IP lease to each device, and then using Unbound’s “local.d” configuration to define a new hostname. Although I must note that I haven’t had a chance to test this solution yet, it theoretically should work. I’d appreciate it if you could share your experience if you decide to try it.

chatGPT guide

This guide assumes that you’re already assigning static IP addresses to specific devices using DHCP on IPFire.

1. Identify the IP and MAC addresses of the devices.

   You need to know the IP address and MAC address of each device you want to assign a custom name. You can usually find this information in the DHCP leases section of the IPFire web interface.

2. Create a new configuration file for each device.

   Use SSH or another method to log in to your IPFire box and navigate to the /etc/unbound/local.d/ directory. Create a new configuration file for each device using a format like this:

   nano /etc/unbound/local.d/device1.conf
   

   Replace “device1” with the name of the device. You can use the MAC address or another unique identifier.

3. Add the custom name to the configuration file.

   In the configuration file, add a static local-zone and local-data record for your hostname, like this:

   local-zone: "device1.mylocalnetwork.local." static
   local-data: "device1.mylocalnetwork.local. IN A 192.168.0.100"
   

   Replace “device1.mylocalnetwork.local” with the custom name you want to assign to the device, and “192.168.0.100” with the static IP address that the DHCP server is assigning to the device.

4. Save and close the file.

   After you’ve entered the custom name and IP address, save and close the file.

5. Repeat the process for each device.

   Create a separate configuration file for each device you want to assign a custom name.

6. Restart the Unbound service.

   After you’ve created configuration files for all the devices, restart the Unbound service to apply the changes. Use the following command to do this:

   /etc/init.d/unbound restart
   

Now, Unbound should resolve the custom names to the IP addresses of the devices. To test this, you can use the dig command from another machine in your network, replacing “device1.mylocalnetwork.local” with one of the custom names you assigned:

dig @<IPFire IP> device1.mylocalnetwork.local

This should return the static IP address of the device if everything is set up correctly.

my comment

This process could be scripted by parsing a configuration files containing a MAC address name pair. I asked again chatGPT to write a bash script. Be very careful, if you decide to test it. I do not see anything wrong in the code, but about 50% of the time the code provided needs some trouble shooting.

To address the Blue/green issue, I would simply create two entries in the unbound configuration files adding to the name device1 the suffix -blue and -green with their corresponding IPs. In this case, you need to modify the script accordingly.

scripting the procedure, by ChatGPT

Yes, this procedure can be scripted with a bash script. Below is an example of how you might write this script. Please note that this is a basic example and may need to be customized to fit your specific environment and use case.

This script assumes that:

1. DHCP reservations are configured in the /etc/dhcp/dhcpd.conf file in the format host device-name { hardware ethernet aa:bb:cc:dd:ee:ff; fixed-address 192.168.1.100; }.

2. A file exists at /path/to/names.txt with a mapping of MAC addresses to custom hostnames, in the format aa:bb:cc:dd:ee:ff device1.mylocalnetwork.local.

Here is the bash script:

#!/bin/bash

dhcp_conf="/etc/dhcp/dhcpd.conf"
names_file="/path/to/names.txt"
unbound_dir="/etc/unbound/local.d"

# Extract MAC and IP from dhcpd.conf and create an associative array
declare -A ip_for_mac
while read -r _ _ mac _ ip _; do
    ip_for_mac[$mac]=$ip
done < <(awk '/hardware ethernet/ { getline; print }' $dhcp_conf)

# Extract MAC and hostname from names file and create Unbound configuration files
while read -r mac hostname; do
    ip=${ip_for_mac[$mac]}
    if [[ -n $ip ]]; then
        conf_file="$unbound_dir/$mac.conf"
        echo "local-zone: \"$hostname\" static" > $conf_file
        echo "local-data: \"$hostname IN A $ip\"" >> $conf_file
    else
        echo "No IP found for MAC $mac"
    fi
done < $names_file

# Restart Unbound to apply changes
/etc/init.d/unbound restart

To use this script:

1. Update the dhcp_conf, names_file, and unbound_dir variables at the top of the script to match your environment.

2. Save the script to a file, e.g., update_unbound.sh.

3. Make the script executable with chmod +x update_unbound.sh.

4. Run the script with ./update_unbound.sh.

Again, this is a basic example and you may need to modify it to fit your specific requirements. Also, it’s good to keep in mind that using scripts to modify system configuration files carries some risk, so it’s recommended to test this script in a controlled environment before deploying it to a live system.

[cfusco]

@pslpsl

I just think I have some trojan proxyware in my network and I try to find it. I found that IPfire doesn’t offer me real help…

cat /var/log/messages | grep "IP_ADDRESS_HOST"

examining the logs this way does not help?

[cfusco]

@pslpsl

Other weak point is “active connection statistics”, I cannot filter by IP address/device,

conntrack -L | grep '192.168.1.100'

@pslpsl

I cannot see DNS names (IP->DNS), all I have to do all that manually.

chatGPT to the rescue, again.

Here a script which uses the host command, and accepts the local DNS name as a command-line argument:

#!/bin/bash

# Check if a command-line argument was provided
if [[ $# -eq 0 ]]; then
    echo "Usage: $0 <local_dns_name>"
    exit 1
fi

# Get the local DNS name from the command-line argument
local_dns_name="$1"

# Resolve the DNS name to an IP address using host
ip_address=$(host $local_dns_name | awk '/has address/ { print $4 }')

# Check if IP address was found
if [[ -z $ip_address ]]; then
    echo "Unable to resolve $local_dns_name to an IP address."
    exit 1
fi

# Search the connection tracking table for the IP address
conntrack -L | grep $ip_address

To use this script:

1. Save the script to a file, e.g., search_conntrack.sh.

2. Make the script executable with chmod +x search_conntrack.sh.

3. Run the script with ./search_conntrack.sh device1.mylocalnetwork.local, replacing device1.mylocalnetwork.local with the local DNS name you want to search for.

This script now uses the host command to resolve the DNS name to an IP address, and it expects the DNS name to be provided as a command-line argument when you run the script. If no argument is provided, it will print a usage message and exit.

The script also still assumes that you have sudo privileges to run the conntrack command. If that’s not the case, you may need to adjust the script or the system’s sudo configuration.

[bbitsch (Bernhard Bitsch)]

The information which is to be written to local.d directory is generated by IPFire in /etc/unbound/dhcp-leases.conf, yet ( if you follow the description in the wiki ).
The information should be updated by dhcp-leases-bridge.

All tools exist in IPFire. Reading the wiki yourself may produce more straight-forward solutions than asking ChatGPT.

[cfusco]

@bbitsch

All tools exist in IPFire. Reading the wiki yourself may produce more straight-forward solutions than asking ChatGPT.

point taken. I think I had this in mind when I suggested this approach to the AI. It had no knowledge of the specific organization of unbound in IPFire. I got the idea of doing this a while ago but never came around to test it. The point was to have an arbitrary name in the local DNS instead of the hostname provided by IPFire. This was the question of OP.

EDIT: to clarify, I want to get rid of all my statically assigned IPs and move everything on the DHCP configuration page as fixed IPs. However, I do not want to have the hostname in the local DNS zone, so I was trying to find a way to solve this problem. From this, the long answer to OP.

There is also a point I want to make. IPFire being a well designed Linux distribution can be configured in two ways, WUI and console. The developers have created a very well designed WUI, but right now they have no time to implement new pages to accomplish any of the multitude of requests from the user-base.

The console is on the other end pure freedom and nothing prevents the user to implement a script to accomplish goals like the ones highlighted by the OP. We can do anything in it, including shooting our own foot. Just few months ago the time necessary to come up with a solution using the console, researching and experimenting, was too much for a normal user. Now the LLMs can short this time by a factor of ten, at the very least.

Getting to the point, it is more useful to implement a new functionality using the console than sending a message to the developers that do not have time to take care of the user-base trivial requests. Furthermore, this is also the best way to learn: messing around with your machine, AND learning how to use the AI prompt at the same time. As long as it is clear that the console is a high caliber foot-gun, there is nothing wrong to decide to take the risk and modify IPFire to our own needs, and share our experience in the forum, which also introduces a second order positive effect, by spreading the knowledge to others.

I could see the other side of this argument being embraced by some of the developers wanting to protect us from our own recklessness and ignorance. This would be a legitimate opinion, but as long as we users understand the risks and are willing to take responsibility for our own actions, I see no problem in my approach.

[pslpsl (Petr Slansky)]

The solution generated by AI is impressive but not easy one. And it doesn’t produce CNAME records but A records (and complex configuration). Smart AI should recommend to replace IPfire with other gateway, like PFsence, OPNsense or ??

My original point was that something is missing in IPfire UI (it is not only about UI, some background scripts should be modified, to support CNAME records). I prefer to manage Android clients with DHCP dynamic addresses, so A records are not crafted manually but generated by DHCP. Simple CNAME record could map user-friendy hostname to generic android hostname (android-4b5f82982c6b9b18) and it will work even in the case that DHCP will asign to client different IP address or when it will connect to different AP. It is not possible now so the easiest way is to write to a transaction table to sheet of paper with entries like android-beef321dead → android-tablet1…

I have to learn conntrack it looks like a powerfull tool…

[cfusco]

@pslpsl

Smart AI should recommend to replace IPfire with other gateway, like PFsence, OPNsense or ??

Maybe it is already smart enough not to do this recommendation. Joking aside, please keep in mind that the very small team of developers have their priority set to a major rewriting of the code-base to add several important missing features, namely IPv6 support and an arbitrary number of zone support. Your feature would be nice, but there is not enough man power right now. New developers are sorely missing.

[pslpsl (Petr Slansky)]

I was running old IPcop for years and when I tried to replace it, it was a painful process, I worked on that for several years (it was not urgent task)… There was problem to find good modern hardware that was reliable, well supported had 2+ NIC and was energy efficient and not expensive. Requirement for 2+ NIC was really painful so I played for some time with OPNsense running on old thinclient terminal (or mini PC) and cheap smart switch that supports VLAN (OPNsense/PFsense supports VLAN out of the box). I decided for IPfire gateway when I managed to get mini PC with 2 ETH ports and free PCI slot for WiFi card. I was familiar with IPcop and I like that IPfire has update accelerator, I like this feature and this was important for me; I do not need IPv6, I have OpenWRT router and small sub-lan dedicated to experiments with IPv6…

Inspired by AI advice, I tried CNAME, just proof of concept, it works:

I have found android entry in /etc/unbound/dhcp-leases.conf:

local-data: "android-9c5479851201c5a3.home 60 IN A 192.168.222.232"
local-data: "232.222.168.192.in-addr.arpa 60 IN PTR android-9c5479851201c5a3.home"

I appended CNAME record to the end of the file; I understand this file is generated by a script when DHCP configuration is changed, so I understand this is not permanent change and it will be lost in few minutes:

local-data: "android-tablet.home 60 CNAME android-9c5479851201c5a3.home"

I sent HUP signal to unbound to reload configuration:

# killall -HUP unbound

Verify that configuration is still in the file:

# grep "9c5479851201c5a3" /etc/unbound/dhcp-leases.conf 
local-data: "android-9c5479851201c5a3.home 60 IN A 192.168.222.232"
local-data: "232.222.168.192.in-addr.arpa 60 IN PTR android-9c5479851201c5a3.home"
local-data: "android-tablet.home 60 CNAME android-9c5479851201c5a3.home"

TEST, it works:

# host "android-tablet"
android-tablet is an alias for android-9c5479851201c5a3.home.

# host "android-tablet.home"
android-tablet is an alias for android-9c5479851201c5a3.home.

# host "android-9c5479851201c5a3"
android-9c5479851201c5a3.home has address 192.168.222.232

# host "android-9c5479851201c5a3.home"
android-9c5479851201c5a3.home has address 192.168.222.232

# host "192.168.222.232"
232.222.168.192.in-addr.arpa domain name pointer android-9c5479851201c5a3.home.

---

Test the case that alias is linked to host that was removed and test for host that is not defined at all.
I cannot explain why I receive two NXDOMAIN replies from host android-tablet2

# grep "broken" /etc/unbound/dhcp-leases.conf 
local-data: "android-tablet2.home 60 CNAME android-broken.home"

# grep "tablet2" /etc/unbound/dhcp-leases.conf 
local-data: "android-tablet2.home 60 CNAME android-broken.home"

# host "android-tablet2" 
android-tablet2.home is an alias for android-broken.home.
Host android-broken.home not found: 3(NXDOMAIN)
Host android-broken.home not found: 3(NXDOMAIN)

# grep "tablet3" /etc/unbound/dhcp-leases.conf

# host "android-tablet3.home" 
Host android-tablet3.home not found: 3(NXDOMAIN)

---

But life is not easy, khost tool (host from knot package) cannot resolve “android-tablet”. I assume this is a bug in khost tool, it ignores “search home” in file /etc/resolv.conf

user@ubuntu:~$ khost "android-tablet" 192.168.222.1
Host android-tablet. type A error: NXDOMAIN
Host android-tablet. type AAAA error: NXDOMAIN
Host android-tablet. type MX error: NXDOMAIN

user@ubuntu:~$ khost "android-tablet.home" 192.168.222.1
android-tablet.home. is an alias for android-9c5489852201d5e2.home.

user@ubuntu:~$ host "android-tablet" 192.168.222.1
Using domain server:
Name: 192.168.222.1
Address: 192.168.222.1#53
Aliases: 

android-tablet.home is an alias for android-9c5489852201d5e2.home.

user@ubuntu:~$ tail -4 /etc/resolv.conf 

nameserver 127.0.0.53
options edns0 trust-ad
search home

[cfusco]

@pslpsl Nice work.

@bonnietwin Do you think there is a way to make these changes permanent?

[pslpsl (Petr Slansky)]

Pernament changes? Maybe there is a quick workaround. Add new include to /etc/unbound/unbound.conf, after include of hosts.conf

# Include aliases
        include: "/etc/unbound/cname.conf"

Define CNAME records in cname.conf file. As this modifies core IPfire files, there is high change it will be replaced in future update of IPfire.

Better solution will allow to enter “hostname” to field that is reserved for IP address now (in hosts,cgi) and script /usr/sbin/unbound-dhcp-leases-bridge that parses /var/ipfire/main/hosts will check if 2nd field is IP address and in that case it will generate A (and PTR when required) record (current behavior) and CNAME record when 2nd field is not IP address (new feature). CNAME records could be written to /etc/unbound/hosts.conf alongside A and PTR records…

UPDATE. Maybe it is not that easy, /var/ipfire/main/hosts is parsed by start script /etc/init.d/unbound too…