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?

not related to aliasclient but I found this regarding android auto adding google dns : https://www.reddit.com/r/pihole/comments/aqjrqo/android_auto_adds_8888_to_dns_list/

Are they OnePlus devices?
To clear up a misunderstanding, its not Google Android doing that ... I believe.
I have four different brand Android devices that dont show the behaviour you described above.
I have up till now only seen OnePlus devices doing that.

To fix, advertise the Pi-hole IP two or even three times as a DNS IP via your DHCP service.
For Pi-hole's own DHCP service thats as easy as:

pi@ph5a:~ $ sudo nano /etc/dnsmasq.d/10-dhcp-dns.conf
dhcp-option=option:dns-server,0.0.0.0,0.0.0.0,0.0.0.0
pi@ph5a:~ $ pihole-FTL --test
dnsmasq: syntax check OK.
pi@ph5a:~ $ sudo service pihole-FTL reload
pi@ph5a:~ $

To check:

pi@ph5a:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
   dns-server: 10.0.0.2
   dns-server: 10.0.0.2
   dns-server: 10.0.0.2
[..]

To check on an Android devices, I advice to install the Network Info app and checkout the WiFi tab.

A friend of mine has an OPPO phone which is running their version of Android called colorOS. He's on colorOS v11.1, based on Android 11. His phone does the same thing. We were trying to configure it with his router and Pi-hole and no matter what we did the phone always adds an additional DNS entry for 8.8.8.8. There's no warning that it chooses to do this nor seemingly any way to disable the behaviour.

Interestingly OPPO and OnePlus are very close so this probably explains the same behaviour on both brands.

1 Like

The one that made that up must have been sniffing the wrong glue.
Every sane admin can tell you that any redundant DNS server(s) should be identical in the way they reply / the records they hold.
Google 8.8.8.8 doesnt know about your local DNS records.
Very strange that another brand adopted the same stupid implementation.
Or I am mistaken and they have a very very good reason to do so :wink:

Maybe related to Chrome feature "Async DNS resolver" for example. This seems to allow the use of another dns than the primary.

My phone is a realme, and it does exactly the same : adding 8.8.8.8 as dns at the end.

Do you have the option to advertise two or more IP's for DNS via DHCP?
Validate with that Network Info app I mentioned before.

Thanks you deHakkelaar. I did a redirection of all requests on my router, following this example:

1 Like

Disadvantage of masquerading the DNS queries before being dropped at Pi-hole is that they will all appear as coming from the router/firewall.
So those devices that misbehave wont show up on the Pi-hole dashboard but the router/firewall IP instead.

Best to have both advertise the Pi-hole IP via DHCP multiple times ... and DNS redirecting with the firewall.
That way those pesky OnePlus devices show up on the dashboard and any other misbehaving devices/apps will get the redirect.

FYI, some routers/firmware have that DNS redirecting already as a setting.

My router asks a different IP address than the first one for the DNS.
And the misbehaving devices add always 8.8.8.8 as additional dns.

You could try entering 0.0.0.0 for that second DNS address field.
Or enter an unused private IP from your LAN subnet thats outside your DHCP scope.
For the clients it doesnt matter that much if this second DNS IP is dead.

You can validate on the Pi-hole host with below (I have two Pi-hole nodes):

pi@ph5b:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
   dns-server: 10.0.0.2
   dns-server: 10.0.0.4

And check on the bugged device oc :wink:


The router is the dhcp server. It has 2 dns fields; primary and secondary.

What dns-server's are displayed when you run below one?

You could disable the router DHCP service and let Pi-hole take over that part:

That way you could try to advertise the Pi-hole IP three times and see if that "Realme" device adds a fourth 8.8.8.8 DNS IP which seems highly unlikely ... but still: