- rssac-caucus - lists.icann.org

Work Party [Rogue RSO]: Thoughts on a definition of "Rogue Operator"
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 5, 2020

May 5, 2020

Throwing out some ideas on terminology for the rogue operator work party. Please feel free to share your thoughts on these. -Ken Non-sanctioned Operator: This could be an enterprise that serves the root zone [possibly with modifications] to its internal users, fully within their authority. This purposefully avoids the term "rogue" and its negative implications. This could be done via recursive resolvers configuring non-standard root servers, or by impersonating RSO address space only within the domain of their authority. Do we need a separate term for cases where they do this outside of their authority? Impersonating Operator: An authoritative server, serving the Root Zone publicly, that is run by someone other than the 12 Root Server Organizations, responding to one or more the 26 root server addresses. These organizations do not necessarily uphold the guiding principles of the root server operators. Correctness of the served zone is irrelevant? This also purposefully avoids the term "rogue" and its negative implications. (Impersonating Operator, Imposter Operator, Fake Operator, … word-smithing encouraged) Rogue Operator: A legitimate Root Server Operator that decided to do "bad things". A starting point for defining "bad things" would be a violation of some set of the 11 principals defined in Section 3 of RSSAC037. Specifically: Guiding Principal #2: IANA is the source of DNS root data -- If an RSO serves a non-IANA root zone or a modified IANA root zone, they are in violation of this principal Guiding Principal #6: The IETF defines technical operation of the DNS -- If an RSO does not support the protocols as defined by the IETF, they are in violation of this principal. Serving protocols in addition to IETF protocols should not be considered in violation (flame away, here) Guiding Principal #7: RSOs must operate with integrity and an ethos demonstrating a commitment to the common good of the Internet -- this one is pretty open-ended. Guiding Principal #11: RSOs must be neutral and impartial -- serving data with intentional bias of query source/content (e.g. serving slow or incorrect data to market competitors or governments) Lots of room for discussion here More ideas welcome There could be more definitions and we can certainly refine these. Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil

2 1

Study of the root zone management process
by Paul Hoffman May 5, 2020

May 5, 2020

Greetings. Recently, ICANN put out a request for proposals (RFP) for a study on the process that is used to manage the root zone. Please see: https://www.icann.org/news/announcement-2020-04-28-en Note that this study is part of the IANA transition; it was recommended by the group that created the transition process. I bring this up here because some of you might know people or organizations who are qualified to perform the study. If so, please pass this information to them. --Paul Hoffman

1 0

Re: [RSSAC Caucus] [Ext] TCP and TC (was Updating the RSSAC FAQ)
by Fred Baker May 5, 2020

May 5, 2020

