Please enjoy this guest post by Agustín Formoso, Software Developer at LACNIC: Regional connectivity is not an easy metric to measure. To do it properly you need measurements generated by multiple vantage points, located in as many places as possible (both geographically and logically). Besides, connectivity is not something strictly defined, as it has no standard definition (as opposed to many metrics we use in today’s Internet).
RIPE Atlas back-end applications run on more than 40 servers. Each day these machines can produce thousands of application logs of any kind of severity level. In order to be able to track down serious errors, warnings or even unusual behaviour, we decided some time ago to try Elasticsearch as a logging sink. In this article we will look at the design of such a system and describe how we can easily make sense from an ocean of logs.
I attended a conference on Broadband Services and Infrastructure Mapping, which I think had some interesting content for RIPE Labs readers.
The IXP country jedi tool described in earlier RIPE Labs articles, can also be used to analyse the situation in a specific city. This time we look at Berlin.
The RIPE NCC has developed an additional interface for the RIPE community mailing lists – something that we hope will encourage more interaction and discussion among the RIPE community.
Recently we have seen an increase in the frequency of excessive traffic towards the RIPE NCC DNS infrastructure. Our servers generally absorb peak loads without an impact on our DNS services. However, to be better prepared for extreme traffic floods, we will work with an external party to provide additional DNS service capacity for serving the ripe.net zone.
Over the last couple of months we've been putting a lot of focus on improving the usability of the RIPE Database web interface. We started with tightly integrating our Single Sign-On system, RIPE NCC Access, into webupdates. This allows users to seamlessly make changes in all of the different RIPE NCC service interfaces while only requiring a single set of credentials. Then we added better validation, auto-complete, "diffs", integrated abuse-contact creation, updates in a text-area and many more tweaks and improvements to enhance the user experience. The last big part of the RIPE Database web interface that was left untouched is Syncupdates. Until now...
In February 2011 the RIPE NCC implemented the "pingable:" and "ping-hdl:" attributes in the RIPE Database. These attributes were added to the Routing Policy Specification Language by RFC 5943 to allow networks to advertise IP addresses that are reachable and can be used as a target for diagnostic tests. Five years later we check how the new attributes have been adopted and how reachable the pingable addresses registered in the RIPE Database are when pinged from RIPE Atlas.
In the past few months, we've added some new features and functionality to RIPE Atlas, including making the DNSMON code available on GitHub for personal use, displaying IPv4 vs IPv6 comparisons in LatencyMON, new credit sharing options, and new limits on probes per measurement and results per day. Learn more about the latest updates - and don't forget to tell us what you think.
Here's how we developed a methodology and open source tools to make it easier to detect route prefix hijacks.
The Elliptic Curve Cryptography (ECC) is becoming increasingly popular in DNSSEC. While it is sometimes considered to be a remedy for the low DNSSEC adoption rate, there is also a lot of controversy around it. One of the main concerns is that DNSSEC-validating resolvers don't always make use of ECC. We used RIPE Atlas to measure the support for ECC in DNS resolvers.
Internet interconnection has often been described as an unregulated field. However, local public regulation is starting to emerge – be it through disclosure regulations, mandatory peering or licensing terms. Due to the networked nature of the internet, local rules may acquire a global scope.
We’ve updated our IPv4 graph to tell the whole story about our remaining address pool.
A new tool joins the family of applications whose goal it is to take full advantage of RIPE Atlas to monitor availability, consistency and reachability of networks and services: the RIPE Atlas Monitor.
This week, the RIPE NCC saw a milestone as the 10,000th Local Internet Registry (LIR) received IPv6 addresses. The first block of IPv6 addresses was allocated from IANA to the RIPE NCC in 1999, so we have been distributing IPv6 addresses for 17 years. In those years we have seen interesting policy developments, making it easier for LIRs to obtain enough IPv6 to satisfy their needs. In this article we track the policy developments that have made it progressively easier for LIRs to get the IPv6 they need.
The RIPE Atlas Interface Hackathon is an opportunity to work together with RIPE Atlas developers and other enthusiastic coders and hackers. The hackathon will take place from 21-22 May in Copenhagen ahead of the RIPE 72 Meeting. Find out how you can take part!
We tend to make a number of assumptions about the Internet, and sometimes these assumptions don’t always stand up to critical analysis. We were perhaps ‘trained’ by the claims of the telephone service to believe that these communications networks supported a model of universal connectivity. Any telephone handset could establish a call with any other telephone handset was the underlying model of a ubiquitous telephone service, and we’ve carried that assumption into our perception of the Internet. On the Internet anyone can communicate with anyone else – right?
Following my research on DNS reachability and performance, I found interesting results for specific domain names.
The RIPE NCC membership has raised concerns regarding members setting up additional Local Internet Registry (LIR) accounts. The RIPE NCC Executive Board is now asking the RIPE NCC membership to discuss this. The article below provides some background information, data and statistics for the discussion.
This is the second part in a series of articles looking at the use of DNS servers in Iran. For the second part I will continue measuring performance and reachability for two more sets of DNS resolvers: TIC and Verisign.