501(c)(3), RU nodes, and ISATAP DNS

Lots of updates after a brief summer hiatus

The summer brought a brief pause on our monthly newsletters as we took a couple of months off. While the newsletter was paused, we have had many plates in the air that we are working through. Activities that will be picking up in the back-half of the year:

• Back-end work (capacity, redundancy, and resilience).

• Organizational up-keep (bookkeeping and tax planning).

• Preparing for an exciting 2023 (stay tuned to these newsletters).

The most notable update is that our application for Dataplane.org as a U.S. federally recognized not-for-profit organization has been accepted.

As a non-profit organization, we will begin accepting donations to further our mission. Dataplane.org NFP aims to improve Internet infrastructure operations by facilitating access to raw data collections, measuring Internet activity, analyzing trends, and supporting researchers.

Network Nodes with Russian Providers

As some of you know, we have been discussing our official position on conducting economic activity with Russian hosting providers. The dilemma we face is whether or not to continue funding Russian providers, even if legally permitted by national guidelines. The measurement data we obtain from these nodes helps provide a view into an important Internet region and allow our community the ability to observe the impact of world events on Internet activity. Some would suggest we have a moral obligation to avoid enriching any Russian-affiliated entity or individual. Others have said, we are duty-bound to provide complete insight where legally permitted to do so.

This is not a decision we are comfortable making without legal counsel, so for the time being, we have halted new funding for any Russian-based services. Over time Russian services will fade due to a lack of renewal payments. If we decide to continue or revive Russian-based services on the recommendation of legal counsel, we will reinstate services there after considerable deliberation on how we select and manage providers in the future.

We appreciate the thoughtful comments from our friends and advisors on our Slack channel on this matter. We welcome further comment and feedback from our newsletter subscribers. Please reach out ot us and send us your thoughts and concerns. We exist to try to reflect what is useful and helpful to the Internet community, so please tell us what you think that should be.

ISATAP and DNS

One of the legacy IPv6 transition mechanisms called for the use of a DNS query to locate an IPv4 to IPv6 tunnel router. This mechanism, known as Intra-Site Automatically Tunnel Addressing Protocol or ISATAP was featured in a recent research publication by one of our co-founders. As part of that research, the Dataplane.org infrastructure was used to operate a set of authoritative DNS name servers for dozens of ISATAP names within various top-level and second-level domains. These name servers are used to measure and analyze ISATAP usage in-the-wild.

Even though ISATAP is now considered an obsolete mechanism, and has never attracted widespread usage, many existing client IPv4-only systems, particularly Microsoft Windows version 8.1 or earlier, try to locate a tunnel server by issuing an ISATAP query for their locally configured domain. Due to how this transition mechanism functions, a client may issue queries to our ISATAP name servers when their default domain is one where we have registered the ISATAP hostname. The research paper contains additional detail and evaluates the risk of such behavior. There you can find insight into the susceptible population of clients still attempting to obtain IPv6 connectivity through an ISATAP tunnel relay router.

In this month’s newsletter, we provide insight into the DNS traffic we see from these ISATAP queries. The volume of queries, resolver behaviors seen at our servers, and the inference of ISATAP clients can tell us a lot about today’s Internet DNS subsystem.

First, look at the daily query volume of our ISATAP name servers in this plot below:

In May 2022, we see the common saw-tooth pattern of network traffic activity, where the valleys represent weekends when systems tend to be used less. This picture alone tells us relatively little other than a fairly significant amount of ISATAP query traffic exists in-the-wild.

If we show the volume of queries broken down by the name server that receives ISATAP queries, we better understand how our DNS servers are used. We have one name server in France (NS1) and another in the U.S. (NS2).

The two servers depict roughly the same pattern, but NS1 sees more queries overall. Is it performance (i.e., lower latency by clients using round-trip-time measurements), or something else? Without digging further, we hypothesize that NS1 has lower latency for more queries. Why? Because the majority of the ISATAP queries tend to originate from systems nearer Europe than North America. Most clients are likely “closer” to NS1, and, therefore, will have slightly better round-trip-time estimates to that server, which will lead to more queries landing there on average.

Here is a picture we found quite interesting:

We’ve removed the legend, but each colored line represents a specific IPv4 or IPv6 address of a resolver querying our authoritative name servers. Two features stand out. One is that these resolvers don’t seem to follow the saw-tooth pattern we saw from the aggregate picture. One resolver is querying significantly more than the others, but also notice the valleys where queries for a couple of resolvers appear to have fallen to or nearly to zero in the second week of May. What do we suppose is happening here? Perhaps those two valleys represent a network or system outage?

Are you interested in DNSSEC? Have you wondered whether or not resolvers express interest in validating answers from your authoritative servers? We wondered about that, and we can provide a partial answer. Take a look at this plot:

The top blue line indicates that a resolver has set the DO (DNSSEC OK) bit in the query. Notice how many more queries set that bit than don’t. Our servers see queries from all the popular resolver services (e.g., Google, OpenDNS, Cloudflare), many of which are known to set this option. While this isn’t a complete picture of DNSSEC deployment, it gives some sense of common behavior, and this is precisely the sort of thing we aim to help shed light on.

There is much more to explore, but we’ll leave it to you, dear reader, to ask us the questions you’d like answered. If we can provide answers, we will in a future newsletter. If we can’t answer them, we’ll certainly consider what we need to do to get the data or measurement in place to do so.

The State of Dataplane.org

As previously mentioned, we made progress with our organizational structure by receiving official approval for not-for-profit, tax-exempt status 501(c)(3). With this step completed, our focus shifts to identifying banking options for our organization by understanding any mandatory requirements, reviewing banking rules, and understanding fee structures to see what fits best with our non-for-profit. Along with the bank services selection, we are sure everyone is interested in all the details; we are researching the requirements for IRS compliance! Our team continues to monitor legal concerns with international regulations, sanctions compliance requirements, and intellectual property issues that could affect our operations.

Once the financial foundation is complete, we will look for opportunities for funding that will allow us to improve current services and identify new services to benefit the community and align with our mission to increase awareness, leading to a more robust and secure Internet.

In the not-so-distant future, we are hoping to be at a location near you, or at least virtually. We are reviewing opportunities to present at conferences and participate in speaking engagements to share our mission, how we do our work, insights from our measurements, and educate the community on the services we provide. Let us know if you have suggestions on topics that you want covered in these engagements.

We welcome your feedback on any items covered in our update or suggestions for improvement.

Feel free to reach out via email, Twitter, or Slack (request an invite if you need one).