The survey is the brainchild of Viktor Dukhovni <email@example.com>, a coauthor of RFC7672 which defines DANE for SMTP, and the developer DANE implementations in Postfix, Exim and OpenSSL. Hosting for the survey is generously supported by USC's Information Sciences Institute. Wes Hardaker (USC/ISI) summarizes the results of Viktor's data collection efforts and produces the graphs found on the main statistics page.
We believe that the survey is for the benefit of both you and the Internet. We scan the Internet for DNSSEC and DANE related growth and problems, letting operators (like you) know when we detect problems. To achieve this goal, we ask that SMTP connections from the survey not be blocked.
Scanning OPT-OUT information: we scan both DNS records and DANE/TLS/SMTP servers from the dnssec-stats.ant.isi.edu host. If you wish to be added to our Out-Out list for your domain name(s) or IP address(es), please contact firstname.lastname@example.org and include the IP addresses and/or names that you wish to be added to the opt-out list.
The purpose of the survey is to promote DANE adoption by:
The survey runs once per day. It checks the status of each DNSSEC-signed domain delegated from a parent domain on the Mozilla public-suffix list (generally just the top-level domain of a given organization). Domains internal to organizations are not included.
The DNS data collected includes:
If an MX host does have TLSA records, then an SMTP connection is made to each IP address of the MX host, and a STARTTLS handshake is performed (assuming STARTTLS is offered, as it needs to be for a host with published TLSA records).
The certificate chain is then compared with the TLSA records, and if all goes well, for all the MX hosts, the domain is counted as one of the successful deployments reported in the aggregate statistics.
If, on the other hand, one or more of the MX hosts with TLSA records fails to offer or rejects STARTTLS, or presents a certificate chain that does not match its TLSA records, then reasonable effort is made to find technical contacts for the domain, and a notice is sent to those contacts detailing the problems found.
In the majority of cases, each SMTP server will see at most one connection per IP address per day, provided it has TLSA records under just one name.
If an SMTP server has multiple names with associated TLSA records, then it potentially also has multiple certificate chains (selected via SNI). Connection de-duplication is therefore by name, and so SMTP servers known under more than one name may see more than one connection per IP per day. At present, in the worst case, this still yields a modest number of connections per IP, spread out over a few hours.