- von Bob Smith, vor 4 JahrenBewertet mit 2 von 5 SternenI'm with bsiege: I'm looking to replace CZ.NIC Labs' excellent DNSSEC/TLSA Validator. (In use since 126.96.36.199, Nov. 2016, currently 188.8.131.52 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.
- von Firefox-Benutzer 13645153, vor 4 JahrenBewertet mit 2 von 5 SternenUsing 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.
Quad9 https://quad9.net/ DNSSEC resolving (online) service supports (Encrypted) DNS over TLS, on IP 184.108.40.206 & 2620:fe::fe , Port 853. And GetDnsApi https://getdnsapi.net/ service supports (Encrypted) DNSSEC DNS over TLS on IP 220.127.116.11 & 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.
- von Firefox-Benutzer 12976734, vor 4 JahrenBewertet mit 3 von 5 SternenI want better icons for the display. The thin font raises no attention. It's a good extension that increases security.
- von bsiege, vor 4 JahrenBewertet mit 2 von 5 SternenSearched 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.