Sending again using the right email address. > On May 4, 2020, at 9:01 AM, Fred Baker <fredbakersba(a)gmail.com> wrote: > > Stepping aside a bit from the question of the FAQ... Yes, this is a change of subject, which is why I changed the subject line. > > Does this become a requirement for resolvers using the RSS? RFCs 1034/1035 only hint at it (they define the bit without defining its use case). If, however, I look at RFC 2181, it says > > Where TC is set, the partial RRSet that would not completely fit may > be left in the response. When a DNS client receives a reply with TC > set, it should ignore that response, and query again, using a > mechanism, such as a TCP connection, that will permit larger replies. > > In the absence of any other alternative that reliably works (Geoff will argue from his data that IP fragmentation and reassembly is not a mechanism that works reliably to transport larger replies, and protocols like SCTP and QUIC are not generally used to communicate with the RSS), that reads to me as "responding with TC set means 'please ask again using TCP'". > > The interface between a host and its resolver is another question; I would argue wants gets the same answer, but that's perhaps secondary to a conversation about the RSS. > > So, is it reasonable to say that the ability to pose a DNS request and receive a response using TCP, and using TCP as the fallback transport when TC is invoked, is a requirement of a modern resolver? > >> On May 4, 2020, at 1:44 AM, Andrew McConachie <andrew.mcconachie(a)icann.org> wrote: >>> On May 1, 2020, at 22:22, Geoff Huston <gih(a)apnic.net> wrote: >>>> On 2 May 2020, at 1:25 am, Dave Lawrence <tale(a)dd.org> wrote: >>>> Geoff Huston writes: >>>>> "Finally, many more resolvers today are capable of falling back to >>>>> TCP when they receive a truncated response over UDP” >>>>> >>>>> really? Where is the study that publishes this finding? >>>> >>>> It could use clarification, certainly, beyond just the fuzziness of >>>> "many more". There are several metrics which could all claim to be >>>> relevant. A few of them seem like they are probably true in raw >>>> numbers if only because of overall growth over the past couple of >>>> decades (and yes, good measurement would confirm that). Like: >>>> >>>> * Total number of implementations >>>> * Total number of running servers >>>> * Total number of people served (not strictly a resolver, but still relevant) >>>> >>>> But, maybe that picture changes when you ask about the percent of the >>>> whole, and then "many more" might not apply. >>>> >>>> Measurement rules, for sure. I also don't think it is entirely out of >>>> place to make a qualified claim based on our cumulative anecdotal >>>> experience that overall the TCP fallback scenario is improved now vs >>>> the past, as long as it clear that it is supposition rather than data. >>>> >>> >>> My measurements of TCP use from time to time report that the relative number of >>> users that sit behind recursive resolvers that cannot perform TCP appear >>> to be unchanged for the 6 years that I’ve looked (from time tim time). Now >>> there are many ways of reporting DNS (resolvers, users, queries, … as well as >>> absolute numbers or relative numbers). >>> >>> Therefore I don't understand the basis of the TCP claim in that report - it seems >>> apocryphal to me >> >> I’ve deleted that sentence from the answer to question 1. The answer no longer makes any statements regarding how many resolvers can fallback to TCP if UDP comes back truncated. >> >> —Andrew >> >> _______________________________________________ >> rssac-caucus mailing list >> rssac-caucus(a)icann.org >> https://mm.icann.org/mailman/listinfo/rssac-caucus >> >> _______________________________________________ >> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. >

6 6

Work Party [Rogue RSO]: Summary of kickoff meeting
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 4, 2020

May 4, 2020

Summary The "Rogue Operator" Work party held its kickoff meeting on Friday, 1 May 2020. Participation was good with approximately 20 people. With only mild interest in volunteering for the role of Work Party Leader, it was decided to postpone the selection of a leader until the next meeting, allowing participants to learn more about the topic. The Statement of Work was presented and a few topics were discussed among the group. For future meetings, a doodle poll will be initiated to determine one or two standing times for monthly calls. Plans to hold a work party meeting as part of the ICANN 68 (Kuala Lumpur, virtual) meeting were dismissed as the work party preferred to decide on a time slot on their own versus being tied to local time in KL. Action Items 1. Staff will conduct a poll to determine a standing meeting time for monthly calls 2. Work Party members are encouraged to volunteer to act as work party leader 3. Work Party members are encouraged to continue discussions on the RSSAC Caucus mail list on new or existing topics related to this work party. 4. Ken Renard and staff will send out meeting summary to RSSAC Caucus mail list Topics discussed A good definition of “rogue” The original use of the term "rogue" came from RSSAC037 in reference to how an existing Root Server Operator could be removed from its duty. There are negative connotations of the term rogue (in US English), but the term seems to be fitting as long as we can define what it means in the perspective of an RSO. Some of the scenarios discussed were: "Unexpected behavior" Serving anything other than the true IANA root zone to users outside of your organization/scope-of-authority. This means that enterprises who extend the root zone _only_ for their internal users would _not_ be considered rogue. If such an enterprise serves users outside of their authority, then that would be considered rogue Restricting the term "rogue" to only legitimate RSOs versus non-RSOs acting as an RSO (answering queries on one or more of the 26 ‘official’ addresses) "Intention" - while the intention to deceive is an obvious indication of a rogue operator (or server), it is not up to this WP to determine intention. Organization / Government roles There may be cases where an organization or government requires (by law?) that the root zone must be modified. These are outside the scope of our determination of "rogue-ness" and are not true RSOs (what if they are responding on RSO IP addresses?) Are these "fake" instances (use term other than "rogue"). Other potential terms: "non-IANA", "non-standard", "non-sanctioned" RSOs serving zones other than '.', '.arpa', or '.root-servers.net’ It was brought up that some RSOs may serve zones other than these 3 on their Root Server IP addresses. This should not lead to any change in the root zone information served, but it could mean that some root servers return different results to the same query (such as additional records). A follow-on email from Wes indicated that no RSOs are actually doing this now. This might be an interesting hypothetical discussion for root ops. Agenda topics for next meeting Select a work party leader Document examples of changing the root zone that could cause problems Discussion of scenarios that would be considered rogue RSO-gone-bad (example, serving incorrect zone data) Non-sanctioned RSO (a recursive resolver that uses an alternate root server list) Practicality of detection strategies Discussion of damage that could be done by a rogue operator Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil

