Local DNS names not migrated to V6

Help
1

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

I have two Raspi running Pihole in Docker, the newer Pi4 as the Primary DNS server and the older/slower Pi2 one as the secondary.

Expected Behaviour:

I expected the migration from V5 to V6 to include the Local DNS names

Actual Behaviour:

I have initially migrated the secondary one from V5 to V6 to test the migration process and the changes I made to the yml docker file.
My Router (TP-Link ER605) is acting as the DHCP server but as it does NOT have a DNS stub for local name resolution (!) So I have previously set local DNS names for a number of clients in PiHole in order to identify the clients in the logs and dashboard.

After migrating the Secondary DNS server to V6 I noticed that the "Local DNS" settings that I had created no longer appear in the UI under the "Local DNS" panel in Settings. However, to my surprise, the Query log is still showing the client name, even for queries made after the migration!
Have they migrated and if so, where can they be found?

Debug Token:

Sorry, can't find how to generate a dubug token in V6 in a Docker container

2

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 if you run your Pi-hole as a Docker container:

docker exec -it <pihole-container-name-or-id> pihole -d

where you substitute <pihole-container-name-or-id> as required.

3

Thanks for the guidance.

I have just run the debug utility and the associated token is WRkBtRmx

FYI, I can now see one local domain in my Local DNS list, it is for my Philips TV with an IP address of 192.168.1.102.
However, all the devices that have used the Secondary (migrated) DNS today (1st April) are showing device names in the Query Log, not IP addresses, so it looks like PiHole V6 is getting them from somewhere other than the "Local DNS" set in the UI.

Any help you can give would be appreciated

The setup of my primary DNS on a Pi4b which has not yet been migrated to V6 shows 16 devices in my local DNS, each with their associated IP addresses. The setup of the two devices appeared identical prior to this test migration.

4

Indeed, your debug log only shows one locally defined name:

-rw-r----- 1 pihole pihole 55K Mar 31 11:35 /etc/pihole/pihole.toml
   [dns]
     (…)
     hosts = [
       "192.168.1.102 philipsambilighttv"
     ] ### CHANGED, default = []

Please share your docker compose or docker run script for your Pi-hole container.

5

Yes, I saw that one device in the debug log subsequently. I have no idea why that one client has its name registered.
My YML file is as follows;-

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole2
    image: pihole/pihole:latest
    hostname: Pi2b_Dock
    ports:
      # DNS Ports
      - "53:53/tcp"
      - "53:53/udp"
      # Default HTTP Port
      - "80:80/tcp"
      # Default HTTPs Port. FTL will generate a self-signed certificate
      - "443:443/tcp"
      # Uncomment the below if using Pi-hole as your DHCP Server
      #- "67:67/udp"
      # Uncomment the line below if you are using Pi-hole as your NTP server
      #- "123:123/udp"
    environment:
      # Set the appropriate timezone for your location from
      # https://en.wikipedia.org/wiki/List_of_tz_database_time_zones, e.g:
      TZ: 'Europe/London'
      # Set a password to access the web interface. Not setting one will result in a random password being assigned
      FTLCONF_webserver_api_password: <redacted>
      # If using Docker's default `bridge` network setting the dns listening mode should be set to 'all'
      FTLCONF_dns_listeningMode: 'all'
      FTLCONF_misc_etc_dnsmasq_d: 'true' # just for migration from V5 to V6 pihole
      FTLCONF_dns_reply_host_IPv4: 192.168.1.150  # Reserved IP
      FTLCONF_dns_upstreams: 208.67.222.222;208.67.220.220  # OpenDNS default servers
    # Volumes store your data between container upgrades
    volumes:
      # For persisting Pi-hole's databases and common configuration file
      - './etc-pihole:/etc/pihole'
      # Uncomment the below if you have custom dnsmasq config files that you want to persist. Not needed for most starting fresh with Pi-hole v6. If you're upgrading from v5 you and have used this directory before, you should keep it enabled for the first v6 container start to allow for a complete migration. It can be removed afterwards. Needs environment variable FTLCONF_misc_etc_dnsmasq_d: 'true'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #cap_add:
      # See https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
      # Required if you are using Pi-hole as your DHCP server, else not needed
      # - NET_ADMIN
      # Required if you are using Pi-hole as your NTP client to be able to set the host's system time
      # - SYS_TIME
      # Optional, if Pi-hole should get some more processing time
      # - SYS_NICE
    restart: unless-stopped

It is pretty much based on the sample provided.
Thanks for your help

6

Pi-hole v5 and v6 store local names in different files, but both do so in a file under /etc/pihole.

Your current docker compose script for Pi-hole v6 does mount /etc/pihole/.

If your previous v5 script wouldn't have done so, that could explain why your local names wouldn't have made it into your v6 container.

7

