Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ubuntu/debian: DNS is NOT listening but names are resolved #962

Closed
6 tasks done
edgd1er opened this issue Jan 3, 2022 · 12 comments
Closed
6 tasks done

ubuntu/debian: DNS is NOT listening but names are resolved #962

edgd1er opened this issue Jan 3, 2022 · 12 comments

Comments

@edgd1er
Copy link
Contributor

edgd1er commented Jan 3, 2022

This is a: RUN Issue with a suggested solution and a workaround

Details

When running on ubuntu 20.04 LTS or debian 10/Buster hosts, pihole status returns DNS is NOT listening, though names are properly resolved. Only pihole status is improperly detected.

root@b5c283006144:/# pihole status
  [✗] DNS service is NOT listening

root@b5c283006144:/# netstat -tplun
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.11:35055        0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::53                   :::*                    LISTEN      -                   
udp        0      0 127.0.0.11:42081        0.0.0.0:*                           -                   
udp        0      0 0.0.0.0:53              0.0.0.0:*                           -                   
udp6       0      0 :::53                   :::*                                -                 
  
root@b5c283006144:/# lsof -Pni:53
root@b5c283006144:/#

Related Issues

  • I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

  1. Environment data

  2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here
    use docker-compose-example.yml as exists in project.

  3. any additional info to help reproduce
    open browser at admin page, up left, read dns status.

These common fixes didn't work for my issue

  • I have tried removing/destroying my container, and re-creating a new container
  • I have tried fresh volume data by backing up and moving/removing the old volume data
  • I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
  • I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
  • I have tried running without my volume data mounts to eliminate volumes as the cause

If the above debugging / fixes revealed any new information note it here.
Add any other debugging steps you've taken or theories on root cause that may help.

pihole status is based on lsof -Pni:53's results. For latest os, app armor denies access to ptrace. hence the result of lsof is "".

I've found the workaround reading theses:

Suggestion:

  • use netstat (net-tools package) to detect opened ports.(may concern pi-hole/pi-hole project, but only needed for docker)

Workaround:

  • start container with SYS_PTRACE capabilities.
root@88e3ca25d127:/# pihole status
  [✓] DNS service is listening
     [✓] UDP (IPv4)
     [✓] TCP (IPv4)
     [✓] UDP (IPv6)
     [✓] TCP (IPv6)

  [✓] Pi-hole blocking is enabled

root@88e3ca25d127:/# netstat -tplun
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      500/pihole-FTL      
tcp        0      0 0.0.0.0:4711            0.0.0.0:*               LISTEN      500/pihole-FTL      
tcp        0      0 127.0.0.11:38761        0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      487/lighttpd        
tcp6       0      0 :::53                   :::*                    LISTEN      500/pihole-FTL      
udp        0      0 127.0.0.11:54280        0.0.0.0:*                           -                   
udp        0      0 0.0.0.0:53              0.0.0.0:*                           500/pihole-FTL      
udp6       0      0 :::53                   :::*                                500/pihole-FTL      

root@88e3ca25d127:/# lsof -Pni:53
COMMAND   PID   USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
pihole-FT 500 pihole    4u  IPv4 530645587      0t0  UDP *:53 
pihole-FT 500 pihole    5u  IPv4 530645588      0t0  TCP *:53 (LISTEN)
pihole-FT 500 pihole    6u  IPv6 530645589      0t0  UDP *:53 
pihole-FT 500 pihole    7u  IPv6 530645590      0t0  TCP *:53 (LISTEN)
@runningwithcode
Copy link

I'm having exactly the same problem. I've upgraded my pihole instance in docker (pulling image with latest tag) and after restarting status is showing DNS service is NOT listening. But all my queries are resolved correctly. Before upgrading it (my latest docker image was 2021.11).

@PromoFaux
Copy link
Member

This will be sorted in a future release of the web interface - just waiting for that one, and we will tag a new docker container.

You can see if fixed in the nightly container, which draws from all the development branches of the three Pi-hole components - but, beware that running that version of the container is not guaranteed to be stable

@manfromdownunder
Copy link

Just adding my two cents here. The new (latest) image released 4 hours (DIGEST:sha256:6e53abc57c20705e39700ac36cfaf8bd2da58435a5c1b4b46b5d9c44f2f22d48) ago was giving me DNS issues also. The DNS service fails to start. Rolled back to 2021.12.1 working as expected again.

@PromoFaux
Copy link
Member

The DNS service fails to start.

If this is the case, then it is not the same as the OPs issue, so please open a new issue with more details, including logs etc asked for in the issue template.

If the queries are resolving, but the web interface says that it is not active, then it is a cosmetic issue that will be fixed in a figure release.

@diamondsw
Copy link

Although this is largely a cosmetic issue, since Pi-hole believes that DNS is already disabled it may interfere with monitoring tools. I noticed this evening that my Pihole instances appeared to be "offline" even though everything was running as expected. This in turn interferes with remote scripts to turn on/off Pi-hole, as they get the wrong status and send the wrong requests.

While this is not a major issue by any means, is there an expected ETA for release, since it has already been identified and fixed in the development branch?

@PromoFaux
Copy link
Member

Ah, it's affecting it via API, too. OK - I'll chat with the guys today and see if we can do a release on the main components.

@pralor-bot
Copy link

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pihole-dns-not-running/52206/2

@PromoFaux
Copy link
Member

Also to note here, workaround as mentioned in the OP:

start container with SYS_PTRACE capabilities.

@pralor-bot
Copy link

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/dns-service-not-running-on-raspberry-pi-4b/52195/5

@pralor-bot
Copy link

This issue has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-dns-service-not-running/52222/2

@edgd1er
Copy link
Contributor Author

edgd1er commented Jan 5, 2022

possible duplicate with #734

workaround added to doc in PR #966

fix being tested in branch tweak/ss and tweak/netstat in pi-hole/pi-pihole project

temp fix:

  • set DNSMASQ_USER as root (but defeat less root use in container)
  • add SYS_PTRACE to docker run options.

@PromoFaux
Copy link
Member

possible duplicate with #734

Yeah, absolutely. I hadn't appreciated the scope of the issue until last night, and realised it's more than just a cosmetic issue. Will close this one in favour of #734 as they are both reporting the same thing (I'll pin that issue until it is fixed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants