This past weekend several of my Dyn colleagues and I attended the DNS-OARC annual meeting and fall workshop in Montreal. “OARC” in the organization’s title stands for “Operations, Analysis and Research Center”. DNS-OARC was founded by the Internet Systems Consortium (best known as the maintainers of the BIND DNS software) in 2004 to address a gap in the DNS community. Engineers working to extend the DNS protocol itself have always had a home in the Internet Engineering Task Force (IETF), but there was no corresponding community for those who operated DNS infrastructure and did research using data gleaned from DNS operations. DNS-OARC provided a much-needed dedicated forum for DNS operators and researchers to gather and collaborate.

I was on DNS-OARC’s board of directors early in the organization’s lifetime and back then, things were certainly different. The organization could only afford a single staff member—an executive director. Running two workshop meetings per year consumed much of the organization’s time and resources. These workshops were always successful, but it took arm twisting to find people willing to present and attendance was measured in dozens. Now DNS-OARC has the equivalent of three and a half full-time employees on staff and the budget has doubled. There’s a proper program committee to choose material for the workshops and this workshop had more submissions for presentations than the agenda allowed. Plus, a whopping 138 people registered for this most recent workshop!

The weekend was packed and started with the annual business meeting. Several board members’ terms were up and there was an election. I’m pleased to report that Dyn’s Dave Knight was re-elected to a seat on the board of directors. Congratulations, Dave!

After the business meeting, the workshop proper started and the content was outstanding. I’m proud that Dyn was able to contribute. Jim Cowie, Dyn’s Chief Scientist, spoke on “Internet Performance Impacts of Canadian Content Hosting”. Using the zone file from Canada’s ccTLD, .CA, he researched where Canadian web sites are actually hosted and what performance impact that has on Canadian Internet users. Only about 19% of all Canadian content is hosted in Canada, likely due to the proximity of so many seemingly good hosting options just across the southern border in the U.S. But milliseconds matter: users in Vancouver, BC pay a noticeable latency penalty to reach content hosted in a U.S. west-coast location, such as the San Francisco Bay Area. The conclusion of his research: host Canadian content in Canada for the best performance for Canadians as well as the rest of the world (we’d like to offer a big thank you to CIRA, the .CA registry, for giving us access to the .CA zone file to do this research).

I spoke, too, with a presentation entitled, “Analyzing the distribution of DNS clients to recursive name servers across the Internet”. I used a large data set gathered from Dyn’s new Real User Monitoring (RUM) service. Our customers can enable this monitoring service just by adding a single tag to their website’s main page. Once enabled, visitors to our customer’s website will download and run a small piece of Javascript that measures performance to different websites in the background, without affecting the user’s web browsing experience. This performance data from the viewpoint of “real users” gets sent back to Dyn, where it joins our other data sets (data that no one else has!) and allows us to continue to expand and refine our unrivaled view of Internet performance.

Our real-user monitoring has a happy consequence for our DNS research: for every web browser that makes a measurement, Dyn learns the address of that client’s recursive name server (but that’s all we learn: there’s no personal identifying information returned or any information about what the user is browsing). Recursive servers are usually found at ISPs or in enterprise networks and they perform the “heavy lifting” in the DNS system: they look up queries on behalf of users by contacting various DNS servers all over the Internet. There hasn’t been a lot of research to characterize the relationship between clients and the recursive servers they use. For example, how many clients does an average recursive server even have? Are the users of a recursive server usually in the same network? The same country or city? Or are they widely distributed? Which organizations run the largest recursive servers, i.e., the servers with the most clients? My research using this vast data set of nearly 230 million entries let Dyn answer some of these questions—to our knowledge—for the first time. I’ll be writing up my findings on the Dyn Research blog in much more detail soon.

Of all the events I attend each year, the two DNS-OARC workshops are my favorite and the most valuable. Not only do I see great presentations, but as with most technical meetings, the hallway conversations are just as important; it’s a great opportunity to catch up with friends and colleagues in the DNS community. We’re a small technical group that keeps DNS working on the Internet and your colleague one day may work for a competitor the next. But I’ve noticed that who works for whom isn’t important once the presentations start and the talk turns technical. Then you see a bunch of engineers working together on everyone’s common goal: to keep DNS up and running and to keep learning.

I’m grateful that Dyn can contribute to DNS-OARC and continue to play our part in keeping DNS up and running, and helping our customers connect faster, safer, and more reliably than ever.