Thanks for starting the discussion Ken. I've been looking at this at doodling on paper and sort of come to the conclusion that we should not be focusing on the *types* of rogue/fake/bad operators, but rather on the various ways that a DNS client can get anything other than a correct response from an IANA recognized root server. I apologize in advance if this takes us in the wrong direction, but it feels right to me so I figured I'd share it. Thinking about a DNS query from a recursive resolver (client) to a root server, a number of things can happen that prevents it from getting correct response from a real root server: 1) The recursive resolver might be configured for RFC7706-style operation, which is to say that the query is answered locally, without leaving the recursive resolver itself or the local network. I'm not saying this is bad/wrong, but we may want to describe the risks around it. 2) Does the recursive resolver have non-IANA root NS RRset and associated addresses? This is like your "non-sanctioned operator" case, and also like the Yeti DNS project. In this case queries do not (always) reach real RSOs. Probably two sub-cases here where one is opt-in/intentional and the other is not. 3) Route hijacks. Even though a DNS query has a proper RSO destination IP address, it may be routed to another entity. I would include here both BGP hijacks and static routes to serve RSO addresses locally, which is also covered in your non-sanctioned operator case. 4) On-path attacker. Although the query is on its way towards a proper RSO, an on-path device or attacker may interfere. Think "great firewall" style. 5) Incorrect or unexpected data served by an RSO. The query was delivered to a proper RSO, but the response was incorrect somehow, either due to compromise, software bug, misconfiguration, or intentional interference. We've seen an example of a software bug like this just recently. A long time ago (probably 2008?) I remember there was a root server that was serving "localhost," I'm guessing because about that time it came as part of the default BIND configuration. 6) Off-path attacker? Not sure this is in scope, but perhaps. Of all these different possibilities, I think the likelihood that a client gets bad data because of an RSO's intentional actions is quite low. Nonetheless we could describe these various scenarios and the extent that mitigations are needed and effective. DW

On May 5, 2020, at 1:11 PM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus@icann.org> wrote:

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@mail.mil

_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://secure-web.cisco.com/1exAFAzXHjmETsRjUrrDmy0r0Cv7oMt1WXxIx43ciJUX8aU...

_______________________________________________ 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://secure-web.cisco.com/1aef_Y0-7xwmr_Q-eoPH1VxGyE_5wLxRL-oQkhD_InQmLOQ...) and the website Terms of Service (https://secure-web.cisco.com/17fOdMyxlceIQHihFHIvLaUBKkF7_CDaE2Qv8M8VoksDHau...). 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.