[RSSAC Caucus] Rogue Operator Work Party: Source of zone data

[Fred Baker]

Sending again, this time with the right “from” address...

Speaking strictly for myself, I would argue, as you did in your email, that getting the root zone from another party has a safety issue in it - how do we know it has the right data? I could imagine an RSO downloading the relevant files to somewhere in its own cloud, and then distributing from there to its constellation. Doing so would offload the RZM source. But I would consider getting the first copy from anywhere else as unsafe.

> On Oct 6, 2020, at 10:19 AM, Renard, Kenneth D CTR USARMY CCDC C5ISR (USA) via rssac-caucus <rssac-caucus at icann.org> wrote:
> 
> A discussion topic brought up at the last Rogue Operator Work Party call was on where [technically] an RSO fetches their root zone information from.  Typically, an RSO will fetch zone data directly from the RZM’s servers [distribution of the zone files among the RSO’s instances is not considered here, just the initial fetch(es) from a source].  What if an RSO obtained their copy of the zone data from an intermediate source?  #RootZone
> 
> The RSO is responsible for publishing the correct IANA zone, as made available by the RZM.  Whether they get it directly from the RZM or via some other party should(?) be irrelevant.  An intermediate source certainly does introduce additional risk that the zone could have been modified, but it is still the responsibility of the RSO to publish true IANA data.  I would not consider it _wise_ to obtain the zone from an intermediate source, but would we go so far as to say that this is a _rogue_ operation?  Historically (1998?), fetching from an intermediate was seen as a pre-cursor to rogue operations, where new source may have had intentions of changing the zone, but there seem to be different interpretations of those events.
> 
> The question to the group is: “Would using an intermediate source of root zone data, by itself, be considered a ROGUE operation?”  Regardless of who the intermediate is…, regardless of the authenticity of the zone data…
> 
> Thoughts?
> 
> 
> 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
> 
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at 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.