Aliasclient usage and queries

Hello,
First I would like to thank you for all the dev and features.
I'm using the standard version of pihole

  • Pi-hole [v5.15]
  • FTL [v5.20.1]
  • Web Interface [v5.18.1]

And I tried to use "aliasclient" so as to get name instead of ip address in the interface.
I successfully added names by doing : INSERT INTO aliasclient (id,name,comment) VALUES (0,'firstmachine',NULL);
Then I added the corresponding ID in network table:
UPDATE network SET aliasclient_id = 0 WHERE hwaddr = '3c:fd:e1:5b:1c:02';

then, I can see in the dashboard the names I entered!
However, when I click the name, there is no query recorded for the aliasclient.
The url is: http://192.168.8.5/admin/queries.php?client=aliasclient-0

Would you know if this is normal, or if I missed something?

Thank you for your help!

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Hello,

Here is the url: https://tricorder.pi-hole.net/kgQOEsfc/

pihole runs in a docker container on a synology with its own virtual network/ip address.
Here is the docker-compose who create the container (my router is 192.168.8.10):

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    hostname: pi-hole
    build:
      context: .
      shm_size: '256m'
    mac_address: d0:ca:ab:cd:ef:01
    shm_size: '256m'
    cap_add:
      - NET_ADMIN
    ports:
      - 443/tcp
      - 53/tcp
      - 53/udp
      # - 67/udp # Uncomment if you want to use Pi-Hole for DHCP
      - 80/tcp
      - 22/tcp
    environment:
      FTLCONF_LOCAL_IPV4: 192.168.8.5
      WEBPASSWORD: ${WEBPASSWORD}
      DNSMASQ_LISTENING: all
      DNSMASQ_USER: root
      VIRTUAL_HOST: pihole
      DNS1: 192.168.8.6
      DNS2: 192.168.8.13
    volumes:
      - /volume1/docker/pihole-unbound/pihole/volume:/etc/pihole:rw
      - /volume1/docker/pihole-unbound/pihole/config/hosts:/etc/hosts:ro
      - /volume1/docker/pihole-unbound/pihole/config/resolv.conf:/etc/resolv.conf:ro
      - /volume1/docker/pihole-unbound/pihole/config/dnsmasq.conf:/etc/dnsmasq.d/02-network.conf:ro
      - /volume1/docker/pihole-unbound/pihole/config/pihole-FTL.conf:/etc/pihole/pihole-FTL.conf:ro
    networks:
      home:
        ipv4_address: 192.168.8.5
    restart: always
  unbound:
    container_name: unbound
    image: mvance/unbound:latest
    hostname: syn-unbound
    mac_address: d0:ca:ab:cd:ef:02
    ports:
      - 53/tcp
      - 53/udp
    networks:
      home:
        ipv4_address: 192.168.8.6
    restart: always

networks:
  home:
    driver: macvlan
    driver_opts:
      parent: eth1
    ipam:
      config:
        - subnet: 192.168.8.0/24
          gateway: 192.168.8.10
          ip_range: 192.168.8.5/30

Hello,

Do you need a more recent debug log?
I just made a new one:
https://tricorder.pi-hole.net/CRX5Pmr8/

Here is my pihole-FTL.conf:

PRIVACYLEVEL=0
DBINTERVAL=60
RESOLVE_IPV4=yes
BLOCKINGMODE=IP-NODATA-AAAA

I just added:
DEBUG_ALIASCLIENTS= true
and restarted pihole-FTL.

I downloaded /var/log/pihole/FTL.log from container too.

Sorry for the delay - your answer slipped past me.

alias-clients are not required to show hostnames instead of IPs.

That experimental feature will aggregate dashboard statistics for several IP addresses as aggregated by a network interface's hardware address under a single hostname. Your observation is expected: It's effect is limited to the dashboard.

However, associating client IPs to hostnames is done automatically by several other means like regular reverse lookups for client IPs or inspecting directly observable, same-link network information.
If you were not seeing hostnames in Pi-hole's dashboard, then there must be a separate reason for that.

If your router is your DHCP server, using your router as Pi-hole's only upstream or enabling Pi-hole's Conditional Forwarding would be required for reverse lookups for local IPs to succeed. Of course, this would imply that your router would not only know the names for its DHCP clients, but that it would also provide those names as replies for DNS queries.
Note that not all routers would do so.
You may verify whether your router at 192.168.8.10 does by running a reverse lookup past it, e.g.

nslookup 192.168.8.6 192.168.8.10

Another fundamental prerequisite for seeing individual clients (IP or hostname) in Pi-hole's dashboard is that clients have to talk to your Pi-hole directly.

Your debug log shows your router's DHCP server to distribute your Pi-hole as local DNS server to DHCP clients - but also 1.1.1.1:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   
   * Received 300 bytes from eth0:192.168.8.10
     Offered IP address: 192.168.8.166
     DHCP options:
      Message type: DHCPOFFER (2)
      router: 192.168.8.10
      dns-server: 192.168.8.5
      dns-server: 1.1.1.1
      --- end of options ---

That would allow clients to use 1.1.1.1 for DNS at their own discretion, bypassing Pi-hole completely. Pi-hole has to be the only DNS resolver for your clients.

1 Like

Thank you for your detailed explanation and advices.
I understand what aliasclient is for then.
I was hoping of using it as a way to identify names clients in pihole from their mac address instead of ip address. (client MACs to hostnames instead of client IPs to hostnames)
Most of the devices in my LAN get dynamic IP from my router.

I will try to make the router know the names of its dhcp clients, as you suggest and make reverse lookup.
192.168.8.6 is the virtual ip of unbound container.

All clients use pihole ip address as DNS. You're right, I don't need cloudflare 1.1.1.1

I configured specific leases on the router dhcp config for all clients. This allows me to customize the host file in the pihole container. Thanks for all.

Apart from that, a problem is that stock android smartphones put automatically 8.8.8.8 as secondary DNS (or third) in network wifi config; and I didnot find any way to prevent this.

Same problem here, but the question was answered here (January 2021). That answer says it's pointless to add this to the web interface, because v5.x will soon be superseded.
Since development of v5.x apparently continues (lots of improvements lately) I wonder if @rdwebdesign can be encouraged to look at this missing part of the web interface, when using alias clients?