RIPE Atlas: a script to show ASes traversed in traceroute

I released a small Python script which reads results from RIPE Atlas traceroute measurements and shows Autonomous Systems traversed by probes to reach the target: ripeatlastracepath.

It uses a library that I wrote to cache RIPEstat results about IP addresses details (ASN, prefix, …), in order to improve performance and to avoid a flood of requests: ipdetailscache.

More details can be found on my GitHub profile page.

A demo can be found here. It can’t be used to process other measurements, it only shows results from measurement ID 1674977, a traceroute from 50 probes all over the world toward You can drag&drop ASes to build the layout that best describes your scenario and, once done, you can “save” the graph for later usage. In this demo the “Load graph” button gives a preset of JSON data representing the example graph below:

Graph of traceroute to

These scripts are not so elegant, but do the job! ;) They are on, feel free to use/edit/fork/improve them as you whish!

Avoid Cisco FIB/TCAM exhaustion on full BGP table feed

The number of IPv4 prefixes in the global BGP table is approaching the limit of many Cisco products, such as 7600/6500 RSP720/Sup720 and some ASR1000, which may hold a maximum of ~500K routes in their FIB (the Forwarding Information Base, where only best paths are stored).

These routers can usually handle a bigger load of prefixes, they can also be used to receive the full BGP table from many upstream providers concurrently, but they can’t manage more than 500/512K entries in their RIB or FIB.

Routing protocols to FIB

On 6500/7600 platforms, the default PFC3BXL/PFC3CXL TCAM configuration provides 512K entries for IPv4 and 256K for IPv6; the show mls cef maximum-routes command allows to show the running TCAM layout, that can be changed by entering mls cef maximum-routes ip … (it requires a reload).

7600(config)#mls cef maximum-routes ip 768
Maximum routes set to 786432. Configuration will be effective on reboot.

7600#show mls cef maximum-routes
FIB TCAM maximum routes :
Current :-
 IPv4 + MPLS         - 512k (default)
 IPv6 + IP Multicast - 256k (default)

User configured :-
 IPv4                - 768k
 MPLS                - 16k (default)
 IPv6 + IP Multicast - 120k (default)

Upon reboot :-
 IPv4 + MPLS         - 512k (default)
 IPv6 + IP Multicast - 256k (default)

While this method allows to patch the immediate requirement for more IPv4 FIB space, it has the side effect of reducing the IPv6 resources, which are supposed to be more and more needed in the future.

Some ASR1000 platforms support up to 500K IPv4 routes and, as far as I know, they don’t allow RIB/FIB repartition.

In some scenarios, in order to continue using these routers while avoiding performance impairments, the BGP – Selective Route Download feature may help.

Routing protocols - table-map - FIB

The BGP—Selective Route Download feature allows a network administrator to selectively download some or none of the BGP routes into the Routing Information Base (RIB). (

Sample scenario

Suppose to have a border router which receives 3 BGP feeds: some prefixes from a multihomed customer, some from an Internet exchange and the full table from a transit provider. This border router is also connected to a core router, where other border routers and the rest of the network is connected too. Configuring the table-map … filter option on the border router allows to prevent its FIB to be loaded with a lot of useless prefixes, which may be summarized with a default route toward the transit provider.

BGP prefixes filtering with table-map

Filtering may be based on many parameters; the one I used here is the next-hop address of each learned prefix. The final configuration looks like this:

router bgp xxx
 address-family ipv4
  table-map BGP-Table-IPv4 filter
route-map BGP-Table-IPv4 permit 10
 match ip next-hop BGP-NextHop-OK
route-map BGP-Table-IPv4 deny 10000
ip access-list standard BGP-NextHop-OK
 deny Transit_Provider_IP
 permit any

In order to minimize the changes to the standard configuration, an access-list is created which only denies the transit provider’s next-hop address.
Preferred prefixes learned from the Internet exchange and from the multihomed customer are permitted (not denied) by the access-list and, consequently, by the BGP-Table-IPv4 route-map referenced in the table-map command. Other prefixes are denied by the route-map and prevented from entering into the FIB, but they are anyway kept in the BGP database and announced toward the core router. Local-pref and other features may be configured on the routers to implement usual routing policies. Of course, in this example the core router must have a big enough FIB to handle the full BGP!

Please note that before configuring this feature, specific considerations are needed about local routing policies and traffic engineering mechanisms; special attention should be paid to locally generated prefixes announced to the border router by the rest of the network. As always, do it at your risk!


CIDR Report: Summary of total route table size for the past 7 days Cisco 7600 Series Route Switch Processor 720 Data Sheet Cisco ASR 1000 Series Embedded Services Processors Data Sheet BGP – Selective Route Download

RIPE68: Content blocking methods and their impacts

Today, in Warsaw, during the RIPE68 morning session reserved for the Cooperation Working Group, Olaf Kolkman kindly presented my work about Content blocking methods and their impacts.

Olaf’s presentation was the first in a series of 3, all about censorship and censorship circumvention.

Content Blocking Methods And Their Impacts

My work was born within a discussion on the RIPE Co-op Working Group mailing-list with the goal of depicting the impact of various content blocking mechanisms, in order to reach a final guide for policy makers and legislators called to solve social issues by using web filtering methods.

Unfurtunately, the time slot allocated to Olaf’s presentation was too small to allow him to give a full overview of impacts, side effects and hidden costs related to content blocking methods. More details can be found on the online resources:

- on the RIPE68 Cooperation Working Group Agenda you can find the slides and the video of the presentation;

- here on my blog I’m hosting the first version of the document A Technical Overview of Content Blocking Methods;


- on the IETF website you can find the other document that Olaf talked about in his presentation, Technical Considerations for Internet Service Blocking and Filtering by IAB.

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:

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.