Apparent reliance on AAAA records for updates

Help
1

Expected Behaviour:

In a non-IPv6 environment be able to update / run pihole updatecheck without error when AAAA records are blocked and pihole is in default / null blocking mode.

Core v6.4.3 FTL v6.7 Web interface v6.6

OS : Ubuntu server 26.04 LTS (virtual machine)

Hardware : Intel based mini-pc running Proxmox

Docker : none

Actual Behaviour:

With IPv6 disabled via netplan (so IPv6 is known on loopback but not of any other interface) and IPv6 blocked / denied / disabled on all intermediate network equipment, when running pihole updatechecker or pihole -up the updates fail when AAAA records are replied with null but A records are not.

fatal: unable to access ' https://github.com/pi-hole/pi-hole/ ': SSL certificate verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
fatal: unable to access ' https://github.com/pi-hole/web/ ': SSL certificate verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
fatal: unable to access ' https://github.com/pi-hole/FTL/ ': SSL certificate verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)

Updates work successfully when either the specific GIT AAAA entries are allowed or pihole is switched to NODATA blocking mode.

github.com
api.github.com
release-assets.githubusercontent.com

This behaviour started when the underlying OS was upgraded from ubuntu-server 24.04.4 LTS to 26.04 LTS

My Thoughts:

This may or may not be a bug, I am just trying to understand the process. Even with no IPv6 the upgrade should work but it doesn't.

This may not be an issue as I am not sure if 26.04 is supported as yet.

I am aware that pihole should not point to itself for DNS, however this is a HA pihole environment where each pihole points to a different machine for its own lookups so if pihole as a system works then DNS lookups work rather than local pihole dies therefore DNS is dead.

According to pihole documentation, when in default / null blocking mode, blocked queries get a 0.0.0.0 / :: response and the client should not even try to connect to the destination. However, during the update process an A and AAAA lookup are performed, A is permitted, AAAA is blocked but the update fails with the errors shown above.

When the pihole is configured to block AAAA but with NODATA then the update process works which means the underlying update process is not complying with the 'should not even try' quoted above.

This behavious did not appear with 24.04 LTS but did with 26.04 (although I have seen something similar with apt and its apparent reliance on IPv6 / AAAA even in a pure IPv4 network).

If this is related to an underlying change between the above OS version, such as kernel 6 -> kernel 7 or codebase re-write etc. then this will appear more as OS upgrades are adopted.

This would appear to be an underlying OS / process issue - not a pihole issue - but it is a process that pihole is dependent on.

3

For what it's worth :

The only situation I can remember seeing APT trying to connect via IPv6 instead of IPv4 was when I had some weird connection issue.
Despite having no connectivity at all the IPv6 connection method was used.

While this is weird from a user point of view it really isn't when you realize that modern Operating Systems these days prioritize IPv6 over IPv4 in general so it's actually perfectly normal :slight_smile:

4

Pi-hole's update check relies on git commands, e.g. from the corresponding line for your pihole updatechecker output, that would likely be git ls-remote:

Since git fails, that would indicate that your OS update has somehow affected git's behaviour.

It should be noted that your error message shows an SSL certificate error rather than a DNS related one:

I don't run Ubuntu 26.04, so I can't reproduce your observation.

Since git in turn is using tools like curl for retrieval, you could try to investigate how that validation failed by manually running ls-remote on your Pi-hole machine with verbose output, e.g.:

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/pi-hole/pi-hole/
5

Thanks for this, I wasn't aware of the curl verbose option, and it definitely shines more light.

Interestingly we were both right.

The error was indeed listed as a certificate problem but I believed that pihole couldn't establish a connection and so couldn't validate the cert - as in there was a DNS issue but it was masked.

I had originally searched for the cert errors and found Unable to access github.com for update

That article was pointing at resolv.conf so was different to my issue but it gave me some ideas such as trying NODATA mode.
I also saw that A and AAAA lookups were happening with AAAA being blocked so I also tried permitting all AAAA and then blocking AAAA but permitting the specific github domains.

This gave me the following:

