Amazing work, thanks to you all for considering it and bringing it to bear.
1 Like
Sorry, it appears I missed some questions here.
It fails the validation immediately as it has no way to verify the signature.
The procedure is different but similar: We move to the next release once the currently supported minimum passed EOL* for a sufficient long time. For example, Debian bullseye ("buster +1") was released on 2021-08-14 so Debian buster's EOL is around 2022-08.
*) the EOL date for the stable Debian release is the date of the next stable release plus one year.
Should be as easy as running
pihole checkout ftl development
right now. You can get back on track with
pihole checkout ftl master
at any point.
@DanSchaper As Debian Buster went EOL three months ago, should we drop Debian 10 support? The minimum Ubuntu we officially support is 20.04 which is based on bullyseye.
Confirmed. The key is no longer seen as a bogus blob and the A record is returned with NOERROR.
Before:
After:
Thanks @DL6ER for the additional info. I forked docs ready to write it up as a special edge case howto, but I'll leave it now, as this official update makes the problem go away.
I thought it would be interesting to perform the Root Canary Algorithms test again, with Pi-hole and local recursive Unbound, to see if it accurately picks up the new capability. And it does.
FTL with older nettle library:
FTL dev with newer nettle library:
Thanks for your check. RFC 8624 says RSA-MD5, DSA, and DSA-NSEC3-SHA1 as well as ECC-GOST MUST NOT be used for DNSSEC Signing explaining the missing columns. Furthermore, the same RFC says the DS algorithm GOST R 34.11-94 MUST NOT be used for DNSSEC delegation explaining the missing third row:
TL;DR: This means every allowed algorithm will be supported from the next release on or in current development branches of pihole-FTL on most architectures*.
Edit: This was kind of a misinterpretation of the RFC. In reality, the GOST implementation was simply incorrectly done in dnsmasq. This should be fixed as of dnsmasq v2.88rc1 (FTL v5.19.2). However, it shouldn't have had any practical impact as GOST isn't even used for DNSSEC by the Russian government sites themselves.
*) They are already now but only in the x86_64-musl binary.
2 Likes
I would hang onto it as long as we can (typically end of LTS) , ideally after a release subsequent to Bullseye is availalble.
Running the latest versions (Pi-hole v5.14.1, AdminLTE v5.17, FTL v5.19.1). This command doesn't work. pihole -v v seems like it might be trying but just returns the below; I don't know whether this relates to the crypto libraries.
$ pihole -v v
Hashes for Pi-hole not available
Hashes for AdminLTE not available
Hashes for FTL not available
Incidentally, maybe a minor bug report, after the update pihole -v shows versions but not the latest versions. It needs updatechecker before it becomes aware of them.
$ pihole -v
Pi-hole version is v5.14.1 (Latest: N/A)
AdminLTE version is v5.17 (Latest: N/A)
FTL version is v5.19.1 (Latest: N/A)
$ pihole updatechecker
$ pihole -v
Pi-hole version is v5.14.1 (Latest: v5.14.1)
AdminLTE version is v5.17 (Latest: v5.17)
FTL version is v5.19.1 (Latest: v5.19.1)
It's pihole-FTL -vv
1 Like
I can confirm that if I use the right command, it is indeed working!
Just to inform you that there is some more motion coming into the topic (fixing the broken GOST implementation). Make sure to check out the screenshots over at
1 Like
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.