[RSSAC Caucus] Work Party [Rogue RSO]: Thoughts on a definition of "Rogue Operator"

Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) kenneth.d.renard.ctr at mail.mil
Tue May 5 20:11:51 UTC 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 at mail.mil

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200505/0dd04e5d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5162 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200505/0dd04e5d/smime.p7s>


More information about the rssac-caucus mailing list