The Modern Resolver Behaviours Work Party has two general areas of work: the code bases of DNS resolvers, and the actual resolvers on the Internet. This discussion is about the latter. The two tasks from the Statement of Work: 1. Analyze DNS resolver network traffic and behaviour to better understand how they operate as they interact with authoritative servers generally and the RSS specifically in terms of preferred root server selection. 4. Analyze DNS resolver systems using multiple resolution instances (with potentially individual or shared caching systems) to understand how they interact with the RSS. (e.g. google, cloudflare, quad9 type systems) Currently, these tasks are only being done at a large scale by APNIC. The APNIC resolver test system has three basic parts: - Javascript code that contains unique names - A mechanism to get that Javascript in front of a large number of users - Authoritative servers to receive queries from resolvers and provide customized answers The Javascript code is relatively easy to create. There are many ways to set up the authoritative servers using enough programming and configuration creativity, good logging, and horsepower. The mechanism for getting the Javascript in front of user largely controls the value of the data received from the test system. For its delivery mechanism, APNIC uses the Google Ad network using nearly-free advertising given to APNIC. As part of this plan, APNIC cannot control who will see the ads in the short term, but it appears that Google tries to get a wide dispersion of ads over the longer term. Other delivery mechanisms are possible, such as: - Other advertising networks. These might have wider or at least different user populations, depending on the content of the ads that are prevalent on the networks. - Web properties with international scope. For example, a business that has users throughout the world might be willing to host the Javascript. - Games or other applications with international scope. These would likely be more focused on younger Internet users. There are additional issues such as: - Should a user be prevented from contributing more than once? Even if they move between networks? - How much information is it acceptable to get from the user before we get into the PII realm? - Is it useful to compare "home" users and "office" workers? Or users during "the day" and "at night"? Some of this comes down to if RSSAC wants to just measure resolver behavior versus also measuring the user population behind a resolver. In the former case, the goal of the delivery mechanism is just to get any user behind a resolver to participate, but not to worry about representation. In the latter case, there are more questions about counting the same user multiple times and the locality of users in the delivery mechanism.