Pihole in default (null) mode with all AAAA blocked - connection failed.
Pihole in default (null) mode with all AAAA permitted- connection succeeded.
Pihole in default (null) mode with all AAAA blocked except github - connection succeeded.
Pihole in NODATA mode with all AAAA blocked - connection succeeded.

This implies the underlying connection mechanism is trying to use IPv6 :: (as supplied by null mode) when it should allegedly treat the :: as unreachable.

This is the updatechecker output from Pihole in default (null) mode with all AAAA blocked

pihole-ubuntu-vm:\~# GIT_CURL_VERBOSE=1 git ls-remote https://github.com/pi-hole/pi-hole/
20:18:42.598630 http.c:890              == Info: Could not find host github.com in the .netrc file; using defaults
20:18:42.606944 http.c:890              == Info: Host github.com:443 was resolved.
20:18:42.606973 http.c:890              == Info: IPv6: ::
20:18:42.606979 http.c:890              == Info: IPv4: 4.237.22.38
20:18:42.607011 http.c:890              == Info:   Trying \[::\]:443...
20:18:42.607332 http.c:890              == Info: GnuTLS priority: NORMAL:%PROFILE_MEDIUM:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2
20:18:42.607396 http.c:890              == Info: ALPN: curl offers h2,http/1.1
20:18:42.607753 http.c:890              == Info: SSL Trust Anchors:
20:18:42.619690 http.c:890              == Info:   CAfile: 121 certificates in /etc/ssl/certs/ca-certificates.crt
20:18:42.657490 http.c:890              == Info:   CApath: 363 certificates in /etc/ssl/certs
20:18:42.659113 http.c:890              == Info: SSL connection using TLS1.3 / ECDHE_RSA_AES_256_GCM_SHA384
20:18:42.659609 http.c:890              == Info: SSL certificate verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
20:18:42.659640 http.c:890              == Info: closing connection #0
fatal: unable to access ' https://github.com/pi-hole/pi-hole/ ': SSL certificate verification failed: certificate signer not trusted. (CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
pihole-ubuntu-vm:\~#

As I thought, even though an IPv4 address is resolved GIT still tries to connect via the IPv6 null.

This is the updatechecker output from Pihole in NODATA mode with all AAAA blocked

pihole-ubuntu-vm:\~# GIT_CURL_VERBOSE=1 git ls-remote https://github.com/pi-hole/pi-hole/
20:39:21.904407 http.c:890              == Info: Could not find host github.com in the .netrc file; using defaults
20:39:21.905902 http.c:890              == Info: Host github.com:443 was resolved.
20:39:21.905929 http.c:890              == Info: IPv6: (none)
20:39:21.906042 http.c:890              == Info: IPv4: 4.237.22.38
20:39:21.906087 http.c:890              == Info:   Trying 4.237.22.38:443...
20:39:21.915846 http.c:890              == Info: GnuTLS priority: NORMAL:%PROFILE_MEDIUM:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0:-VERS-TLS-ALL:+VERS-TLS1.3:+VERS-TLS1.2
20:39:21.915928 http.c:890              == Info: ALPN: curl offers h2,http/1.1
20:39:21.916287 http.c:890              == Info: SSL Trust Anchors:
20:39:21.928327 http.c:890              == Info:   CAfile: 121 certificates in /etc/ssl/certs/ca-certificates.crt
20:39:21.966466 http.c:890              == Info:   CApath: 363 certificates in /etc/ssl/certs
20:39:21.967710 http.c:890              == Info: SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256
20:39:21.970698 http.c:890              == Info:   SSL certificate verified by GnuTLS
20:39:21.970794 http.c:890              == Info:   SSL certificate expiration date OK
20:39:21.970808 http.c:890              == Info:   SSL certificate activation date OK
20:39:21.970816 http.c:890              == Info:   SSL certificate status verification SKIPPED
20:39:21.970839 http.c:890              == Info:   common name: github.com (matched)
.... and a lot more .....

I will keep digging.

However based on the expected behaviour of :: can it be said that this section indicates that curl is behaving contra to how it should with an IPv6 null address ? As in why is it trying to connect to that address at all ?

20:18:42.606973 http.c:890              == Info: IPv6: ::
20:18:42.606979 http.c:890              == Info: IPv4: 4.237.22.38
20:18:42.607011 http.c:890              == Info:   Trying \[::\]:443...
6

OK so I tested some more and basically got this whenever pihole is in default-null mode and permits either the specific AAAA or all AAAA

21:02:22.226599 http.c:890 == Info: Could not find host github.com in the .netrc file; using defaults
21:02:22.240569 http.c:890 == Info: Host github.com:443 was resolved.
21:02:22.240605 http.c:890 == Info: IPv6: (none)
21:02:22.240612 http.c:890 == Info: IPv4: 4.237.22.38
21:02:22.240671 http.c:890 == Info: Trying 4.237.22.38:443...

So basically does two things in default-null mode

When AAAA is permitted it returns none (I guess as there is no IPv6 connectivity)

When AAAA is blocked it returns ::

I am now trying to see what is happening with the ::443 connection.

Maybe I have stale config somewhere that points :: to loopback or some other address so connects to the wrong machine. It doesn't make sense as (other than loopback) there is no IPv6 address to source a connection from nor a gateway to reach an IPv6 destination.

7

You didnt mention how you're blocking AAAA record lookups?

But if you did so via a regex like below:

$ dig +short @localhost chess.com aaaa
2606:4700::6812:8c43
2606:4700::6812:8943
2606:4700::6812:8d43
2606:4700::6812:8a43
2606:4700::6812:8b43

$ sudo pihole regex '.;querytype=AAAA'
  [✓] Added 1 domain(s):
    - .;querytype=AAAA

$ dig +short @localhost chess.com aaaa
::

Note that most implementations translate the null address "::" into the loopback address "::1" when trying to connect:

$ sudo pihole-FTL --config debug.webserver true
true

$ curl -ILv [::]
*   Trying [::]:80...
* Connected to :: (::1) port 80 (#0)
[..]

$ sudo tail -F /var/log/pihole/webserver.log
[..]
[2026-08-09 17:30:17.394 CEST 6921] DEBUG: Incoming connection from ::1 (src/webserver/civetweb/civetweb.c:20420)

So in a sense those clients would try to connect to themselves as they prefer the AAAA record replies over A record replies.

Another example but without blocking AAAA queries:

$ dig +short version.bind chaos txt @::
"dnsmasq-pi-hole-v2.92rc1"

$ sudo pihole tail
[..]
Aug  9 17:40:39: query[TXT] version.bind from ::1

Solution, dont block AAAA queries.

EDIT: FYI:

$ ip -br link show lo
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>

$ ip -br -6 address show lo
lo               UNKNOWN        ::1/128

EDIT2:

You most likely got below self signed cert presented above:

$ openssl s_client -connect [::]:443 </dev/null
[..]
depth=1 CN = pi.hole, O = Pi-hole, C = DE
verify error:num=19:self-signed certificate in certificate chain
8

This starts to look like a change of either curl's behaviour or of the OS libraries that curl is using.
For comparison, curl 8.14.1 produces the following output on my machine when NULL blocking AAAA records for github.com:

21:08:41.652097 http.c:913              == Info: Couldn't find host github.com in the .netrc file; using defaults
21:08:41.662304 http.c:913              == Info: Host github.com:443 was resolved.
21:08:41.662341 http.c:913              == Info: IPv6: ::
21:08:41.662347 http.c:913              == Info: IPv4: 140.82.121.4
21:08:41.662389 http.c:913              == Info:   Trying [::]:443...
21:08:41.662739 http.c:913              == Info: connect to :: port 443 from ::1 port 52644 failed: Connection refused
21:08:41.662796 http.c:913              == Info:   Trying 140.82.121.4:443...
21:08:41.677629 http.c:913              == Info: GnuTLS priority: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0

Just as in your case, it is trying to connect to [::]:443, but fails and gracefully falls back to IPv4, which allows ls-remote to succeed.

What's your curl version?

EDIT: And just out of curiousity: What's your reason for blocking AAAA records for github.com? It would seem there currently are no public AAAA records for github.com anyway.

9

deHakkelaar

You didnt mention how you're blocking AAAA record lookups?

I block with regex .*;querytype=AAAA

When permitting to test I either disable the above in the domains list or have the above enabled but then add 'allow' entries for the required github AAAA via the query log.

Isnt this a problem ? I thought the desire behind null blocking was that a value was supplied [::] that systems would know not to connect to {and so hopefully connect to other resolved results such as via IPv4}.

If [::] is translated to [::1] then any system that follows that will try to connect to loopback and probably fail.

pihole-ubuntu-vm:~# dig +short @localhost chess.com aaaa
::

pihole-ubuntu-vm:~# pihole-FTL --config debug.webserver true
true

pihole-ubuntu-vm:~# curl -ILv [::]

Trying [::]:80...

Established connection to :: (:: port 80) from ::1 port 54800

using HTTP/1.x

HEAD / HTTP/1.1
Host: [::]
User-Agent: curl/8.18.0
Accept: /

Request completely sent off
< HTTP/1.1 403 Forbidden
< Cache-Control: no-cache, no-store, must-revalidate, private, max-age=0
< Expires: 0
< Pragma: no-cache
< X-DNS-Prefetch-Control: off
< Content-Security-Policy: default-src 'self' 'unsafe-inline';
< X-Frame-Options: DENY
< X-XSS-Protection: 0
< X-Content-Type-Options: nosniff
< Referrer-Policy: strict-origin-when-cross-origin
< Content-Type: text/html; charset=utf-8
< Date: Sun, 09 Aug 2026 21:22:05 GMT
< Connection: close

I'm not sure where the above forbidden is coming from. My firewall blocks IPv6 but this machine has no IPv6 address so cant even reach it.

What's your curl version?

pihole-ubuntu-vm:~# apt list --installed | grep curl

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

curl/resolute-updates,resolute-security,now 8.18.0-1ubuntu2.3 amd64 [installed]
libcurl3t64-gnutls/resolute-updates,resolute-security,now 8.18.0-1ubuntu2.3 amd64 [installed,automatic]
libcurl4t64/resolute-updates,resolute-security,now 8.18.0-1ubuntu2.3 amd64 [installed,automatic]

EDIT: And just out of curiousity: What's your reason for blocking AAAA records for github.com? It would seem there currently are no public AAAA records for github.com anyway.

The short answer to that is yes.

The long answer is I don't specifically block github, I block all AAAA. There are several reasons for this but primarily my attitude is 'If I dont need it or use it then I block it'

This is to simplify my systems, reduce possible attack vectors [even the paranoid can be right sometimes....] and to prevent (if I can) the likes of Google and Facebook from bypassing my systems (such as DNS) with their own (such as DoH) so that they can track me or serve me ads.

AAAA blocking got caught up in the wash.

This works fine until situations such as this where something has changed. It would appear now that curl does not gracefully fall back to IPv4 after failing with IPv6 at least when using ::

Even now (as I am finding this / becoming aware of this) my mindset is still to block AAAA but permit specific 'known good' AAAA lookups such as ubuntu and github. Even though I know that even if AAAA is permitted and somehow hijacked it still wont work as IPv6 is disabled / blocked on the device and my firewall.

I'm not sure it makes sense to me let alone anyone else.

As stated at the top of this - I wanted to understand the why.

From what I can see pihole is doing everything right. Its configured to serve :: when blocking AAAA in default-null mode and it does that. However systems are then using :: in ways that they should not - such as even trying to connect. In the case of curl this now leads to a failure rather than a fallback and that reflects badly on pihole as pihole served the ::

Maybe I am an exception with blocking AAAA but if I'm not then I would expect to see more reports of this. Especially as it affects pihole's own updatechecker and pihole -up

10

I dont know/cant remember exact details why null blocking was chosen over the others.

Thats bc the document path is /admin/:

$ sudo pihole-FTL --config webserver.paths.
webserver.paths.webroot = /var/www/html
webserver.paths.webhome = /admin/
webserver.paths.prefix =

$ curl -ILv [::]/admin/
[..]
HTTP/1.1 302 Found
Location: /admin/login
[..]
HTTP/1.1 200 OK

I dont see how blocking AAAA queries from your network contributes to a safer setup.
As you can see, it only creates issues.
And maybe there comes a time when you embrace IPv6 as the way forward :wink:

EDIT:

Output for below might be more useful?

curl --version

11

pihole-ubuntu-vm:~$ curl --version
curl 8.18.0 (x86_64-pc-linux-gnu) libcurl/8.18.0 OpenSSL/3.5.5 zlib/1.3.1 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.2 libssh2/1.11.1 nghttp2/1.68.0 librtmp/2.3 mit-krb5/1.22.1 OpenLDAP/2.6.10
Release-Date: 2026-01-07, security patched: 8.18.0-1ubuntu2.3
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

12

Since I am unable to reproduce your observation on my Pi-hole machines (RPi OS, Armbian) or desktop PCs (Linux Mint Debian Edition), and you've succesfully used the same configuration on an earlier OS version, indications are that your issue is tied to your OS version somehow.

For reference, RFC 4291 - IP Version 6 Addressing Architecture explicitly defines that "The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing headers".

I can only guess here, but since we both see Trying [::]:443 in curl's logs, it seems more likely that the OS started to allow accessing [::], though one could argue that curl should not even try to connect to [::] at all (at least not when other IPs are available).

On a side note:
For blocking only specific DNS record types, using the NODATA mode would seem more natural to me, as e.g. an NXDOMAIN reply would be simply wrong - the domain very well exists, I just intend it to not return a specific record type (AAAA in your case).

13

Sorry I'm a bit behind posting here.

I logged a ticket on the curl github and did some more testing.

I have now shown that the behaviour is the same on ubuntu 24.04.4 and 26.04 using curl versions 8.5.0, 8.18.0 and the latest 8.21.0

With any of the above if IPv6 is enabled on loopback then this behaviour happens. curl claims to connect from ::1 to :: but in reality is connecting from ::1 to ::1

My previous testing missed the fact that on my 24.04.4 build IPv6 was disabled via sysctl and was disabled on all interfaces. On 26.06 it was disabled via netplan which leaves the loopback interface intact (I think this was because sysctl is being deprecated ?? and so was not carried over by the upgrade process).

On my 24.04.4 system when I re-enabled IPv6 via sysctl and disabled it via netplan (leaving loopback with an IPv6 address as netplan does not control loopback) then the above connecting to ::1 from ::1 appeared.

I am still testing to see what happens if IPv6 is disabled via sysctl on all interfaces except loopback.

So this does appear to be an OS or maybe netplan issue.

Something somewhere is translating :: to ::1 when used as a destination but I believe it is below curl which is why curl still thinks it is connecting to ::

This seems wrong to me as (from everything I have read) this is not how :: is supposed to be used.

But its not a pihole issue and at the moment its not looking like a curl issue either.

edit:

On the NODATA front. I may go this path or stick with default-NULL and permit specific AAAA as required. NODATA is not as ideal as it seems. Many systems now seem to have built in 'Internet Connectivity' checkers that appear to be badly coded. They seem to perform A and AAAA lookups of various 'popular' sites and prefer the AAAA results over A. When I switched to NODATA mode I had multiple systems (cheap ones) start flagging connectivity flapping issues when there weren't any. These went away when I switched back to NULL so who knows what they are doing.

All of the alerts were minor and could be ignored but just the fact that they occured showed that there's always some bad or lazy code out there waiting to annoy you.

14

Its not only curl that translates :: into ::1 !

$ ping -c1 ::
PING ::(::) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.136 ms

--- :: ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.136/0.136/0.136/0.000 ms

$ sudo tcpdump -nti any icmp6
[..]
lo    In  IP6 ::1 > ::1: ICMP6, echo request, id 20050, seq 1, length 64
lo    In  IP6 ::1 > ::1: ICMP6, echo reply, id 20050, seq 1, length 64
15

My (dated) client seems to comply to that RFC if I null block AAAA:

$ dig +short chess.com a
104.18.139.67
104.18.138.67
104.18.137.67
104.18.141.67
104.18.140.67

$ dig +short chess.com aaaa
::

$ curl -ILv chess.com
*   Trying 104.18.138.67:80...
* Connected to chess.com (104.18.138.67) port 80 (#0)
[..]

$ curl --version
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.16 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u12
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

EDIT: On my Pi-hole sandbox VM:

$ grep nameserver /etc/resolv.conf
nameserver 127.0.0.1

$ sudo pihole regex --list
  [✓] Found 1 domain(s) in the regex denylist:
    - ".;querytype=AAAA"
      Comment: null
      Groups: [0]
      Added: Tue Aug 11 08:01:29 PM CEST 2026
      Last modified: Tue Aug 11 08:01:29 PM CEST 2026

$ dig +short github.com a
140.82.121.4

$ dig +short github.com aaaa
::

$ git --version
git version 2.39.5

$ curl --version
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.16 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u12
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

$ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/pi-hole/pi-hole/
f47b8ede5a8e38f9c703202d324a074dbdba4ca9        HEAD
2b19810ceffdc0d5f0798fa2ef3fcac4a85eb9d8        refs/heads/bats-in-containers-insanity-mode
ca994f451ec020e88ceff49fb0a4db9a7cdf4489        refs/heads/development
7df117876faebeb38353cdd859513ce9a6e60798        refs/heads/doas_alpine
[..]

I dont have native IPv6 on my LAN.

EDIT2: Checked SRV records too just to be sure :wink:

$ dig +short _https._tcp.github.com srv
$

Compared to those for the Debian APT repo:

$ dig +short _https._tcp.deb.debian.org srv
10 1 443 debian.map.fastly.net.

Some applications, like apt for example, connect to SRV records instead of A or AAAA records ... if they exist.

16

I logged the ticket on the curl github only because I was working my way down the chain trying to figure out where this was happening.

It quickly showed to not be a pihole issue and then almost as quickly showed not to be curl either.

I had previously run into some wierd apt behaviour (but had not really linked it to this, it was just another IPv4 -> IPv6 transition oddity) so I am not surprised that other apps/systems are affected too.

In the grand scheme of things this is very minor.

However, it seems wrong to me and I dont like it.

I have read a few articles on IPv6 and :: / ::1 specifically and :: only appears to have two valid uses - and should never be treated as a valid destination so I do not understand the logic behind translating it to ::1

If connectivity was destined for ::1 then ::1 should be quoted.

Thats like the IP stack deciding 'I know you specified TCP, I know you want TCP but I'm going to rewrite that as UDP anyway, no need to thank me, it's fine....'

This sort of coding undermines other peoples attempts to write good code. Take pihole for example. The default-NULL option to reply to blocked IPv6 with :: makes perfect sense based on what :: is supposed to mean, a real but unreachable destination.

With this translation pihole is now effectively telling [blocked] end systems 'you want IPv6 - try loopback' and you are at the mercy of an app trying IPv4 after a real connection to a real IPv6 destination fails.

Just imagine the mess if IPv4 did this 'you're trying to connect to 0.0.0.0 ?, no problem ringing 127.0.0.1 for you now....'

17

Did you try on the Pi-hole host?

dig +short version.bind chaos txt @0.0.0.0

EDIT: Oh another thing, its not recommended to have the Pi-hole IP configured for local DNS on the Pi-hole host itself.
Choose/configure another like your router IP if it doesnt close a DNS loop.
Or your ISP provided ones.
Or external ones like Cloudflare, Google, Quad9 etc.

That way processes on the host wont lose DNS resolution when pihole-FTL goes belly up for some reason.
Is easier diagnosing plus AAAA queries wont get blocked when you try to upgrade etc.

This one:

EDIT2:

$ dig +short _http._tcp.us.archive.ubuntu.com srv
2 0 80 ubuntu-mirror-1.ps5.canonical.com.
0 0 80 ubuntu-mirror-1.ps6.canonical.com.
2 0 80 ubuntu-mirror-2.ps5.canonical.com.
2 0 80 ubuntu-mirror-3.ps5.canonical.com.
0 0 80 ubuntu-mirror-3.ps6.canonical.com.
0 0 80 ubuntu-mirror-2.ps6.canonical.com.