1 0

Work Party [Tool for Local Perspective]: Summary of kickoff meeting
by Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) May 4, 2020

May 4, 2020

Summary The "Local Perspective" Work party held its kickoff meeting on Thursday, 30 April 2020. Participation was good with approximately 20 people. There was interest in volunteering for the role of Work Party Leader, however, it was decided to postpone the selection of a leader until the next meeting, allowing participants to learn more about the topic. The Statement of Work was presented and a few topics were discussed among the group. For future meetings, a doodle poll will be initiated to determine one or two standing times for monthly calls. Plans to hold a work party meeting as part of the ICANN 68 (Kuala Lumpur, virtual) meeting were dismissed as the work party preferred to decide on a time slot on their own versus being tied to local time in KL. Action Items 1. Staff will conduct a poll to determine a standing meeting time for monthly calls 2. Work Party members are encouraged to volunteer to act as work party leader 3. Work Party members are encouraged to continue discussions on the RSSAC Caucus mail list on new or existing topics related to this work party. 4. Ken Renard and staff will send out meeting summary to RSSAC Caucus mail list Topics discussed Limiting scope Duane brought up the point that the work party might be attempting too much to come to a successful conclusion. While implementations of a full set of tools and a data collection infrastructure would be nice to have, these seem like goals that can be put off for future work. The work party should concentrate on defining metrics to achieve the goals of the intended audience. Other research Jaap contributed that CAIDA has been conducting similar research to date and we should reference that work and leverage its results as appropriate. A reference to any publications from this work would be useful for the group] Purpose of this work The purpose of this work is broken in to 2 categories: advising the RSS on placement of new instances and giving the end-user a measurement of their perspective of the RSS. Advising the RSS can only be successful if there are a large and "well-distributed" set of measurements. Measurement of endpoint to RSS versus via configured resolver The work party had a discussion on the desire for a tool to measure direct perspective of the RSS versus measuring perspective via a configured recursive resolver. The tool(s) may be run on a wide variety of platforms such as mobile devices, desktop hosts, data center servers, enterprise recursive resolvers, etc. Direct measurement to the RSS would be interesting for potential placement of new RSS instances, but location of the measurement (such as mobile endpoints) need to be considered. Measurement via the configured recursive resolver would be useful for anyone to get a perspective of their enterprise/ISP configuration. Agenda topics for next meeting Select a work party leader Enumerate end-user use cases: Researcher/curious user in a University or Enterprise network Enterprise IT staff (recursive resolver operators) Topologically-remote network. Well-connected data centers (Google/CloudFlare) good for comparison? Home users (testing ISP versus public DNS perspective of root) RSOs Discussion of CAIDA research What set of measurements would be useful for testing perspective directly to RSS? Let's get an initial list to ground general thoughts on the set. We will revisit this periodically. Local IP (ASN), geo-location?, RSS RTT (v4/v6/udp/tcp), RTT to first-hop router, RTT to well-known Internet infrastructure, traceroutes to RSS What set of measurements would be useful for testing perspective of the RSS via the local resolver? Let's get an initial list to ground general thoughts on the set. We will revisit this periodically. IP (ASN) of RR, RTT to RR, RSS RTT (v4/v6/udp/tcp), RTT to first-hop router, RTT to well-known Internet infrastructure, traceroute (from where?) Compare RTT for cache miss versus cache hit Compare RTT of configured RR versus well-established resolver (google/cloudflare/etc) Ken Renard S&TCD Contractor – ICF Sustaining Base Network Assurance Branch C5ISR Center, Space and Terrestrial Communications Directorate Office: 443-395-7809 kenneth.d.renard.ctr(a)mail.mil

