Verifying DKIM signatures on Thunderbird with DNSSEC

I’m happy to see that more and more tools are developed to increase the security level and trustworthiness of Internet applications. I already talked about DNSSEC and tools to check the validity of domain names, many others blogged about DANE and TLSA validation support in browsers; this time I would like to focus on DKIM and on a Thunderbird add-on to verify its signatures taking advantage of DNSSEC end-to-end validation.


DKIM is a mechanism to build and verify a trust relationship between an email message and a domain name (usually the sender’s one). When an email message is sent, the sending mail server cryptographically signs its contents using the private part of an asymmetric key and adds a reference back to the public part of the key, that is published under the DNS zone of the sending domain.
Since message recipients base the validation on public keys published via DNS records, it’s important to be sure that data obtained through DNS queries is valid; here DNSSEC takes to the field.


Validation may occur both in the email server which holds the recipient’s mailbox or in the email client running on a user’s device: in the first case a local policy (or a DMARC policy, but this is off-topic for this post) defines what to do with the message (drop it, mark it as spam, …); in the second case the user’s client can show a warning if signature validation fails or a confirmation message if everything is fine. Here I’ll cover the second case.

Thunderbird DKIM Verifier add-on

I came across DKIM Verifier, an interesting add-on for Mozilla Thunderbird that checks DKIM signatures on the client-side and which supports a DNSSEC backend to ensure end-to-end DNS security. I tested the Windows version with good results.

The add-on can be configured to fetch DKIM DNS keys using two methods: a JavaScript DNS library, limited to simple TCP queries, or libunbound, a validating recursive DNSSEC library. To use the second method, the only one that gurantees end-to-end DNSSEC validation of DKIM keys, another add-on must be installed: DNSSEC Validator. At time of writing, only the 2.0.1 version includes libunbound, while the official one (1.1.5) does not.


Installation is built on two-steps: installing DNSSEC Validator (required to use libunbound) and then installing DKIM Verifier. Do it at your own risk.

After downloading the DNSSEC Validator 2.0.1 version, I installed it following the “Installing add-ons downloaded from outside Thunderbird” guide. As stated in the DKIM Verifier DNS Wiki page “the DNSSEC Validator add-on must only be installed, not enabled for this to work”, so I disabled it from the Thunderbird Tools / Add-ons interface.

Then I installed the DKIM Verifier from within Thunderbird, via the Tools / Add-ons interface.


Since security and reliability of this solution rely on DNSSEC, we should verify that the trust anchor used by libunbound corresponds to the one used in the root zone: from the Thunderbird Config Editor search for the extensions.dkim_verifier.dns.dnssec.trustAnchor parameter and check that its value matches the one published at the root zone.

DKIM Verifier trustAnchor parameter (click to enlarge)

DKIM Verifier trustAnchor parameter (click to enlarge)

Then, from the Thunderbird Tools / Add-ons interface, open the DKIM Verifier options window and, in the DNS tab, select the libunbound option from the Resolver list. “Then set the path to libunbound to extensions/ and enable Path relative to profile directory” (more details on the DKIM Verifier DNS Wiki page). Many other settings are available in the options window, take a look at them to fully customise your configuration.

Finally, restart Thunderbird to ensure that new settings will be loaded.


Now, when you open a message that is signed using a DKIM header, Thunderbird will verify its signature and will show the results:

DKIM signed test message in Thunderbird with DKIM Verifier add-on

