Add section to validate DNS connection #1176
No reviewers
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#1176
Loading…
Reference in New Issue
No description provided.
Delete Branch "1152"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
This PR adds a new section for giving users easy to follow steps to validate their encrypted DNS connection is working for them. Definitely open to any feedback to make this clearer and more readable.
@Mikaela did note in the issue:
I address this by saying
If the TRR column says "true" for some fields, you are using DoH.
Maybe this could be changed to something more clearer?Resolves: https://github.com/privacytoolsIO/privacytools.io/issues/1152
Check List
I have read and understand CONTRIBUTING.md.
I have listed the source code for this project in source_code.md.This project is free/libre software.This project has an associated discussion.
Code Repository (if applicable): N/A
Deploy preview for privacytools-io ready!
Built with commit
f59c63c0c9
https://deploy-preview-1176--privacytools-io.netlify.com
@ -39,3 +39,3 @@
<tr>
<th data-sorted="true" data-sorted-direction="descending">ICANN DNS Provider</th>
<th data-sorted="true" data-sorted-direction="ascending">ICANN DNS Provider</th>
<th data-sortable="true">Server Locations</th>
Fix small issue with sorting "caret" pointing in the wrong direction on page load.
👍 overall good start, but I have suggestions I would like to see implemented
I think this need additional information.
I am not how good my suggestion is though. Also I am not sure how clear it is that Quad9 often appears as WoodyNet for people in the USA while in Finland they appear as TREX Exchange Services Oy where the node is hosted. My Keybase DNS leak test with my config file is possibly a good showcasing of this.
I guess the dnsleak.com test is higher due to being more reliable? I am thinking on how that test may fail at times due to caching or just in general like happens to BlahDNS https://github.com/ookangzheng/blahdns/issues/42 who doesn't know why it happens. I am not sure if this comment needs to be addressed.
Can we assume that people read our insturctions and we don't need to separately warn about not all queries possibly being TRR?
This discussion made me check the upstream.
I want the link to look better, but I am not sure what to call that test as they don't call themselves as "DNSSEC capability checker by ??? University" or similar.
Should it be noted that dig is part of
bind-dnsutils
in Debian and ??? in Fedora, if it says command not found? And Windows?Yeah, I guess I'm thinking the dnsleaktest maybe isn't more reliable but applicable to all providers we list? Some don't have their own test page is what I'm thinking... I guess it's implicit for users to try several of the points we make here, e.g. check dnsleaktest & see if a test page is available.
Yeah, good point 🤔 the server location difference is due to Anycast, correct (which we call out in the table)? Maybe we should mention here in a warning or something about for Anycast providers, this may not be the most reliable check then...
Hmm... that's a good point... there's ongoing discussions about how the about:config tweaks section could potentially go or not so maybe its worth calling out in a warning or something here about this?
yeah 🤔
hmm, yeah good callout 🤔
I would literally just call it "DNSSEC Resolver Test by University of Duisburg-Essen"
Alternatively, "DNSSEC Resolver Test by Matthäus Wander"
On Ubuntu and Debian (and presumably Trisquel) it's just
dnsutils
. On Fedora and CentOS it isbind-utils
. On Arch (and presumably Parabola) it'sbind-tools
.Hmm, should we just link to something like https://en.wikipedia.org/wiki/Dig_(command)?
I'll push an update.
Will push an update.
I'll push an update for this.
There are sme things I would still like to see addressed
This is not a perfect suggestion either, but "Validate" is a bit unclear on what is being validated.
It's not only the case with anycast or at least I think DNSLeaktest showed BlahDNS Swizerland as etna.switch.cz or similar.
The tests will always show the owner of the IP address block, which is typically the upstream ISP of the VPN provider. This suggestion is worded fine though I think. However, I would change "The main point is that you shouldn't" to "Just ensure you don't".
Also found https://www.dnssec.cz/ by CZ.NIC.
Added as a second option.
👍
@ -288,3 +303,4 @@
<h3>Worth Mentioning and Additional Information</h3>
<ul>
Does the CZ NIC page have English somewhere or do we assume that everyone can read Czech? 😄
I am learning it and can somewhat understand the gist on having DNSSEC, but I am not entirely sure what it's trying to tell me.
@ -288,3 +303,4 @@
<h3>Worth Mentioning and Additional Information</h3>
<ul>
Hmm so they don't have an English translation... yeah, maybe this is more confusing to add. From my understanding is that as long as there's a big green lock icon next to "DNSSEC", DNSSEC is enabled 😄 But I think the original link is fine to have. I'll remove the CZ.NIC link.
👍