1 0

Re: [RSSAC Caucus] Updating the RSSAC FAQ
by Geoff Huston May 2, 2020

May 2, 2020

What's not clear to me Fred is whether “many MORE” resolvers today are capable of falling back to TCP. > On 2 May 2020, at 9:20 am, Fred Baker <fredbakersba(a)gmail.com> wrote: > > Question: I understood the statement to be that *resolvers* could fall back to TCP, not that the universe behind solvers could. Which is it? > >> On May 1, 2020, at 1:22 PM, Geoff Huston <gih(a)apnic.net> wrote: >> >> >> >>> On 2 May 2020, at 1:25 am, Dave Lawrence <tale(a)dd.org> wrote: >>> >>> Geoff Huston writes: >>>> "Finally, many more resolvers today are capable of falling back to >>>> TCP when they receive a truncated response over UDP” >>>> >>>> really? Where is the study that publishes this finding? >>>

2 1

Re: [RSSAC Caucus] Checking whether current RSOs are authoritative for TLDs: nope
by Wessels, Duane May 1, 2020

May 1, 2020

> On May 1, 2020, at 12:04 PM, Fred Baker <fredbakersba(a)gmail.com> wrote: > > > >> On May 1, 2020, at 9:18 AM, Wessels, Duane via rssac-caucus <rssac-caucus(a)icann.org> wrote: >> >> Thanks Wes. I unfortunately had a lot of connectivity problems during today's meeting, so I missed some of the discussion towards the end. I think there was a question about the behavior of j.root-servers.netrelated to this topic? > > OK, The error came from me. A company in Saudi Arabia was asking about having an F instance, and told me that they wanted to have J but it didn't work out. The thing they found attractive was that having a J instance meant they also had service for the other Verisign TLDs. What you're telling me is that they must have *also* gotten a different server instance for those TLDs. Ah. Verisign has a thing called Regional Internet Resolution Service (RIRS). This is a single server that can be sent to qualifying IPSs etc that we then manage. The RIRS server has multiple VMs, one of which is for j.root-servers.net. Other VMs will serve other zones on other IP addresses. https://www.verisign.com/en_US/domain-names/internet-resolution/index.xhtml… DW

1 0

Checking whether current RSOs are authoritative for TLDs: nope
by Wes Hardaker May 1, 2020

May 1, 2020