The add-on detects that the message is signed with a DKIM header, parses it and extracts the signing domain ( and the selector (s=default):

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default;

Then, it uses libunbound to acquire the public DKIM key via DNS, sending a query of type TXT to selector._domainkey.domain (you can do it manually with dig TXT on a Linux shell or nslookup -querytype=TXT on Windows prompt).

This is what happens behind the scenes, as seen from Wireshark…

DKIM key validated using DNSSEC as seen by Wireshark

… and from the Thunderbird error console (Tools / Error console):

libunbound debug while verifying DKIM public key - from Thunderbird error console

The libunbound library takes care of DNS data lookup and possible DNSSEC end-to-end validation, from the root zone down to the domain level.
Of course, in order to have the “secure: true” output you must not only receive a message that is signed with DKIM headers, but it must be under a DNSSEC-secured domain also. In the example I used a message from the CZ domain registry, whose domain ( is protected by DNSSEC. For example GMail, at time of writing, signs outgoing messages with DKIM but its domain is not protected by DNSSEC. The DKIM Verifier Options window, in the Advanced tab, offers some options on how to treat keys which are not signed by DNSSEC.

Please note that libunbound uses cache mechanisms to reduce network traffic: validations following the first one may not require DNS queries toward root zone or TLD if DNSSEC information have already been received.


- DKIM official home-page:

- DKIM on WikiPedia:

- DKIM Verifier Thunderbird add-on on GitHub:

- Unbound:

Share Button

DNSSEC-aware resolvers among RIPE Atlas probes

After reading the interesting post by Stéphane Bortzmeyer on RIPE Labs (How Many RIPE Atlas Probes Can Resolve IPv6-only Domain Names?) I wondered how many RIPE Atlas probes used DNSSEC aware resolvers, so I tried to setup some measures and some comparisons.

As also expressed in the aforementioned post, it should be noted that RIPE Atlas probes can’t be used to represent general behaviors of Internet users; they are excellent “toys” in the hands of network engineers but nobody can ensure that their configuration reflects the one used in production environments by users or by servers or by applications.


  • 6 measurements requested (all with a 1300 bytes size for reply buffer):
    • simple query (#1421265);
    • simple query over TCP (#1421266);
    • DNSSEC OK (DO flag) query against a signed zone (#1421267);
    • DNSSEC OK (DO flag) query against a signed zone over TCP (#1421268);
    • simple query against a broken zone (#1421269);
    • simple query of non-existent record on a signed zone (#1421270);
  • 500 probes requested for the measurements, always the same;

For the signed zone I used, while the choice for the broken zone fell on Parsing of DNS replies is done using the dnspython library (

498 probes are allocated to the first measure: 65 don’t reply at all or return a SERVFAIL/REFUSED error code, 11 are discarded because of parsing problems in the response while 422 of them return a valid response for the simple DNS query; these 422 probes are then used as the basis for all the comparisons that follow.

DNSSEC OK queries against a signed zone

Almost all the responding probes (415 over 422) return a valid answer when queried using the DNSSEC OK (DO) flag (6 don’t reply and 1 is discarded due to parsing problems): of these, 137 perform validation (AD flag), 153 only include RRSIG records in the answer (acting like a proxy) and 125 simply ignore any DNSSEC related information and strip any RRSIG from the answer.

DNSSEC on RIPE Atlas - DO query - responding probes

Broken zone behavior

From the 137 probes whose resolvers perform validation, only 115 return the expected SERVFAIL error code when queried against the broken zone; 11 return FORMERR, 10 don’t reply at all while 1 returns a NOERROR, including the IP address of the broken record too (but, as we will see later, it also resolves an inexistent record)!

DNSSEC on RIPE Atlas - Answers for from validating resolvers

131 of the 153 proxies return NOERROR along with the IP address of the invalid record while 20 return SERVFAIL or FORMERR error codes: are their resolvers using validating forwarders which block their queries? Two don’t reply at all.

Nonexistent record behavior

134 of the 137 validating resolvers also authenticate the denial of existence of not existent record (, by providing AD answers and NSEC records.

From the proxy group of 153 probes, 148 return the NSEC records, confirming their proxy-like function.

100 of the 125 DNSSEC-unaware resolvers return a NXDOMAIN error code, 4 of them also include an NSEC record (even if they didn’t include RRSIG in the correct query); from the 25 resolvers which don’t answer with NXDOMAIN, 18 return a NOERROR: half of them are from the OpenDNS project while the other half use a private IP address (maybe also pointed to OpenDNS servers?). OpenDNS is known to implement a domain typo correction service that resolves invalid hosts and redirects users to a web search page. The remaining 7 probes don’t answer or encounter parsing problems.

DNSSEC on RIPE Atlas - Nonexistent record behaviors


Only 359 probes over the 422 total seem to use resolvers with TCP support; 349 of them also support DNSSEC OK queries: 126 validate data, 126 just proxy RRSIG records and 97 ignore or strip any DNSSEC related information.

Validating resolvers vs proxies

When probes with validating resolvers are compared with those whose resolver blocks broken zones and those that provide denial of existence authentication the result is 114 probes using fully DNSSEC compliant and validating resolvers, 107 of which also supporting TCP.

For what concerns the remaining probes, 145 seem to use resolvers which act like a proxy, providing RRSIG/NSEC records but avoiding validation; 123 of them also support TCP.

DNSSEC on RIPE Atlas - DNSSEC OK, proxy and unaware resolvers

Who are they?

12 of the 114 validating resolvers are on private IP addresses; from the remaining pool of 102 public resolvers, 64 are from the Google Public DNS project, 10 are from the Comcast DNS and 28 are “privately managed” server.

DNSSEC on RIPE Atlas - Who validating resolvers are


Almost two-thirds of the involved probes use DNS resolvers which allow them to perform validation (proxies) or which perform validation on their own (validating resolvers), largely thanks to local configurations based on open public projects implementing DNSSEC.

If we exclude from the computation the number of probes using resolvers from “big DNS projects”, the number of probes that use “private” validating resolvers represents only a small subset of the total.

Moreover, 15% of probes can’t use their resolvers on TCP connection but only via UDP.

Share Button

IPv6 adoption in Italy

After the good IPv6 Working Group presentations at RIPE67 I decided to put togheter some data regarding IPv6 adoption in Italy, analyzing enabled Government websites and enabled access networks.

The results are… quite encouraging from the point of view of the work that needs to be done!

IPv6 enabled Italian Government websites

In the wake of Zuzana Duračinská’s work presented at RIPE67 I built a small lab to analyze IPv6 adoption by Italian Government websites.

As shown in the aforementioned document I used IPv6 Services Monitoring Tool (IPv6-SMT) to analyze 74 websites and domain names taken from the Italian Governement official website ( plus the website used as positive control group.
Analyzed domains include constitutional organs, authorities, armed forces, committees and Commissions, Government agencies and ministries.

Results ( excluded) show that no domains have IPv6 support for web, only 6 (8.22 %) have some IPv6 enabled authoritative name servers and only 1 domain has full IPv6 support on its MX record (thanks to Google Apps hosting its mail service).

IPv6 enabled Italian Government websites

IPv6 enabled Italian Government websites (2013-10-24)

Putting these results next to those showed at RIPE67 (GEN6 – national level only) we have the following situation of IPv6 oriented services:

IPv6 enabled Italian Government websites - GEN6 comparison

IPv6 enabled Italian Government websites – GEN6 comparison

Just a reminder:

Member States should make eGovernment services fully interoperable overcoming organisational, technical or semantic barriers and supporting IPv6
Digital Agenda for Europe, pillar VII, action 89

IPv6 enabled Italian access networks

Measuring IPv6 adoption at the access network level is a quite difficult exercise in which many have attempted.

Thanks to Google IPv6 Statistics data and Eric Vyncke comparison tool we can analyze data about IPv6 enabled web browser accessing Google contents.

Italy seems to be very far from most of the G7 members adoption rates (Italy is the flat azure line at the bottom of the chart):

IPv6 enabled web browser as seen by Google - G7

Only 0.02% of Italian visitors access Google contents via IPv6, while Japan, Germany, France and United States have between 3 and 5 % of enabled IPv6 users and UK and Canada are at 0.21 % and 0.31 % rate respectively.

APNIC also have similar data on its IPv6 Deployment Report:

IPv6 in Italian access network - APNIC - G7

IPv6 in Italian access network – APNIC – G7

It seems we are very far from both the European and the global average usage:

IPv6 in Italian access network - APNIC - Europe and World

IPv6 in Italian access network – APNIC – Europe and World

RIPE also is running a beta tool within the IPv6 RIPEness project to measure real IPv6 deployment from LIRs in the RIPE NCC service region (considering access network + contents): at time of writing, Italy has 42 LIRs with the fifth IPv6 RIPEness star over a total of 929 operating in the Italian area:

LIRs with 5 IPv6 RIPEness stars - 2013-10-01

LIRs with 5 IPv6 RIPEness stars – 2013-10-01

I don’t know what are the causes of this delay; maybe a missing clear legislation which discourages ISPs to adopt IPv6 transition mechanisms, or lack of experience and technical problems on existing equipments, don’t know but I’m sure something has to be done, soon!

Long is the road to IPv6 in the Bel Paese…

Share Button

IPv6 Prefix Calculator

Yes, I’m proud to announce the umpteenth maybe-useful IP subnet calculator (or call it whatever you want): IPv6 Prefix Calculator.

This one is an IPv6 only calculator, particularly focused on prefixes, which allows you to take a base network and split it in smaller sub-prefixes.

IPv6 Prefix Calculator

IPv6 Prefix Calculator

I hope that someone will find it useful; feel free to contact me for any problem or error you encounter using it.

You can find it here:

Share Button

DNSSEC secured blog: raising awareness on DNS security

Hurray! My blog and the whole domain are now running on a DNSSEC secured zone.

Thanks to the recent moving of the blog from the hosted infrastructure to the OVH hosting service I finally managed to enable IPv6 and DNSSEC support.

If you are using a DNSSEC-aware resolver (are you? check it out…) you can verify it yourself:

:~# dig +dnssec

; <<>> DiG 9.8.1-P1 <<>> +multi +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31643
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

There it is the ad (Authenticated answer) flag.

If your resolvers are not DNSSEC-aware – what a shame! Tell your ISP to enable them :) – you can try the same using an open resolver which supports DNSSEC, like those of Google…

:~# dig +dnssec @

… or you can try an online test suite, like the one provided by Verisign Labs or DNSViz.

A nice browser addon – available for Internet Explorer, Firefox and Chrome – allows you to check the DNSSEC validity of the domain names in your browser window. It’s name is DNSSEC Validator and it works even if your resolvers are not DNSSEC enabled (you can set an external resolver different from the one in use in your operating system); here it is a screenshot showing my blog’s status:

DNSSEC secured blog as seen by DNSSEC Validator addon

DNSSEC secured blog as seen by DNSSEC Validator addon

(in the above screenshot you can see a green 6 too, originated from another Chrome addon, IPvFoo, which indicates whether the current page was fetched using IPv4 or IPv6).

This is just a small drop in the ocean of Internet, but I like to believe that it might raise awareness about DNS security matter and encourage its adoption (it seems that as of September 2012 only 1.7% of the visible DNS resolvers in the Internet were performing DNSSEC validation).


RIPE Labs – Counting and Re-Counting DNSSEC – DNSSEC in ccTLDs, Past, Present, and Future/ – ccTLD DNSSEC Adoption as of 2013-07-30 [PDF]

CZ.NIC – DNSSEC Validator

Verisign Labs – Test if you are benefiting from DNSSEC

Verisign Labs – DNSSEC-Debugger – DNSViz

Share Button