I would give at least 4 stars, if it would use my local resolver instead of using google/cloudflare for DNS lookups.
Reason behind the downgrade: 1. it introduces a single point of failure: if either of those sites can't answer, _ALL_ users of this extension (who have configured that site) can't use it, if it would use the local resolver and that failed it would be just the users of the local machine who experience that problem.
2. it is a privacy hazard: a hacker needs to crack only a single (ok: two) machine(s) to get a complete log of who on this world tried to communicate with which web server.... if it would use the local configured resolver that _might_ still be a problem, depending on the configuration of said resolver, but mostly (I hope) those will contact multiple authoritative servers to walk from the root to the leaf containing the desired information and only the _last_ server will know which site I wanted to contact, but there it's irrelevant, since _that_ site knows it anyway.... (btw.: _THIS_ is the reason why I disabled this extension)
3. it can't verify local domains according to 'dig' my own domains are DNSSEC enabled and working correctly, still your extension reports them as unsigned because there is no global glue record, as such while it is reachable from the world (via dyndns), the world doesn't see the DNSSEC information stored on my local dns-server.
Since Mozilla is not interested in developing DNSSEC/DANE validation for the browser this WE is certainly much welcome, however forcing Google or CF resolver leaves a bad taste and offering DoH at some point does not change it if the TRR URI is again limited to Google or CF.
The user should be at liberty to utilize whatever method, as such DoT is absent, and resolver incl. localhost/127.0.0.1
A feature suggestion would be DANE validation (on the heels of DNSSEC)
Great addon ! It just lacks the ability to set a custom DNS resolver, and the TLSA support.
Besides, the UI doesn't integrate well with a dark theme on Linux (KDE here, but I suspect it will be the same for another window manager), as the background of the tooltip gets its color from the system, and the font color seems to be hardcoded in black.
Oh, and I didn't find any link to the sourcecode. Is it available ? :)
You may be able to use this https://dnscrypt.eu/ instead of hard-wiring Google in directly. Also, the Czech fellows who used to make DNSSEC Validator provided 2 IP4 and 2 IP6 machines to go with that. Other that supporting DNSSEC those are simply public DNS servers like Google's and there is nothing to enforce the use of their own plug-in. The addresses are in their documentation. (Actually, they may have a whole bunch more on the account of being people who run .cz TLD registry. AFAIK, the Czechs are the only TLD registry that support regular, documented version of DNSSEC, though there is a whole bunch more using some slightly hacked version of their own)
Four stars for functionality, minus two because the implementation goes through Google. Yes, much the same as every other review so far - I'm actually writing this review to let you know that you don't actually need to trust any external HTTPS service to handle this!
Specifically, the Chrome version of DNSSEC/TLSA Validator, the extension you're clearly attempting to replicate, suffers from the same WebExtensions restrictions that modern Firefox does. Rather than trust an external service, however, they work around the issue through a WebExtensions feature called native messaging: a compiled binary is installed onto the system, which can do whatever it likes locally including make its own DNS queries, and then the WebExtension can ask that binary to check DNSSEC status when necessary.
Yes, it's a little bit of a hassle to install the necessary binary in the first place, since the browser won't install it automatically, but it's much more secure than trusting any external service - and it's no different to how the Chrome version of DNSSEC/TLSA Validator works right now.
I can confirm that Firefox supports this exact same approach, since I use several WebExtensions in Firefox this way (browserpass and bukubrow, specifically!). I don't know why the folks behind the DNSSEC/TLSA Validator haven't simply released a Firefox 57+ extension that uses native messaging, exactly like their existing Chrome extension, but it's definitely something you could do. :)
I'm with bsiege: I'm looking to replace CZ.NIC Labs' excellent DNSSEC/TLSA Validator. (In use since 188.8.131.52, Nov. 2016, currently 184.108.40.206 in use with Cyberfox x64 52.6.1 portable under Windows 7 and Quad9 DNS.) DNSSEC *and* TLSA validation.
Rating: five stars for proof of concept; minus three for google.
In Mozilla's quest to make its browser more "secure," it disabled the ability to run extensions to make sure it's doing so and the ones to force it to do so if needed.
I'll be revisiting this page to check on your progress. Thanks for your efforts with hopes for success.
Using fixed remote/public DNSSEC DNS Server/Resolver over unencrypted connection is NOT secure habit/procedure. And Google is known to LOG/record usage for-ever ! https://developers.google.com/speed/public-dns/privacy Please add option for users, to specify their own local DNSSEC DNS validating servers/resolvers (like: Unbound, BIND, etc) or redirectors/resolvers (like: Stubby, GetDNS, etc) in this addon. Local DNSSEC resolvers or redirectors can run/respond on IP 127.0.0.1, 127.0.0.2, etc, Port 53. ISP corporations can see+record/log (aka, profile) user's all DNS resolving IP data, etc usage, when DNS query/answer going over UDP/TCP unencryptedly into their or any other DNS server/resolver. If a trustworthy 3rd-Party(3P) public DNSSEC-DNS Server/Resolver service(s) is(are) used (who has publicly publicized that they absolutely do not record user's any DNS usage), then that(those) service(s) can help to maintain privacy (little bit better). When encrypted/TLS connections are used, then ISP cannot see data inside encrypted packet (but can see+record(profile) IP adrs of "from"/"source" and "to"/"destination") unless ISP also obtained required+related decryption cert+key. But tracking/recording/profiling still possible (from 3P to DNS-servers/resolvers traffic), as all DNS servers/resolvers are not yet using DNS-over-TLS, and, DNS by nature need to connect with known/established IP addresses. When DNS Data & Content Data authenticity can be verified by using unchangeable (but updateable with newer data) records from public p2p ledger (i.e: blockchain), and content data is obtained via multiple random p2p network based multiple peer computers, then full/complete profiling will not be possible. Unbound DNSSEC server/resolver software also supports Encrypted DNSSEC resolving (DNS-over-TLS https://tools.ietf.org/html/rfc7858 ) on Port 853 when user will use+specify+load custom cert+key in Unbound-resolver & in client (firefox/unbound/libunbound, etc). And when SOCKS5 (tunnel/proxy etc) used by firefox/user/host-computer, then Encrypted DNSSSEC resolving is very necessary. If this addon (will be) using "libunbound", then also please add option for users to manually specify/add their own "root.key", and/or add PEM/cert for dnssec-rootkey webpage/site, and add/specify cert+key for encrypted/TLS DNS-resolving, etc. Unbound: https://www.unbound.net/ Quad9 https://quad9.net/ DNSSEC resolving (online) service supports (Encrypted) DNS over TLS, on IP 220.127.116.11 & 2620:fe::fe , Port 853. And GetDnsApi https://getdnsapi.net/ service supports (Encrypted) DNSSEC DNS over TLS on IP 18.104.22.168 & 2a04:b900:0:100::37 , Port 853. Both Quad9 & GetDnsApi also supports unencrypted DNS over UDP/TCP on Port 53. More IP: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers The "getdns"/"Stubby" https://getdnsapi.net/ , https://github.com/getdnsapi/getdns , https://github.com/getdnsapi/stubby , etc redirectors/resolvers software can also be used (instead of Unbound/BIND server software) to forward/resolve all local DNS queries over TLS/encrypted connection. Almost all OS have option to load Unbound (or other Full Validating DNSSEC DNS Server/Resolver, etc), either directly, or thru 3rd-party(3P) package-management software (CygWin, MacPorts, HomeBrew, etc). Also check out the alternative DNSSEC-Validator (XUL based) firefox addon/extension https://www.dnssec-validator.cz/ which allows using custom/local/remote DNSSEC resolver/server with firefox below v57, (and dnssec-validator does not yet have a Web-Extension (W-E) based addon/extension for firefox v57+ (when i posted this message here Dec-30-2017), but their chrome extension should+can be converted to be used with firefox v57+). DANE/TLSA is best part of DNSSEC. if this addon is already not doing this, then please also add these options: Display DANE verification related status ICONs in toolbar for HTTPS based websites which are DNSSEC signed, so that user can know/view different ICONs for different types of verification/unverification status.
Firstly, we do not use unencrypted connections, everything is done through HTTPS.
Then, the developers of the former DNSSEC-Validator said themselves they would not port their extension because of missing APIs in Firefox 57+. As mentionned in another comment, as far as we know, there is no way of crafting and executing a raw UDP or TCP packet in Firefox 57+. We are therefore forced to use HTTPS to perform all DNS queries through HTTP resolvers.
That being said, I agree using Google by default is not a good choice, and a choice that was made as a proof of concept. I am in the process of forking OpenDNS HTTP resolver to support reporting DNSSEC status, so you can self-host your resolver and use it with this extension instead of Google's.
But that self-hosted resolver will always be an option. The extension has to work on first run, for non-technical people, and must use a publicly-hosted HTTP-based DNS resolver. If you have any service that does that outside Google, I'll be happy to integrate it.
Searched for a replacement of https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ But as long it uses hardcoded Google servers and not the same as the local machine it is more dangerous than helpful (for me)
Unfortunately, as far as I know, there is no way to know the machine's configuration or to make raw socket connections from the new WebExtensions, hence the use of HTTP.
However, I'm still looking for another HTTP resolver that does not involve Google and that does report DNSSEC status (OpenResolve public service does not, for example). I'm currently looking at a self-hosted OpenResolve resolver. Will get back to you.