Skip to main content

Root Server Operators: Diversity is the Key

Over the past week, we’ve seen some buzz over a set of events that occurred last week, which impacted a small proportion of the Root Server Operators. While ICANN does operate L-Root, we do not speak for the collective of Root Server Operators. In the spirit of transparency, the Operators have a published a collective statement regarding the events. You can read it here.

ICANN completely agrees with and supports the text in the Root Server Operators statement. However, there are a couple of salient points that we would like to expand upon.

While attacks like these are rare, they can and do happen. In fact, there might be any number of reasons that your Internet Service Provider’s (ISP) Domain Name System (DNS) resolver can’t reach one particular root server. This could be related to your ISP’s routing, or some level of unrelated international network event, such as a severed submarine cable. The DNS protocol is designed to be resilient in these scenarios, and it worked as expected.

Diversity in the system is fundamental to why this works as it does. ICANN makes operational decisions on how it operates and locates L-Root anycast instances independently from the other root servers, even down to the software we choose. This diversity means there is substantial operational resiliency in the entire Root Server System.

Unfortunately, many seem to be saying, “Oh my, a root server or two didn’t respond for a short period of time – this must be bad!” However, it’s important to look at the events in their entirety to determine how we should react.

When I was made aware, my first response was, “Wow! The entire system works.” There was no discernable impact on end users, even though some root servers weren’t available for a short period of time. So people were still able to visit websites, YouTube uploads didn’t stop, online shopping continued and users were able to upload photos of their food to Instagram.

Does this mean the entire Internet operations community should become complacent? Absolutely not. The Root Server Operators statement highlights a salient point. If all network operators implement the provisions from BCP 38, the attacks that were attempted towards the Root Server Operators would not have occurred in the first place. In fact, a vast number of these “spoofed” or forged source address Denial of Service (DoS) attacks that target many organisations or individuals would be stopped in their tracks.

So here is my challenge to you: Does your company implement BCP38? Does your ISP implement BCP38? Do you have a contract term that specifies they implement BCP38? If not, encourage them to do so. Implementing BCP38 ultimately protects you, your own interests on the Internet and the Internet as a whole.


    juliemartin  08:44 UTC on 14 December 2015

    Thanks. We well understand ICANN operations.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."