Gravity run cannot access lists after upgrade to v6

Help
1

Description

So Pi-hole has been running great on the previous version. Now about two weeks ago when I repulled the latest tag it was upgraded to the new v6. Since then my gravity runs are unable to access the block lists and I cannot figure out why.

Maybe someone here could help me with this. I would be grateful.

Setup

  • Home Server running Ubuntu Server 24.04.2
  • Pi-hole running in docker created from docker-compose.yaml

My docker-compose.yaml

pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      TZ: 'XXX'
      WEBPASSWORD: ${PIHOLE_PW}
      IPV6_ADDRESS: 'xxxx::xxxx:xxx:xxxx:xxxx/64'
      AAAA_QUERY_ANALYSIS: yes
      FTLCONF_dns_listeningMode: "all"
      FTLCONF_dns_upstreams: "8.8.8.8"
    volumes:
      - './pihole/etc-pihole:/etc/pihole'
      - './pihole/etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped

Repro Steps

  • Go to Tools > Update Gravity
  • Click on the "Update" button

Expected Behaviour:

  • Update goes through
  • Block lists are updated
  • No errors are reported

Actual Behaviour:

Page is stuck on:

  • [✗] DNS resolution is currently unavailable*
  • [i] Waiting until DNS resolution is available..............*

Also Pi-hole diagnosis reports "X was inaccessible during last gravity run" for all block lists (X). Example:
WARNING List with ID 1 (https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts) was inaccessible during last gravity run

Debug Token:

Will the debug token expose my IP? Maybe the provided information is sufficient for any ideas. Otherwise I will provide this as well.

2

Your environment variables are a mixture of v5 and v6 options.

Please refer to Upgrading from v5.x - Pi-hole documentation and adjust as required.

Also, consider passing a public DNS server into your container:

services:
    (…)
    pihole:
        ports:
        (…)
        environment:
        (…)
        volumes:
        (…)
        dns:
            - 127.0.0.1
            - 1.1.1.1
        (…)
3

Hello @Bucking_Horn. Thanks for your reply! I see you're even a moderator, today must be my lucky day :slight_smile:

I'm not that experienced with Pi-hole and networking. So your answer brought up a few new questions for me.

So after the errors appeared that's exactly the first thing I tried to do, that's why I already have some variables from the v6. The thing is that the page does not mention the variables IPV6_ADDRESS and AAAA_QUERY_ANALYSIS. So I was assuming they stayed the same. If not, do you have an idea how I could maybe find out the new v6 name for these variables, since they do not exist in the documentation?

I did not know about the new top-level argument dns in the compose structure. What exactly is that referring to? I thought we set the DNS upstream server with FTLCONF_dns_upstreams?

Regarding 127.0.0.1: I'm not sure why I should be pointing to the container itself as the DNS server.

Regarding 1.1.1.1: Not sure what the difference is compared to using 8.8.8.8, also shouldn't this be passed via FTLCONF_dns_upstreams?

4

Note about debug log:

When you run pihole -d a debug log is generated and uploaded (if you answer "Y") to a secure server.
Only 8 or 9 people in the whole planet have permission to access this server (and probably only 1 or 2 moderators will actually read your log to help you).
The log is automatically purged after 48 hours.

You are asked to post here only the Token generated when you upload the log. The log contents are never exposed.

Also, the debug log tries to retrieve only the information needed to solve Pi-hole issues.

Usually only the local network IPs are shown.

1 Like
5

This option (dns:) is not a Pi-hole option. This is a docker option.

You are actually saying docker to use 127.0.0.1 and 1.1.1.1 as DNS servers for the container.
Since and docker runs on the host, this means 127.0.0.1 is the host machine, not the container itself.

6

Thanks for the clarification.

Ok, so I figured out these two things myself. The dns argument affects the container itself. This was somehow not needed in v5 and I've never seen this before on any other docker compose file either. Anyways, using this solved my issue. Now everything works as expected again. Also regarding the DNS severs: there are simply several servers and it apparently doesn't hurt to use several of them I guess.

I'm still not sure what to do about the v5 environment variables that do not appear in the documentation or why I would add my local IP to the dns section.

But since everything is running well again I guess my issue was solved and I want to show my solution if anyone ever has the same issue. This is the working docker-compose.yaml (also includes information found out through later comments):

pihole:
    image: pihole/pihole:latest
    container_name: pihole
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      TZ: 'XXX'
      FTLCONF_webserver_api_password: ${PIHOLE_PW}
      FTLCONF_dns_listeningMode: "all"
      FTLCONF_dns_upstreams: "1.1.1.1;8.8.8.8;8.8.4.4"
    volumes:
      - './pihole/etc-pihole:/etc/pihole'
      - './pihole/etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped
    dns:
      - "1.1.1.1"
      - "8.8.8.8"
      - "8.8.4.4"
7

I can't recall IPV6_ADDRESS to have ever been a valid Docker environment variable?

Is something not working without that option?
If not, then you may just omit it.

Otherwise, you may consider FTLCONF_dns_reply_host_IPv6, probably in conjunction with FTLCONF_dns_reply_host_force6: true.

AAAA requests are analysed by default, and also note that WEBPASSWORD is to be replaced by FTLCONF_webserver_api_password.

That's not new at all - it's a standard Docker element, defining DNS servers to be used by the container itself.
While Pi-hole's DNS server will only use the very upstream DNS servers you configure for it (e.g. via FTLCONF_dns_upstreams), the pihole scripts will call command-line tools like curl, dig or git, which in turn will use whatever DNS server is configured for the system it runs on.

In case of a Docker container, Docker would usually inject the host's resolv.conf into a container. Depending on a conatiner's network mode, that may not happen, or the contents may only supply nameservers inaccessible from the container, resulting in a lack of DNS resolution for commands run from inside the container (while Pi-hole's DNS server continues to be fully operational).

To avoid this, it is a good idea to explicitly provide nameservers you know to be operational.
My suggestion was to use Pi-hole itself and a public DNS server, but you are free to change that as you prefer, of course. :wink:

1 Like
8

Wow OK, so I actually never needed these two variables in the first place. Good to know! I updated the docker-compose.yaml in the solution.

I did initially have trouble with IPv6 connections through Pihole. I tried out some approaches and I guess these were the remnants of that.

I guess everything is solved and resolved then! Thank you so much for your help! Since we are at it though: do you see anything I could improve on my docker-compose file or anything I maybe should look into now that v6 is out? Always happy to learn something new.

9

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.