Sorry but I am bit confused by your response, I can see the following statement in my yml file -

  # For persisting Pi-hole's databases and common configuration file
  - './etc-pihole:/etc/pihole'

This is the same as in the previous (V5) yml file. Is it incorrect in some way?

8

Docker-compose.yml for V5 contains the following -

Volumes store your data between container upgrades

volumes:
  - './etc-pihole:/etc/pihole'
  - './etc-dnsmasq.d:/etc/dnsmasq.d'
9

dockert-compose.yml for V6 contains the following-

Volumes store your data between container upgrades

volumes:
  # For persisting Pi-hole's databases and common configuration file
  - './etc-pihole:/etc/pihole'

The only difference I can see is that there is a # comment line between the "volumes" keyword and the volume definitions

Have I misunderstood your response?

10

Hi @Bucking_Horn
I still have a V5 version of Pihole running on my primary DNS server on a Pi4b so I had the opportunity to compare the data before it was migrated to V6.
Within the etc-pihole directory is a file named "custom.list"
This contains a list of my 16 devices with their IP4 addresses which are in shown in my "Local DNS names" under the "Local DNS" setting in V5 pi-hole.
The "philipsambilighttv" device with its IP4 address is the last record in that file. That is the only device that was migrated into V6 in the "hosts" file.

IMHO, it looks like the migration only took the last record and not the other 15 devices listed.

The Query log in the migrated V6 pihole is still showing device names rather than IP addresses although there is only the one record in the "hosts" file. I have no idea how that is happening, especially as there are no "Clients" listed in the Clients section either.

Regards
mhoam

11

Note:

This is expected if you are not using the Group Management pages.

This page doesn't show all clients currently using Pi-hole. It only shows clients that you manually added to a group.

This is a completely unrelated feature.

12

Ah, OK, thanks for the info.
I was just trying to think of where else within PiHole the device names could be held.
As I stated, the dashboard and query logs are still showing the correct device names despite only one device being migrated across from V5 in the “Local DNS” settings
Thanks
Mhoam

13

Since I have no answers or further suggestions on this Forum I guess this item will just close itself. Rather disappointed at the lack of input

14

As explained, both v5 and v6 would store local names under /etc/pihole, if in different files.

For names to have been migrated to v6, your Pi-hole v5 container must have mounted /etc/pihole/, or else any local names would have been stored only within the container, and thus been overwritten when you discarded the container and created a new one from a Pi-hole v6 image.

Similar would be true if you had created a new v6 next to your existing v5 container, as they would have used different mount points.

Your debug log has expired, so I can't check for it, but another potential explanation would be that your secondary Pi-hole never held those records itself, but queried your primary Pi-hole for them.

Would any of the above apply to your scenario?

15

Thanks for the info.
I know that both yml files were identical as I had spent some time trying IPV6 configurations on both machines. They both definitely mounted the etc/pihole volume. It seems one device name and IP address was migrated from the V5 “custom DNS” file to the V6 “hosts” file both in the etc/pihole volume which strongly suggests the volumes were mounted correctly in the container.

I was not aware that one pihole instance in a docker container could query another instance of pihole in a docker container on a separate machine for a device name. I’m not a network expert so I’m guessing this could occur via an “arpa” reverse DNA query?
I had taken some time and effort to keep the two configurations re the Local DNS configurations in sync, although I cannot prove they were identical.

As I don’t have enough evidence/data to log an issue in GitHub I guess I will just have to migrate the second device and see what happens. It won’t be the end of the world if I have to re-enter the 16 devices.
I will retain the pre-migration yml and Custom files, can you suggest any other prep prior to the migration of the Primary DNS on the Pi4b?
Thanks
Mhoam

16

You would need to enable Conditional Forwarding via Settings | DNS in Expert mode, and you'd need your Pi-holes to use distinct subnets and local domains.
But this isn't likely to be your scenario if you aim to keep both your Pi-holes in sync.

Creating a teleporter backup via Settings | Teleporter is always a good idea.
That would allow you to restore your settings if something should go wrong during an upgrade.

Please report if you would observe a loss of your 16 names again, as that would suggest a bug in Pi-hole's upgrade script for container upgrades.

17

@Bucking_Horn
OK, thanks. Can you confirm that a Teleporter backup made on a V5 Pihole will restore correctly into a V6 version?
Mhoam

18

I am not aware of any issues when restoring Teleporter backups into v6.

19

Sorry @Bucking_Horn but that is a VERY noncommittal statement.
I appreciate you are a volunteer but is it not possible to check if the restoration of backups across breaking versions was a test case that was checked prior to release?
Thanks

20

Teleporter imports have been tested, but that doesn't prove that there may not be bugs.
My statement was meant to convey that I've put in the extra effort for you to go through v6 related forum posts as well as GitHub issues, to preclude that you may run into any known issues.

Those sources are public, so if you feel you can't trust my statement, you are free to verify that analysis.