What is the problem/bug ? Which TESTs i/we have done ? Hi, me and few other users have queried "mozilla.org" zone/domain-name via various tools and via various tunnel, port-forwarding etc path, and could not find any TLSA record. Neither the CERT PGP, etc vital records exist. All test computers (in our side), locally have a full DNSSEC supported DNS-Resolver (DNS-Trigger, Unbound, BIND, etc) installed, (in Windows, Linux, MacOSX computers), from where i/we have used query tools. And remote full DNSSEC supported Public DNS-Server was also used to make sure our query results were right, and was not malformed or modified. The 'dig' query tool was obtained via Cygwin on Windows. And Linux computers had 'dig' from bind, and some Linux also configured with dns-resolver like: unbound, dns-trigger, etc instead of bind. (So it is not any tools' fault, that TLSA are not found). command-lines such as below were tried: dig @127.0.0.1 -c in -t TLSA _443._tcp.mozilla.org. +dnssec +additional +tcp dig @127.0.0.1 _443._tcp.mozilla.org. TLSA +dnssec +additional dig @127.0.0.1 _443._tcp.www.mozilla.org. TLSA +dnssec +additional dig @127.0.0.1 _443._tcp.mozilla.org. TLSA +dnssec +additional +short dig _443._tcp.mozilla.org. TLSA +dnssec +additional +short dig _25._tcp.mail.mozilla.org. TLSA +dnssec +additional +short And i/we have also queried, after changing IP-address "127.0.0.1" into a (full DNSSEC supported) Public DNS-Server's IP-address. There was no result with any TLSA. As some computers were behind (different type of) proxy server(s), or was using tunnels or was using Port-Forwarding, i/we had to do slightly different type of dns queries on those. So query was done for mozilla.org site, from remote public dns server(s) as well: Ether by adding "+vc" or "+tcp" option at the end, in 'dig' tool's command-line. Computer which was (also) listening on different DNS port, that listening port number was specified with "-p PORT_NUMBER" option, in 'dig' tool's command-line. And still there was no result with any TLSA. ====================================================================== This need to be stopped : OR, Why we need TLSA record ? Consider this (one out of many) scenario : your(Mozilla.org) website admin obtained paid (or self-signed) SSL cert from company-A for the "mozilla.org" ... now another bad-person (or bad-entity or bad-group) has also obtained a SSL cert for same "mozilla.org" but from a different cert company-B or created a fake SSL cert. Now if visitors or Mozilla Software-Updaters or Purchasers/Buyers , connecting with Mozilla.org via Tor-Proxy or any other (type of, any single or multiple) Proxy , or via compromised ISP directly , or directly via/from a censoring-country , or via compromised (middle-man) server , and IF that bad-person/bad-group have also setup a fake server with 'Mozilla.org' , and also doing DNS-SPOOFING , then he/she/they can easily take visitors or Mozilla software-updaters to fake Mozilla.org ! :( And would you take responsibility when users have lost money/valuables by such mechanism(s), and blaming you how would my web-browser suppose to know what SSL cert is actually & really belongs to you(Mozilla.org) and approved by you for HTTPS ? TLSA record declares what exact SSL/TLS cert is approved, and used by the actual owner/holder of a domain/zone "mozila.org" site. DANE supported apps, with assistance of a Full DNSSEC supported DNS-Resolver, can detect it, and warn/indicate the user about it. ====================================================================== Expected Results: What steps you(Mozilla) may/can do ? a TLSA record (for port 443 for HTTPS connections to mozilla.org) will look like : _443._tcp.mozilla.org. 300 IN TLSA 3 1 1 Hex-Code-of-SSL-Cert _443._tcp.www.mozilla.org. 300 IN TLSA 3 1 1 Hex-Code-of-SSL-Cert TLSA is aka TYPE52. You should also consider to add below DNS-records for Mozilla's own members benefit, and for secured communication: _25._tcp.mail.mozilla.org. 300 IN TLSA 3 1 1 Hex-Code-of-SSL-Cert _993._tcp.mail.mozilla.org. 300 IN TLSA 3 1 1 Hex-Code-of-SSL-Cert _995._tcp.mail.mozilla.org. 300 IN TLSA 3 1 1 Hex-Code-of-SSL-Cert in above example i assumed your IMAPS/993, SMTPS/25, POP3S/995 all using same host : mail.mozilla.org. If your SSL cert for mozilla.org is in "mozilla.org.pub.crt" file. Then Hex-Code-of-SSL-Cert can be found by: openssl x509 -in mozilla.org.pub.crt -outform DER | openssl sha256 or use "tlsa" tool. TLSA can be viewed from such sites : https://fedoraproject.org/ , https://torproject.org/ , https://jhcloos.com/ , https://www.kumari.net/ , https://good.dane.verisignlabs.com/ , https://www.statdns.net/ , https://hacklab.to/ , https://nohats.ca/ , https://dane.rd.nic.fr/ And also please add the "CERT PGP" dns record, for sharing your public-side (master or 2nd-level) GPG-KEY code, which you used to SIGN your binary-installers and other files. Full/entire GPG key code (public-side) can be added into CERT PGP dns record, and that is very important. For more info on this paragraph pls see this bug report : GPG KEY Not Found In Your DNS Records - https://bugzilla.mozilla.org/show_bug.cgi?id=869053 ============================================================================ How would visitors, users, software-updaters will use TLSA or benefit from it ? TLSA based DNS records can be utilized by DANE DNSSEC feature supported client software(s), like, Firefox web-browser, now with assistance from "DNSSEC Validator", "Extended DNSSEC Validator" extension/addons/plugins. But ultimately TLSA detection should be built-into Firefox core itself, ability to use a local DNSSEC supported dns-resolver / dns-client, when present. ======================================================= References: * DANE https://tools.ietf.org/html/rfc6394 * TLSA https://tools.ietf.org/html/rfc6698 * CERT PGP / GPG in DNS : https://tools.ietf.org/html/rfc4398 above doc obsoletes http://www.faqs.org/rfcs/rfc2538.html * DNSSEC and Certificates (Oct 19, 2012) - by Shumon Huque ( How to convert any server cert or CA cert or self-signed cert or paid cert .crt file into a TLSA dns record based cert, using 'openssl' tool, for adding in DNSSEC supported domain-name, so that users/visitors can verify SSL cert from DNS record via using DANE supported apps ) : http://blog.huque.com/2012/10/dnssec-and-certificates.html * Article author 'Paul York' has written this article (on Nov 30, 2012), and informing us, How to use software named "Hash-Slinger"/tlsa created by 'Paul Wouters', to pull-up a SSL/TLS certificate from a web-site ( which is already pre-configured to use a SSL/TLS cert over HTTPS), and then convert that SSL/TLS cert into its equivalent TLSA dns record, so that site visitors can use it via DANE/DNSSEC supported apps : http://www.internetsociety.org/deploy360/blog/2012/11/hash-slinger-helps-you-easily-create-tlsa-records-for-dnssec-dane/ * DANE DNSSEC Test Sites - http://www.internetsociety.org/deploy360/resources/dane-test-sites/ * http://www.gushi.org/make-dns-cert/HOWTO.html (old article, May 2010) * http://www.df7cb.de/blog/2007/openpgp-dns.html (old article, 2007) * http://www.gnupg.org/documentation/manuals/gnupg/ * Thanks to few other users (viktor1dane, ale, joe, emde, van, afolk, tareek, sorry left out many others) from #dnsresolvers and other irc channels, and mailing-list, who have also helped by doing DNS query and by sharing their result, and by helpful active conversation on these. -- Bright Star (Bry8Star). bry 8 st ar a.t ya hoo d.o.t c om GPG_FPR=12B7 7F2C 92BF 25C8 38C6 4D9C 8836 DBA2 576C 10EC. gpg key-id is last 8 digit of above code.

sorry this bug report is dupe , i now see it already exist in https://bugzilla.mozilla.org/show_bug.cgi?id=589537 https://bugzilla.mozilla.org/show_bug.cgi?id=672239 (thanks to user JesperHansen). I will copy some portion from here to the 589537. -- Bright Star.

(In reply to Bry8Star from comment #1) > sorry this bug report is dupe , i now see it already exist in > https://bugzilla.mozilla.org/show_bug.cgi?id=589537 > https://bugzilla.mozilla.org/show_bug.cgi?id=672239 > (thanks to user JesperHansen). > > I will copy some portion from here to the 589537. Thanks, duping to 589537.