Pi-Hole IPv6 - Hostname resolution noob questions

[mx2k]

Hello Community,

my new ISP gave my IPv6 Internet and I have some questions regarding Pi-Hole, IPv6 and Hostname display in Pi-Hole logs.

Please see Pi-Hole network info screenshot.

• Like my router 10.1.1.1 is not getting a hostname at all. And that's the only device where I actually manually defined a hostname to use via the routers config.

• Some devices do get the IPv4 hostname displayed, but not the IPv6, like the NAS.

• Yet other devices (not shown in screenshot) actually do get some hostname assigned to both IPv4 and IPv6.

• This leads to 2 log entries for each device, one for IPv4 which usually also gets a hostname to show for easy client identification. And then there's the IPv6 where only the IP address is shown in the logfiles. This is making it quite hard to identify which device is sending queries, since IPv6 addresses ain't easy to memorize.

• The router is acting as DHCP Server and Pi-Hole does DNS only.
  The router provides Pi-Hole DNS Server IPv4 and IPv6 to its leases.
  In Pi-Hole I use conditional forwarding to my router IP, so that name resolution for local devices works at all with my setup using separate DHCP server.
  There is only one field for conditional forwarding in Pi-Hole config and I cannot seem to add conditional forwarding for IPv6 to the router's IPv6 address. Which would be the solution if I understood the involved networking principles correctly.

Questions:

• How is determined which device gets a IPv6 hostname to show in Pi-Hole?
• How to configure so that all active IPv6 hosts get a hostname assigned to them
  (so that in Pi-Hole logs a hostname is displayed as usual and not only the IPv6 address?

• Maybe there is a simple misconfiguration somewhere in my network. I really hope there is an easy way to make all IPv6 hostnames known to Pi-Hole with my current network setup.

[Daxtorim]

The hostname of your devices is discovered through PTR queries (reverse DNS). Your local network is 10.1.1.0/x I assume, then such a PTR query would look like 5.1.1.10.in-addr.arpa (IP address in reversed order) and the answer would be the hostname of that device, mx-nas.fritz.box. The "issue" with the conditional forwarding on the web interface is that it is very specific about which of those domains it forwards. It actually only forwards those that look like xxx.1.1.10.in-addr.arpa. But the PTR query for that devices link-local IPv6 address would look like 6.8.4.e.3.8.e.f.f.f.2.3.1.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa, that obviously does not fit the template for the IPv4 addresses and is thus never forwarded to the router where it should go.

You need to create a custom config file like /etc/dnsmasq.d/conditional-forwarding.conf on the device that hosts Pi-hole (the actual name isn't important, just the directory) and add your new templates for PTR queries like this:
server=/0.8.e.f.ip6.arpa/10.1.1.1
The first field is the template for the domain (i.e. every domain that ends with 0.8.e.f.ip6.arpa will be forwarded). The second field is where that query should be forwarded to, i.e. your router at 10.1.1.1.
Now you need to add such a rule for every one of your IPv6 prefixes that you might encounter and you are golden.

---

Or be lazy and do this:
server=/arpa/10.1.1.1
Just forward the entire arpa domain to your router. This will include every PTR query that comes up in your network, so make sure you are not creating a DNS loop in your network. This means Pi-hole cannot be the upstream DNS server of your router itself. There is this handy guide for the FritzBox: Fritz!Box (EN) - Pi-hole documentation (Avoid/Undo the middle part of that guide: Pi-hole as upstream DNS server for your Fritz!Box).

After you do all that don't forget to restart the DNS server (pihole restartdns or click the button on the web interface).

[mx2k]

Hello thanks for the feedback!

It could be I was already encountering some sort of DNS Loop. Would this explain a large set of NXDOMAIN, NODATA and Retried log entries? Somehow the network and DNS resolution still worked. Need to find time later to implement the new config file.

More info on current config:

• Pi-Hole IPv4/6 was set as the Upstream DNS in the FritzBox.
• Pi-Hole IPv4/6 is distributed to the clients as DNS server to use via DHCP, so I can see individual clients statistics.
• Pi-Hole has conditional forwarding back to FritzBox for IPv4 enabled.
• Pi-Hole runs a local unbound installation as its sole upstream DNS entry.

Changes implemented:

• I have exchanged the upstream DNS servers in the FritzBox, replaced the Pi-Hole IPs with Cloudflare and Google.
• The DHCP configuration was correct already.

Result:

• IPv4 PTR and A queries for local network are now handled by fritz.box#53 instead of unbound at Pi-Hole localhost#5335
• IPv6 PTR and AAAA queries now are also handled by fritz.box#53 but respond with NODATA. I guess that is the case until I integrate the .conf and enable conditional forwarding for IPv6 on Pi-Holes dnsmasq.

What I gotta do:

• Create .conf for dnsmasq to enable conditional forwarding for all PTR with server=/arpa/10.1.1.1.

Question:

• Is server=/arpa/10.1.1.1. the one fire and forget command that handles all conditional forwarding for IPv4 and IPv6, or only IPv6?

• Do I have to keep the existing IPv4 conditional forwarding settings enabled in the Pi-Hole GUI? Or can it be disabled because the new .conf will handle all the forwarding regardless of IP protocol version?

• I notice that upstream queries (for domains in the internet) sent via unbound sometimes only resolve the IPv4 address and give NODATA for the IPv6.
  Example:
  Query to google.com gives responses with both versions Status OK, and then the IPv4 and IPv6 addresses of google.com.
  Query to ea.com only gives IPv4 response and NODATA for IPv6.
  Is this maybe due to the fact that not all servers / domains on the internet provide a IPv6 address and can I safely assume that ea.com domain simply does not support IPv6 and provide no AAAA record?

[Daxtorim]

It could be I was already encountering some sort of DNS Loop. Would this explain a large set of NXDOMAIN, NODATA and Retried log entries?

No, NXDOMAIN means the requested domain simply doesn't exist. Could be a typo, could be misconfiguration, could be the domain was moved to another name. NODATA means there is no information for the requested type. Most commonly seen for queries for AAAA records, because a lot of domains don't support IPv6 yet.
If you have a massive amount of Retried queries it could maybe, potentially mean some underlying connectivity issues. If it's just a few here and there, it could be dropped packet or unbound is currently under load and drops the query or the device is under such load that the query cannot be processed in time. If it is relatively rare, I wouldn't worry about it.

If you had a DNS loop you would see several hundred thousand, maybe even millions of queries. Pi-hole would send a query to your router and the router would send it right back, but it's still the same query, so Pi-hole will send it to the router again and the router will send it back again and so forth; and that several times a second.

---

IPv6 PTR and AAAA queries now are also handled by fritz.box#53 but respond with NODATA.

Wait, PTR queries are already send to the router even without the custom config? Or was that a typo?

NODATA as response to the AAAA queries could mean that the device doesn't have a IPv6 address or the router isn't keeping track of it.
The response to PTR queries would be NXDOMAIN in that case. This will be the case for PTR requests for IPv6 addresses that simply aren't in use anymore. A lot of devices nowadays make use of RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Basically, they periodically generate a random IPv6 address for temporary use. This is because the IPv6 address is globally unique to your device, the temprary address is to prevent the servers you connect to during browsing from tracking your device based on its address. With IPv4, all devices on your network are communicating to the Internet with one public address of your router and thus are obfuscated by it, this is simply not the case anymore with IPv6.
Pi-hole will only try to get hostnames for recently active IP addresses, so PTR queries for IP addresses not in use anymore will cease after a while.

Is server=/arpa/10.1.1.1. the one fire and forget command that handles all conditional forwarding for IPv4 and IPv6, or only IPv6?

It handles both and more. See the wikipedia article for more info. All those domains are trying to get information that would probably be given by your router anyway. If the router can't resolve them, it will send them to its upstream DNS server, hence the necessity to avoid DNS loops. Unless you have some very specific use case for these domains this isn't a problem.

Do I have to keep the existing IPv4 conditional forwarding settings enabled in the Pi-Hole GUI?

Technically no, you could remove it. If you also add server=/fritz.box/10.1.1.1 to your new config to copy the functionality of the Local domain name (optional) field too, the GUI options become completely redundant. It doesn't hurt to keep them and they will remind you that you have conditional forwarding active.

I notice that upstream queries (for domains in the internet) sent via unbound sometimes only resolve the IPv4 address and give NODATA for the IPv6. [...] Is this maybe due to the fact that not all servers / domains on the internet provide a IPv6 address [...]?

Correct.

[mx2k]

@Daxtorim

Wait, PTR queries are already send to the router even without the custom config? Or was that a typo?

Yes, that's totally me confusing PTR and AAAA again.

Anyways, I think it's working now, I have implemented the custom config. IPv6 PTR requests go to fritz.box#53 and Pi-Hole also shows hostnames for the IPv6 hosts in dashboard and logs.

@Daxtorim

Just forward the entire arpa domain to your router. This will include every PTR query that comes up in your network

I read the arpanet wikipedia articles you provided. From my understanding .arpa primarily handles reverse DNS and some other very specific things I never encountered within my LAN, but no other traffic.

Just to be safe: I assume there is no other network traffic than reverse DNS / PTR requests, which is now being automatically forwarded to fritz.box. In other words, the conditional forwarding is limited to local hosts and it wont leak any data to the outside world?

And finally another IPv6 question.

• Basically (literally) each device on my network now has 3 IPv6 addresses where I kinda understand the purpose. Global IP from router, fd00: for local, and fe80: for link local / loopback or whatever.
• Except my cellphone. It has a ton of fd00:. Why?
  
  

[Daxtorim]

@mx2k

the conditional forwarding is limited to local hosts and it wont leak any data to the outside world

The conditional forwarding is there to prevent leaking data to the outside world by keeping PTR request for local IP addresses inside your own network. It is limited to the domain you specified (arpa I presume) and wont affect any other traffic.

---

@mx2k

Except my cellphone. It has a ton of fd00:. Why?

This is what I tried to explain here:

@Daxtorim

A lot of devices nowadays make use of RFC 4941 - Privacy Extensions for Stateless Address Autoconfiguration in IPv6. Basically, they periodically generate a random IPv6 address for temporary use. This is because the IPv6 address is globally unique to your device , the temprary address is to prevent the servers you connect to during browsing from tracking your device based on its address. With IPv4, all devices on your network are communicating to the Internet with one public address of your router and thus are obfuscated by it, this is simply not the case anymore with IPv6.

Pi-hole saves all its queries in a database, and part of every query is the IP address that issued that query. This address is then associated with one of your clients and displayed in the network overview. Even if the device itself is no longer using that IP address, it is still stored in Pi-hole's database and is therefore still displayed in the network overview.
The reason why you see a lot more ULAs (fd00::) than GUAs (2a00::) is probably that the ULAs are preferred when connecting to another ULA inside your own network. The GUAs are used when the device actually connects to the outside server (you can't even use the ULA in this case at all).

[mx2k]

Thanks for the info, and all the help provided so far. I'm getting a better understanding (hopefully ) Still questions, questions, here we go:

The Pi-Hole is working quite stables and most things seem in order. There are some hosts shown in Pi-Hole network stats that simply don't exist and I wonder how they get there.

• This IP address is not assigned anywhere in the router. Looking up the MAC address results in "invalid MAC". Scanning the LAN does not show any device 10.1.1.38.

Another two devices with invalid MAC addresses.

• I wonder where Pi-Hole gets this data for hosts with invalid MAC addresses. No idea how to identify an unknown device when I cannot even figure out the vendor by MAC lookup. There are 40 devices in my home LAN and I kinda want to identify which one is causing this.

The conditional forwarding is properly resolving all IPv6 hostnames with DHCP leases, but not for the FritzBox router itself.

• Shouldn't the own hostname be the first thing FritzBox tells Pi-Hole?
• Or is that working as intended, since Pi-Hole is no longer the FritzBox upstream DNS server, thereby FritzBox no longer sending DNS queries to DNS hole?
• Is it normal that number of queries is 0? I would expect all the PTR queries to be recorded there.

---

And finally, some more general IPv6 issues:

FritzBox router is supposed to Firewall IP4 and IP6 in the same way, e.g. do not let any fishy traffic into my network and shield my local hosts from external access. Do not expose local hosts to the internet.

Now, with IPv6 my Pi-Hole got, in addition to the fe80:/fd00: local addresses, the globally unique address 2a00:6020:[..omitted for security..]:24f8.

This address is supposed to be behind the firewall and not accessible externally. From external LTE network I can access this 2a00:6020:[..omitted for security..]:24f8. firewalled IP in ways that should not be possible:

• I can ping it. Says host online, but all ping packets are lost. The ping command should stop at the FritzBox firewall as last hop and not tell anything about device status of my local hosts. There is an option in FritzBox to enable PINGv6 for a device which has port forwarding enabled. But I have not done so for Pi-Hole, yet its IPv6 is pingable.

• I can visual traceroute it. It gives pretty exact geolocation of where my hosts are located. The tracert discovery should stop at router firewall as the last hop, not at the Pi-Hole host hop inside my LAN.

So, is this the way IPv6 works? Each of my internal hosts is now exposed to the internet with its own global IP which any hacker can scan for security flaws?

• Lets say with IPv4 I kinda understood how the firewall worked. With IPv6 not so. Its exposing the global hostnames, but still shielding the ports of each host form external access. How can I find out if the firewall is actually working as intended?

• I still don't understand how the Pi-Hole's global IPv6 is directly pingable at all, since I haven't enabled any PINGv6 forwarding to the RasPi in the router.

• Do I have to firewall all devices separately? I hope not, have a bunch of IoT stuff that has no built in firewall.

• On the other hand, when I scan for open server ports on Pi-Hole global IPv6 2a00:6020: from external LTE net, they are all shown as closed or blocked. I think this looks OK.

• When I scan Pi-Hole's 2a00:6020: from within my WLAN, it shows open ports 22, 53 and 80. I think it totally makes sense it works this way, since I access from local. But I really hope those ports are never accessible from external networks (as long as I do not open some ports for VPN etc).

• tl;dr - Can I safely assume my IPv6-enabled networks still is as secure as it was with the IPv4 only connection?

[Daxtorim]

@mx2k

There are some hosts shown in Pi-Hole network stats that simply don't exist and I wonder how they get there.

I can't give you a precise answer to that, so let me make some guesses:

• They could be from guest's devices that have left and their devices aren't registered in the Fritz!Box anymore. Pi-hole still knows them because they were stored in the database.
• Some devices randomize their MAC address when joining a new network, almost similar to Privacy Extensions for IPv6 addresses. Apple's explanation: Wi-Fi privacy - Apple Support
• The MAC address might simply not be registered with a certain vendor. I recognize 62:ff:4d:xx:xx:xx, it's the MAC address of my Fritz!Wlan Repeater, so it probably belongs to AVM even though it's not in the vendor database. (Actually, the label on the device says 7c:ff:4d:xx:xx:xx, which does officially belong to AVM. Might be bug in this case.)

---

@mx2k

Shouldn't the own hostname be the first thing FritzBox tells Pi-Hole?

Pi-hole only gets the hostnames via queries for PTR records. I don't know if the router always tells the client its own name. Why would it?

@mx2k

Is it normal that number of queries is 0? I would expect all the PTR queries to be recorded there.

Yes, Pi-hole is no longer the upstream server of the Fritz!Box itself. The PTR queries are being sent from Pi-hole to the Fritz!Box, but that number on the network overview is the queries being sent to Pi-hole from the Fritz!Box, which is now zero.

---

@mx2k

From external LTE network I can access this 2a00:6020:[..omitted for security..]:24f8. firewalled IP in ways that should not be possible:

• I can ping it. [...]
• I can visual traceroute it. [...]

I can successfully do both of those things with my routers public IPv4 address as well.
I used https://gsuite.tools/ for testing.
When I do both for the IPv6 GUA of a device on my LAN:

• Ping results in Destination unreachable: Administratively prohibited.
• Traceroute stops at the router, just as you expected.

@mx2k

So, is this the way IPv6 works? Each of my internal hosts is now exposed to the internet with its own global IP which any hacker can scan for security flaws?

The internet protocol used for communication should not make any difference in what traffic is filtered by the router's firewall. My Fritz!box's firewall is doing its job keeping this traffic out. Is your Fritz!Box's firewall correctly configured? Did you interpret the output of ping and traceroute correctly? If it is and you did, this would be a security issue and a case for AVM's support.

---

@mx2k

How can I find out if the firewall is actually working as intended?

@mx2k

When I scan Pi-Hole's 2a00:6020: from within my WLAN, it shows open ports 22, 53 and 80. I think it totally makes sense it works this way, since I access from local. But I really hope those ports are never accessible from external networks[...].

@mx2k

On the other hand, when I scan for open server ports on Pi-Hole global IPv6 2a00:6020: from external LTE net, they are all shown as closed or blocked.

You answered your own question there.

---

@mx2k

tl;dr - Can I safely assume my IPv6-enabled networks still is as secure as it was with the IPv4 only connection?

Yes. From wikipedia:

In December 1998, IPv6 became a Draft Standard for the IETF,[2] who subsequently ratified it as an Internet Standard on 14 July 2017. [3][4]

IPv6 was in the works for almost two decades before it became an officially recognized standard. I believe the worst vulnerabilities have been ironed out over that time and it would have never been ratified in the first place if it wasn't as secure as IPv4.

[mx2k]

All questions answered! I love you guys for taking the time to actually answer stuff in a noob friendly way

[mx2k]

Hello again, I further worked on my network and ran into other issues and inconveniences, obviously.

• I was about to complain about of seeing a ton of Unknown log entries, but there was a Pi-Hole patch today which mentioned a fixed bug which might have caused this.
• The issue is this:
  Client sends requests via both IPv and IPv6 hostnames.
  All requests originating from IPv6 hostname are resolved correctly.
  All requests originating from IPv4 hostnames seem duplicated of the IPv6 hostname requests.
  Nearly all (90%) those IPv4 requests create a Unknown response in Pi-Hole.

I hope this is the issue fixed in Pi-Hole 5.6 / latest version.

Regarding the duplicate / stale network table entries: Rebooting router and Pi-Hole kicked out any old DHCP leases, this looks quite fine now.

However, there are some annoyances:

• My Synology NAS was rather stubborn not providing the IPv6 hostname to Pi-Hole.
• Since it has a static IPv6 local address, I have added the IPv6 it to /etc/hosts on Pi-Hole.
  Is this a valid solution to provide a hostname?
• Here is an annotated screenshot of what my hosts file now looks like, with some questions penciled in.
  
  

Does this /etc/hosts file look good to you? Is there anything thing else that should be in here? Or not be in here?

Thanks again!

[Daxtorim]

@mx2k

Since it has a static IPv6 local address, I have added the IPv6 it to /etc/hosts on Pi-Hole.
Is this a valid solution to provide a hostname?

Yes. Alternatively, you could use the GUI option under Local DNS > DNS Records. Under the hood, that will just save it to /etc/pihole/custom.list, which has the same format as /etc/hosts and serves the exact same purpose. But using /etc/hosts directly is perfectly fine too.

---

should I also define the FritzBox router in here?

If you are also conditionally forwarding the local domain, i.e. you also added server=/fritz.box/10.1.1.1 to your custom config file, it isn't necessary. Pi-hole doesn't use the hostnames it got via PTR records to resolve queries for those hostnames. It will still forward those queries upstream, so you probably want anything that ends with fritz.box to be forwarded to the FRITZ!Box as well.

---

For the NAS, I need to define FQDN + alias. If not, \\mx-nas or http://mx-nas do not resolve

I can't replicate that (I tried). My first idea was that maybe your (file-)browser doesn't automatically add .fritz.box, but you say that it works fine for http://rpi-dnshole/. My next idea is that maybe the Fritz!Box's DNS Rebind Protection could play a role. Although, on second thought, by explicitly creating a DNS entry for the NAS you avoid asking the router entirely and it's rebind protection shouldn't matter.
I don't know why one need an alias but not the other.
Does http://mx-nas.fritz.box/ resolve at least? Or does the NAS not respond at all without the alias?

---

Do I need to define IPv6 multicast addresses here?

If you have any additional multicast groups, yes. If not, well, you have nothing that needs to be defined.

---

@mx2k

Does this /etc/hosts file look good to you?

Aside from the spelling error this looks fine to me.

[mx2k]

Hello again.

@Daxtorim

If you are also conditionally forwarding the local domain, i.e. you also added server=/fritz.box/10.1.1.1 to your custom config file, it isn't necessary. Pi-hole doesn't use the hostnames it got via PTR records to resolve queries for those hostnames. It will still forward those queries upstream, so you probably want anything that ends with fritz.box to be forwarded to the FRITZ!Box as well.

I have added the conditional forwarding for the fritz.box domain to the custom config.

---

Today I see that IPv6 hostnames back to not being resolved again. The only other "change" that occured yesterday was a reboot of the FritzBox. I am not sure if this is at all related to the conditional forwarding, or a FritzBox DHCPv6 issue, but here's what I found out.

As said, mx-net-pc IP6v not resolving today. Yesterday, both has the hostname displayed.

Then I had a look in the FritzBox and what do I see:

The mx-net-pc client simply missing the fd00:1111 ULA address.

I mean, FritzBox assigned that ULA to the client, and the client is communicating via that ULA in the LAN, so it should be known to the device actually assigning the IPs via DHCP leases. Anyways, I made a ticket at AVM to be sure, maybe there's some fiddling with my routers IPv6 settings required.

My conclusion: If fritzBox doesn't know that [fd00:1111::9cfa:7536:f41b:8c79] is the IPv6 of mx-net-pc, how would Pi-Hole know.

I noticed that happening earlier, sometimes name resolution worked sometimes not. I think I might have identified the cause of the issue now, but not yet what would the FritzBox forget its ULA assignments. Maybe some network misconfiguration the cause?

---

Finally some general Pi-Hole network table question.

• I have some Tuya Wifi Lightbulb.
• In FritzBox DHCP "always assign the same IPv4 to this device" is on.
• It had 10.1.1.203 assigned via the above option, which I needed to change.
• Somehow flushing DHCP lease got it 10.1.1.37 assigned.
• The new "static/preferred" DHCP IP 10.1.1.160 only got correctly assigned after rebooting the actual lightbulb, not the DHCP server.
• So all this was yesterday and in between the FritzBox and Pi-Hole dnsmasq were restarted. The FTL database was flushed to give me a fresh start dashboard.
• Today I look in Pi-Hole network table, and Pi-Hole thinks all 3 above mentioned IPs are all assigned the the same host. Makes sense so far, since yesterday the host was available under each of them for a few minutes, while I was changing the settings.

Soo, I wonder:

• How does Pi-Hole still think to know about the flushed leases 10.1.1.203 and 10.1.1.37 IPs? Like Pi's database and net table flushed, DHCP server was rebooted, so all old leases should have been flushed out of the network.
• Those IPs are currently not assigned at all, so where is that data displayed in network table coming from?

[Daxtorim]

@mx2k

I mean, FritzBox assigned that ULA to the client, and the client is communicating via that ULA in the LAN, so it should be known to the device actually assigning the IPs via DHCP leases.

Was it really the Fritz!box which assigned the ULA or did you set a static IP address on the machine? I don't use DHCPv6 to assign IPs, so I don't know how that works with a Fritz!Box; but for SLAAC, mine has a setting that, by default, makes it only advertise a ULA prefix if there is no IPv6 internet connection (i.e. there is no GUA for the device). I assume that will also affect which addresses are assigned via DHCPv6.
Fritz!box 7560: Netzwerk > Netzwerkeinstellungen > IPv6-Adressen

But AVM will know more about that than me.

---

@mx2k

DHCP server was rebooted, so all old leases should have been flushed out of the network

The leases, yes. The clients IP addresses, no. There is no widely implemented signal that could tell a client to renew its lease. You can reboot the DHCP server all you want, the clients got an IP address earlier and will only get a new one when they ask for one. The easiest way to get a new IP to a client is to reboot the client as you found out.

@mx2k

• How does Pi-Hole still think to know about the flushed leases 10.1.1.203 and 10.1.1.37 IPs? Like Pi's database and net table flushed, DHCP server was rebooted, so all old leases should have been flushed out of the network.
• Those IPs are currently not assigned at all, so where is that data displayed in network table coming from?

They are coming from the arp-table of Pi-hole's host machine. In addition to the existing query database, Pi-hole will look through the arp-table to make connections between IP and MAC addresses. With ip neigh you can view all currently known IP-MAC-associations. You need to flush that cache as well, but by doing so, you lose all those IP-MAC-associations and the network overview will be populated with a bunch of lone IP addresses from the query database until those IPs are used again and can be grouped by corresponding MAC address. Which sucks if your clients use Privacy Extensions and you are left with IPv6 addresses that will never be used again.
Flushing the network table is kind of useless as it is, you really need to start from zero to get clean network overview again.

Here is a "one-liner" to do that:
(stop Pi-hole, back up database, flush arp-table, start Pi-hole again)

sudo service pihole-FTL stop \
&& sudo mv "/etc/pihole/pihole-FTL.db" "/etc/pihole/pihole-FTL.db.bak.$(date '+%F')" \
&& sudo ip neigh flush all \
&& sudo service pihole-FTL start

Of course replace the path to the database if necessary.

[mx2k]

Thanks for your feedback.

Pi-Hole install transferred from Pi 2 to Pi 3, IPv6 wasn't static somehow.

I had to move my Pi-Hole installation from Raspberry Pi 2 to a Pi 3 due to technical issues with the Pi 2. The SD card image transfer worked flawless, except one thing:

• When my ISP became IPv6 enabled 2 weeks ago, I re-ran setup for static IP's via pihole -r.

• I have booted up the new Pi 3 with a dd image of Pi-Hole, and it got a different ULA assigned. Somehow only IPv4 configured with pihole -r was saved properly as static.
  I guess it makes sense, since its a unique address, and a different Pi gets a different unique address. Which then is the static address of exactly that one device.

• Is it possible to set an easy to remember static IPv6 via config files? Like would something like fd00:1111::1 be possible in my case? (Am I typing this right? Would the long form be fd00:1111:0000:0000:0000:0000:0000:0001)

• On the FritzBox, I have provided the Pi 3 new IPv6 within FritzBox so DHCP clients update their DNS server address to use. This seems to work already using the new IP. Should it say server: UnKnown here? With the capital K in the middle of the word, that maybe unbound telling its name in a nerdy way?
  

  

• On the Pi 3, I have updated the new IPv6 in /etc/pihole/setupVars.conf
  Is there any place else in the config files where the changed IPv6 has to be updated? I'm not sure but it seems the IPv6 defined here is not actually used as the IP to be set for eth0 during boot.

• Some issue I noticed. Network table was broken after booting the transferred SD card image on the Pi 3: unknown error occurred while loading the data. This is just FYI, running your reset db and arp one-liner fixed it and network table works. Might be a bug or something.
  

  

I think my DHCPv6 is messed up...

@Daxtorim

Was it really the Fritz!box which assigned the ULA or did you set a static IP address on the machine?

That's a really good question. At least I did not type any manual IPv6 addresses into some clients config files, so no, don't think I use anything static (only exception being the NAS as described in previous posts)

Maybe I have to not use the ULA, but the other address starting with the ISP's router prefix 2a00:6020, even for local networking. The 2a00: address is always known by FritzBox for each client, in contrary to the previously described experience with fd00 ULA not always showing up in the client details.

Anyways, there's a lot of wonky leftover from some IPv6 local networking experiments from the time before my ISP has been native IPv6 enabled. And I think my DHCPv6 settings might be completely off and might explain the "weird" behavior.

I really think those must be set to provide DNS, IA_PD and IA_NA, so the DHCP does actual IPv6 assignment and not only provide DNS server to clients. It would make sense from my point of view, since now with native v6 ISP, I actually got those prefixes for the Fritzbox to provide to clients.

Well, that was also only FYI, going to discuss the FritzBox basic settings with ISP and AVM, but directly leads me to another general IPv6 question.

The above DHCPv6 settings tell me, FritzBox DHCP currently is not assigning actual IPv6 addresses to the clients, but only the DNS server.

• Then what exactly assigned fd00:1111: ULA?
• DHCPv6 is only providing the DNS. Is FritzBox maybe assigning those ULAs in a different way?
• Is FritzBox maybe not telling/assigning a client which ULA to use, but rather asks the client "hey here is my prefix fd00:111, please tell me your ULA within that prefix"?
• And mostly, how comes Pi-Hole still got a 2a00:6020 address from the ISP prefix space? There must be some other way this global address is defined and assigned, since it can't come from DHCP with my "provide only DNS" config.

Edit: And of course just now (Pi-Hole uptime ~3hrs), the FritzBox automagically knows all the fd00:1111 ULA again and the Pi-Hole IPv6 name resolution is back working. This wasn't the case when I started typing this post, then all the v6 hostnames were still unresolved in stats. This random behavior is driving me nuts

[Bucking_Horn]

@mx2k

I had to move my Pi-Hole installation from Raspberry Pi 2 to a Pi 3 due to technical issues with the Pi 2. The SD card image transfer

Don't shift SD cards or images around between different CPU types!

Doing so is asking for trouble, as binaries may be compiled for a specific CPU's instruction set. You may encounter slow performance, inexplicable failures or outright crashes.

@mx2k

Is it possible to set an easy to remember static IPv6 via config files?

I'd advise against setting static IPv6 addresses on device, unless you are sufficiently familiar with IPv6 and fully aware of the associated consequences.

For your Pi-hole machine, try instead to set a fixed IPv6 interface identifier for that device in your Fritzbox.

Be aware that such an interface identifier only ever gets assigned for those clients requesting it via Stateful DHCPv6. Most clients won't by default, and some never will (e.g. Androids).

This is also relevant for your question:

@mx2k

Is FritzBox maybe assigning those ULAs in a different way?

The majority of IPv6 clients constructs their IPv6 addresses autonomously by combining an IPv6 prefix (procured through Stateless DHCPv6 or RAs) with an interface identifier computed by the device itself using SLAAC.

In that same sense, ULAs don't get assigned.
A client will use IPv6 prefixes as available in your network (i.e. public and ULA prefixes).
It will then combine each such a prefix with any interface identifier it sees fit.
This may or may not include a fixed interface identifier defined in your router.
Even if it does, you could expect your client to have more than one IPv6 address for each prefix (apart from link-local).

@mx2k

On the Pi 3, I have updated the new IPv6 in /etc/pihole/setupVars.conf
Is there any place else in the config files where the changed IPv6 has to be updated?

In general, don't change setupVars.conf by hand.
Pi-hole's installation, update, repair and reconfigure scripts will read and write information from and to that file.
To reconfigure Pi-hole for changed network settings (i.e. a changed IP in your case), run pihole -r and choose Reconfigure.

[mx2k]

@Bucking_Horn

I'd advise against setting static IPv6 addresses on device, unless you are sufficiently familiar with IPv6 and fully aware of the associated consequences. Isn't fd00: the local only address space like 10.0.0.0/8 or 192.186.0.0/24 with IPv4?

Ok, I will do so, since I only got a very basic understanding of IPv6 and your answer concluder there might be security implications involved even when setting a static local IPv6. I will refrain from that step for now.

@Bucking_Horn

For your Pi-hole machine, try instead to set a fixed IPv6 interface identifier for that device in your Fritzbox.

Pi-Hole seems to have requested the identifier.

• I wonder how to use it as a server address in my network? It has only the fe80: address assigned and I assume that's the fixed interface ID for this device.
• However, as I understand, fe80: is the link local / loopback address in IPv6.
• I would totally use that interface ID, but Pi-Hole/DNS doesn't seem to work on the fe80: addresses:
  
  
• Any tutorials out there for Pi-Hole and Local Interface ID communication?
• Just need a coarse direction pointer of what I gotta do next in order to use the Interface ID as the static Pi-Hole server address.

@Bucking_Horn

The majority of IPv6 clients constructs their IPv6 addresses autonomously by combining an IPv6 prefix (procured through Stateless DHCPv6 or RAs) with an interface identifier computed by the device itself using SLAAC.

Thanks for explaining this. Guess I need to read some topics on SLAAC.

@Bucking_Horn

Don't shift SD cards or images around between different CPU types!

• What is the proper way to this? Some RasPi FAQ stated this is common practice. But I'll just consider myself lucky that I haven't run into any issues (yet).

• I'd have no idea how to backup a running linux live system if not by dd to image SD to network share. Any tips or articles how this can be done better?

• For the Pi-Hole only I could have done a fresh installation on the Pi 3 and restore settings via Teleporter. That just doesn't include ufw, openvpn, netdata configurations and I would be sad if I lose them.

• How does the linux pro backup a Pi-Hole with all installed apps and settings so it could be restored to a fresh Raspberry Pi OS installation?

[mx2k]

Further, I might have found out why my NAS hostname mx-nas doesn't resolve properly at the moment and I get the name not resolved browser error when trying to access its web interface.

What the NAS is doing:

What other devices are doing:

NAS hostname gets NXDOMAIN response. Other devices get IP response as intended. Where to most likely look for the cause - Pi-Hole, NAS or Router?

[mx2k]

I ran pihole -d on the Pi 3.

All looks good to me except some some warnings in the pihole-ftl.log.
Warning: Found unknown status 14 in long term database!
Maybe you could have a quick look at the debug token as well: https://tricorder.pi-hole.net/wcshl2f36c

Also it was a good idea to do pihole -r again, the new Pi 3 IPv6 wasn't updated in /pihole/local.list by editing setupVars.

[yubiuser]

@mx2k

Warning: Found unknown status 14 in long term database!

This has been reported and a fix is in the pipeline

Warning: Found unknown status 14 in long term database!