There was discussion today on the newly forming work party about rogue behavior (a work party name change may occur, but I'm using the current one) about whether existing RSOs were serving data other than the root, arpa and root-servers.net from their existing root server infrastructure. One of the questions was whether TLDs were being served authoritatively from some instances. I threw together a few quick bash scripts to do minimal checking of this and determined that based on advertised addresses and the root zone data, there are no RSOs currently advertising TLD service within the root zone data. Details here: https://www.isi.edu/~hardaker/news/20200501-rso-addresses.html (feel free to embrace and extend) -- Wes Hardaker USC/ISI

2 1

REMINDER: RSSAC Caucus Rogue RSO WP Introductory Call | Friday, 1 May 2020 | 14:00 - 15:00 UTC
by Ozan Sahin May 1, 2020

May 1, 2020

***REMINDER*** Draft Agenda: Please see below at the bottom of the invitation. Work Party Wiki Space: https://community.icann.org/x/IonsBw Ozan Sahin is inviting you to a scheduled Zoom meeting. Topic: RSSAC Caucus Rogue RSO WP Introductory Call Time: May 1, 2020 02:00 PM Universal Time UTC Join Zoom Meeting https://icann.zoom.us/j/94479984201?pwd=b0ZkWkNuNTBqcm9aWkxVVWdQRFA1Zz09 Meeting ID: 944 7998 4201 Password: 230111 **Please note this added security/privacy feature. Participants will only be required to enter the password if they are joining via the application and typing in the meeting ID manually. Anyone who joins a meeting via a link in a calendar ore-mail invitation will not be required to enter the password upon joining** One tap mobile +16699006833,,94479984201#,,1#,230111# US (San Jose) +13462487799,,94479984201#,,1#,230111# US (Houston) Dial by your location +1 669 900 6833 US (San Jose) +1 346 248 7799 US (Houston) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 929 436 2866 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 944 7998 4201 Password: 230111 Find your local number: https://icann.zoom.us/u/abmTwJh2CE Agenda 1. Welcome & Roll Call 2. RSSAC and RSSAC Caucus Work Parties<https://docs.google.com/document/d/1IneqdfKR53TBGeapHfIgv-AsMoKK9Ltiwtv2TIc…> * Confidentiality * Roles i. WP Shepherd(s) ii. WP Leader(s) iii. Contributor iv. Reviewer v. Observer 3. RSSAC Publication Procedures * Reviewing and Updating Drafts i. RSSAC Caucus Work Products<https://docs.google.com/document/d/1tvigSnpZdLdbSivkgG-3Zsepx42Vvcck2SmctNv…> 4. Chair Election 5. Statement of Work<https://www.icann.org/en/system/files/files/rssac-sow-rss-local-perspective…> Review 6. Work Party Meetings/Teleconferences * Doodles vs standing call time? * Cadence * A meeting as part of ICANN68 Virtual Policy Forum schedule? 7. AOB

1 0

REMINDER: RSSAC Caucus Local Perspective Tool WP Introductory Call | Thursday, 30 April 2020 | 21:00 - 22:00 UTC
by Ozan Sahin April 30, 2020

April 30, 2020

***REMINDER*** Draft Agenda: Please see below at the bottom of the invitation. Work Party Wiki Space: https://community.icann.org/x/gInsBw Ozan Sahin is inviting you to a scheduled Zoom meeting. Topic: RSSAC Caucus Local Perspective Tool WP Introductory Call Time: Apr 30, 2020 09:00 PM Universal Time UTC Join Zoom Meeting https://icann.zoom.us/j/91684358571?pwd=S0Uzd2pKdDZCc2kxandLM1pxMG9NUT09 Meeting ID: 916 8435 8571 Password: 426658 **Please note this added security/privacy feature. Participants will only be required to enter the password if they are joining via the application and typing in the meeting ID manually. Anyone who joins a meeting via a link in a calendar ore-mail invitation will not be required to enter the password upon joining** One tap mobile +16699006833,,91684358571#,,1#,426658# US (San Jose) +13462487799,,91684358571#,,1#,426658# US (Houston) Dial by your location +1 669 900 6833 US (San Jose) +1 346 248 7799 US (Houston) +1 253 215 8782 US (Tacoma) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) +1 929 436 2866 US (New York) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 916 8435 8571 Password: 426658 Find your local number: https://icann.zoom.us/u/aXT36HF2m Draft Agenda 1. Welcome & Roll Call 2. RSSAC and RSSAC Caucus Work Parties<https://docs.google.com/document/d/1IneqdfKR53TBGeapHfIgv-AsMoKK9Ltiwtv2TIc…> * Confidentiality * Roles i. WP Shepherd(s) ii. WP Leader(s) iii. Contributor iv. Reviewer v. Observer 3. RSSAC Publication Procedures * Reviewing and Updating Drafts i. RSSAC Caucus Work Products<https://docs.google.com/document/d/1tvigSnpZdLdbSivkgG-3Zsepx42Vvcck2SmctNv…> 4. Chair Election 5. Statement of Work<https://docs.google.com/document/d/1DVtC3DA-oxAvERGYsSdOAcBdmCsDEOwuNU1v5TA…> Review 6. Work Party Meetings/Teleconferences * Doodles vs standing call time? * A meeting as part of ICANN68 Virtual Policy Forum schedule? 7. AOB * Topic for discussion as time permits i. Overall goals ii. Target audience (users) of this tool iii. What factors influence measurements iv. Existing platforms for measurement v. Data collection and analysis

1 0