As we have noted, we think the connectivity problem lies on the Pi-hole host platform.
Why are you trying to start dnsmasq? Dnsmasq is already embedded in FTL and running on port 53. If you try to launch a new instance, you will get a port conflict on port 53.
because dns server was not running so i suspected that it was conflicting with systemd and causing my tailscale connect to fail as well so i disabled it...and now after 15min or so my pihole server is in shambles back to no dns running and possible what you just suggested
so i got pihole-FTL back via FTL failed to start due to failed to create listening socket for port 53: Address already in use (by dnsmasq) - #2 by jfb
so you mean pihole has something going on ?
its fetching now, but not all
So i just downloaded the new pihole sys update and changed the upstream dns back to my unbound/pihole default settings, ran pihole -r
and i'm getting connection refused on now 70 adlist out of 100, before it was about able to pass and retrieve 40/60.
so i ran
input:
curl -v https://github.com
return:
* Connected to github.com (140.82.121.3) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=github.com
* start date: Mar 7 00:00:00 2024 GMT
* expire date: Mar 7 23:59:59 2025 GMT
* subjectAltName: host "github.com" matched cert's "github.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo ECC Domain Validation Secure Server CA
* SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: github.com]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x5555a2a18af0)
> GET / HTTP/2
> Host: github.com
> user-agent: curl/7.88.1
> accept: */*
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 200
< server: GitHub.com
< date: Wed, 30 Oct 2024 21:25:34 GMT
< content-type: text/html; charset=utf-8
< vary: X-PJAX, X-PJAX-Container, Turbo-Visit, Turbo-Frame, Accept-Language, Accept-Encoding, Accept, X-Requested-With
< content-language: en-US
< etag: W/"2f1ceca4022680011b0bcc25674e6c19"
< cache-control: max-age=0, private, must-revalidate
< strict-transport-security: max-age=31536000; includeSubdomains; preload
< x-frame-options: deny
< x-content-type-options: nosniff
< x-xss-protection: 0
for context this user has multiple files and i'm using at a minimum 3 of them and only 1 gets parsed and retrieved. so i still don't know whats going on. i even changed to a different WP3 address, and yes i can open each url perfectly
input:
curl -v https://raw.githubusercontent.com/hagezi/dns-blocklists/refs/heads/main/wildcard/doh-onlydomains.txt
returns:
* Connected to raw.githubusercontent.com (185.199.109.133) port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.io
* start date: Mar 15 00:00:00 2024 GMT
* expire date: Mar 14 23:59:59 2025 GMT
* subjectAltName: host "raw.githubusercontent.com" matched cert's "*.githubusercontent.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
* SSL certificate verify ok.
* using HTTP/2
* h2h3 [:method: GET]
* h2h3 [:path: /hagezi/dns-blocklists/refs/heads/main/wildcard/doh-onlydomains.txt]
* h2h3 [:scheme: https]
* h2h3 [:authority: raw.githubusercontent.com]
* h2h3 [user-agent: curl/7.88.1]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x55560c174af0)
> GET /hagezi/dns-blocklists/refs/heads/main/wildcard/doh-onlydomains.txt HTTP/2
> Host: raw.githubusercontent.com
> user-agent: curl/7.88.1
> accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 200
< cache-control: max-age=300
< content-security-policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
< content-type: text/plain; charset=utf-8
< etag: "5149d0e917322b3a011d79b254c0a13293af00201a34a99997affef7069bfae1"
< strict-transport-security: max-age=31536000
< x-content-type-options: nosniff
< x-frame-options: deny
< x-xss-protection: 1; mode=block
< x-github-request-id: CDA7:27857F:2933FA:33CB9B:6722A3CF
< accept-ranges: bytes
< date: Wed, 30 Oct 2024 21:23:27 GMT
< via: 1.1 varnish
< x-served-by: cache-adl2040023-ADL
< x-cache: MISS
< x-cache-hits: 0
< x-timer: S1730323407.497923,VS0,VE296
< vary: Authorization,Accept-Encoding,Origin
< access-control-allow-origin: *
< cross-origin-resource-policy: cross-origin
< x-fastly-request-id: b970b496722bcf99e3f9b6c238c02bba9becaa51
< expires: Wed, 30 Oct 2024 21:28:27 GMT
< source-age: 0
< content-length: 25601
<
# Title: HaGeZi's Encrypted DNS Bypass DNS Blocklist
# Description: Prevent methods to bypass your DNS, blocks encrypted DNS only
# Note: To ensure the bootstrap is your DNS server: Redirect standard DNS outbound (UDP 53) to an internal server. Block all DoT/DoQ (TCP/UDP 853) outbound.
# Homepage: https://github.com/hagezi/dns-blocklists
# License: https://github.com/hagezi/dns-blocklists/blob/98a11fde537193b56f3f97da9cacdf3c8594fe59/LICENSE
# Issues: https://github.com/hagezi/dns-blocklists/issues
# Expires: 7 days
# Last modified: 28 Oct 2024 23:55 UTC
# Version: 2024.1028.2355.11
# Syntax: Domains (without subdomains)
# Number of entries: 1427
This rules out DNS resolution from Pi-hole as being a problem.
Pi-hole is the DNS server. Once it resolves the domain name to an IP, then it's done with that request.
When we update gravity, we use the underlying OS to retrieve the files and then we import them.
If the connection cannot be made to the adlist server once the IP is identified, or if data won't download from that URL, that is a problem outside of Pi-hole.
much appreciated your assistance
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.