Possible method for IPv6

[dschaper]

What do you think of using Unbound in a split-horizon configuration to serve records pointing to localhost? There's a section of an article at calomel called Dnsspoof or 'Split horizon' with Unbound DNS that may help. That would mean another package though.

[jacobsalmela]

I'd rather not use another pacakge/DNS server, but I'll look into this more as I haven't heard of it before.

[dschaper]

Just to update this thread, I already mentioned in another thread some progress on this. dnsmasq works just fine as a resolver, no need to switch to unbound. (There may be performance improvements with another resolver package, but that's to be determined I guess.) Thanks to how DNS works the process isn't too difficult, it's a two step process. First get the IPv6 address of the PiHole, (ip -6 route get 2001:4860:4860::8888 should return the correct address in the same scheme as the current ip get code for IPv4 counterpart.) and second, configure the host systems to use that address as the resolver. No other changes to the PiHole is needed, it can still return it's IPv4 A record and possibly a NODATA-IPv6 instead of the AAAA record.

[jacobsalmela]

Do we don't need dnsmasq to listen over ::1?

What about the people who are using DHCP options on their router? It seems this would not work for them.

[dschaper]

The DHCP configuration is going to be the toughest part of the process I think. I'll do a quick write-up of how I did IPv6 with a Windows 10 box in a post (It might be kind of long, lots of code snippets since I'm running dig to test the resolver). But the beauty of DNS resolution and IPv6 is that IPv4 servers just need to serve up the AAAA records, so an IPv4 resolver is fully IPv6 compliant. Hopefully the write-up will explain a little better...

[dschaper]

Okay, here we go...

Starting out with a fresh install of Raspbian Jessie (Lite Version) and a fresh install of PiHole via curl -L install.pi-hole.net | bash. No other changes made to the Raspberry Pi or PiHole.

Client system is a Windows 10 box. By default my IPv6 is as follows (some bits are masked because I'm using the pubilc IPv6 addresses for both my Pi and my Windows 10 box.)

 IPv6 Default Gateway: fe80::a021:b7ff:fe9b:4b24%9
 IPv6 DNS Server: fe80::a021:b7ff:fe9b:4b24%9

First to test if ads are showing, I go to osxdaily.com and get a ton of ads, so I know things are at a baseline.

On the Pi via SSH I run the following commands:

Find the route my Pi is using to get to the IPv6 world by getting the route to Google's IPv6 DNS server:

ip -6 route get 2001:4860:4860::8888

This returns a reply of:

2001:4860:4860::8888 via fe80::a021:b7ff::4b24 dev eth0 src 2605:e000:3c8e:ca00:6a0:1740::2543

What I'm looking for is the src address, that's my IPv6 public routeable address, and the address I'm going to use to input into the Windows 10 box as the IP address for the IPv6 DNS resolver.

So I go to the Windows 10 box, and for IPv6 settings I change my DNS resolver to the public IP address I just got.

After the changes, my IPv6 is as follows:

 IPv6 Default Gateway: fe80::a021:b7ff:fe9b:4b24%9
 IPv6 DNS Server: 2605:e000:3c8e:ca00:6a0:1740::2543

(Again, some bits have been snipped for this display...)

Now, I bring up a command window in Win 10 and flush the DNS cache to make sure I'm not pulling old data:
ipconfig /flushdns

Now another visit to osxdaily.com and notice the ads are pretty much all gone.

You can watch the /var/log/pihole.log and see that A records are being served via /etc/pihole/gravity.list and AAAA records are either served as NODATA-IPV6 or as the IPv4 address.

This was just with IPv6 change, I actually left the IPv4 resolver to the non-pihole DNS resolver address and ads were still blocked.

[dschaper]

For the DHCP server settings, it depends on how you have the network set up.

If you are using the DHCP server as the DNS server and then setting the DHCP server to use PiHole as its resolver then I don't know if there would be any changes. If you want the DHCP server to give out an IPv6 resolver when it does DHCPv6 then you'd need to either set the DNS server manually if there is an option for IPv6 DNS servers, or you could set the DHCP additional options for option 23 to the IPv6 address.

Here's a link for a list of the options settings. https://www.incognito.com/tips-and-tutorials/dhcp-options-in-plain-english/

[dschaper]

Hmmm, things seem to be a bit different that I expected. It looks like what my setup was doing was using my IPv6 resolver to grab A and AAAA records from my main DNS server that doesn't have any blocking, so when I changed the IPv6 resolver to the Pi-Hole box, then it started to pick up the blocked A records like it should. AAAA records are still getting through in some places, as seen below:

google.com
Server: UnKnown
Address: 2605:e000:3c8e::a1ab:dafd

Name: google.com
Addresses: 2607:f8b0:4007:809::200e
192.168.1.182

The A record is correct and blocked, but that AAAA comes through.

[dschaper]

Alright, it looks like the way to solve the problem is to add to the gravity_hostFormat() so that two entries are made for each domain. As a test I have:

 function gravity_hostFormat() {
    # Format domain list as "192.168.x.x domain.com"
    echo "** Formatting domains into a HOSTS file..."
    sed "s/^/$piholeIP /" $piholeDir/$eventHorizon > $piholeDir/$accretionDisc
    sed "s/^/::1 /" $piholeDir/$eventHorizon >> $piholeDir/$accretionDisc
    # Copy the file over as /etc/pihole/gravity.list so dnsmasq can use it
    cp $piholeDir/$accretionDisc $adList

Which gives a result of

google.com
Server: UnKnown
Address: 2605:e000:3c8e::a1ab:dafd

Name: google.com
Addresses: ::1
192.168.1.182

[jacobsalmela]

@dschaper Interesting. I did something similar a while back, but did it all in one line with awk. I had forgotten about it until now. I'm not sure which method would work best. But thinking back, I do remember that it did start blocking IPv6 ads...I think at the time, I just wasn't ready for that many changes and just decided to work with IPv4 and make it as stable as possible.

One thing that comes to mind is that we decided not to use the IPv4 loopback in the hosts files, which is essentially what the ::1 is in the IPv6 world. I wonder if we will run into some of the same issues as before...

[dschaper]

The ::1 is just a temporary hack to test to see if AAAA records work, in production it would need to be the IPv6 address that is detected with the ip -6 route get 2001:4860:4860::8888 routine.