🐛 `gov.tools` domain inaccessible by Secure DNS (DNSSEC)

[rphair]

Area

Other

Domain

gov.tools

Which wallet were you using?

N/A

Context

gov.tools and its subdomains work fine through regular DNS, but DNS over TLS (DoT) through Cloudflare and through Quad9 returns a result seen as an immediate hostname lookup failure by web browsers.

This likely happens around the domains being redirected a couple times to arbitrary-looking addresses: so either it looks like a "hacked" site (and could therefore be blocklisted in both places) or there isn't a properly configured reverse lookup for the address as I once reported for another web site here:

$ dig gov.tools
;; ANSWER SECTION:
gov.tools.        300    IN    CNAME    z623632c1-z3c24a074-gtw.z1add53af.slab.sh.
;; ADDITIONAL SECTION:
z623632c1-z3c24a074-gtw.z1add53af.slab.sh. 300 IN CNAME    a671ab83a253f4cc58d99d5a52072ff1-fd222fd9900ea9af.elb.eu-west-1.amazonaws.com.
a671ab83a253f4cc58d99d5a52072ff1-fd222fd9900ea9af.elb.eu-west-1.amazonaws.com. 60 IN A 54.73.234.213

There appears no proper workaround for this, since the only way I've found to get to gov.tools is not to use this commonly used secure networking configuration which is especially appropriate for cryptocurrency users & advocates.

Steps to reproduce

1. Find a real Ubuntu 24.04 system.
   • Ubuntu 24.04: since, as of this most common distro & version, DoT is built in
   • real: since it's unknown if the TCP/IP stack in a virtual machine would fully implement DoT
2. Edit /etc/systemd/resolved.conf to use (for example) DoT through CloudFlare by setting these options:

DNS=1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
DNSSEC=yes
DNSOverTLS=yes

3. Restart the systemd resolver: systemctl restart systemd-resolved
4. Observe that browsers won't open web site at gov.tools or subdomains (e.g. Documentation).
5. (optional) Repeat the above with Quad9 DNS= settings and observe the same thing happens:

DNS=9.9.9.9 149.112.112.112 2620:fe::fe 2620:fe::9

Actual behavior

DNS records visible from dig gov.tools ultimately point to an A record (by dereferencing 2 CNAME records) but that doesn't make it through the resolver when DoT is being used. (TL;DR... web site not load!)

Subtly the behaviour could well be the problem pointed out here, indicating some care must be taken to configure DNS domains to make reverse lookups possible that are necessary for secure DNS configurations to authenticate that the domain record & its addresses are not being spoofed; as explained here (this is a follow-up post of the forum thread above): https://community.cloudflare.com/t/cloudflare-dns-missing-popular-site-blocklisted/732950/7

Expected behavior

Web site works with DNS over TLS just as it does without it. Cryptocurrency holders, dApp users, Cardano dReps, and developers / engineers / managers / writers in the field are happy to be able to use DoT continuously: to avoid domain censorship by their ISPs / governments as well as surveillance or exploitation through their DNS histories.

[aaboyle878]

Hi @rphair we tried to enable this last night and again this morning via our current DNS provider which resulted in chain issues as the DNSKEY didn't get assigned and so we have had to revert this change for now however we will explore alternate options and keep you updated of the progress

[rphair]

@aaboyle878 @Ryun1 the Intersect MBO newsletter today confidently says:

This week's GovTool update includes the rollout of an improved wallet connection experience, resolving the long-standing issue of unnecessary validation prompts by only requiring users to sign transactions when necessary (e.g., voting or submitting proposals).
...
These updates aim to streamline the user experience and support more profound community contributions.

In keeping with goals like this, would not the "long standing issue" of gov.tools being completely inaccessible through Secure DNS also be a priority... especially now that the exact problem has been confirmed?

[rphair]

@aaboyle878 @Ryun1 — with a request to please tag whatever other parties will be involved in getting this issue acknwoledged and fixed —

I would like it please to go on record that I have had an absorbing interest in the Governance process from its very beginning, but have effectively been made ineligible for direct participation because of this crippled DNS configuration on gov.tools — which I can tell was implemented later because there was originally no problem accessing the site after it was built.

I am one of the original reviewers of, and contributors to, CIP-1694 as well as all other Cardano governance CIPs. I have advised DReps since the role was conceived and regularly contribute to Governance issues on the Cardano Forum: most notably on issues the institutions and governance tooling providers have steered away from. I am one of Cardano's top unaffiliated generalists and its # 1 independent documentation reviewer.

Yet even though I was eager and ideally positioned to begin service as a DRep when everyone with any interest was being onboarded last year, the site remained blocked: not just to standard desktop Secure DNS configurations but Tor and other VPNs which also use Secure DNS.

It is inconsistent for Intersect to post so many messages suggesting our Governance process is pre-eminent in the industry while neglecting an issue like this. If it will never be fixed, there needs to be a prominent disclaimer on gov.tools and its subdomains that access is prohibited with Secure DNS, DNS over TLS and likely DNS over HTTPS as well. And we need an update on this issue immediately instead of charging forward with crowd-pleasing development and announcements while sweeping this & related fundamental issues under the rug.

[aaboyle878]

Hi @rphair,
Apologies for not getting back to you sooner, I assure your issue is not being neglected but to be transparent, I did get sidetracked with a few ad-hoc tasks and haven't been able to allocate my full time to this issue.

However I believe the main contributor to the problem is the .slab.sh record in the DNS Chain, as you have stated. I have been looking into ways we may be able to remove this record cleanly so that resolver filters are not triggered and prevent the site from loading.

Due to how the site is deployed this has presented some slight challenges, but I'm hoping to test a potential workaround over the next two weeks and will post any status updates here. In the event of any unforeseen delays, I'll also try to give a revised ETA.

[rphair]

I've retitled this thread based on some new findings, mainly because no cooperative investigation has taken place and very little investigative response has been posted: as far as I can tell, checking to see if an "easy" solution was possible, not finding that, and then putting this on hold indefinitely.

So this security problem might be fixed more readily if some match-up can be made between a more specific problem and Intersect's apparently limited flexibility & resources.

It seems only the DNSSEC component of DNS over TLS that fails in this case: one part of a "belt and braces" security configuration that provides:

1. DNS over TLS (DoT) itself, for confidentiality
2. DNSSEC, for tamper-proofing

It is possible to have # 1 on all DNS queries while having only # 2 on hosts & domains where it is supported (currently not gov.tools or any of its subdomains) by changing the DNSSEC option above from yes (or true) to:

DNSSEC=allow-downgrade

Then sites like gov.tools will still be accessible even through they fail to provide authenticated DNS responses as per https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions .

Note that this is a "workaround" only for all sites except gov.tools — not for gov.tools itself, which is still consistently failing DNSSEC — so that governance users can leave DNS over TLS and/or DNSSEC enabled without losing GovTool. I've tested that the allow-downgrade configuration works to access gov.tools in both CloudFlare and Quad9 configurations.

This should still be considered an urgent problem. If considering otherwise, please keep in mind the current motivation for a large-scale spoof of the gov.tools domain (or the third party who provides its CNAME record) while a billion ada worth of governance propositions are being voted upon. - cc @Ryun1 @aaboyle878 @thenic95 @KtorZ @colll78