[dns-wg] DNSMON visualisation delay

Dear DNS Working Group,

At RIPE68 we were asked to "send an email to the mailing-list about
advantages and disadvantages of delayed and non-delayed versions of DNSMON
[visualisation], specifically related to the management of the software and
the ongoing maintenance of the legacy systems that you want to retire".

As many of you know, the old DNSMON service had an artificial delay of a
couple of hours for visualising the incoming data, for everyone except a
specific "DNSMON customers" group. With the changes to the service model as
of 2013 there is no good definition of "DNSMON customers" any more. Also,
the current DNSMON implementation does not apply any artificial delays,
which in practice means all data points show up in the graphs within 10-15
minutes.

As Daniel projected a few days ago, we see some realistic options regarding
this visualisation delay:


=== 1. No changes to what the service offers now; ie. graphs will show
results with minimum delay

Development effort: none

Pro: simplest solution

Con: this is perceived by some to be "helping potential attackers" by making
it easy to observe the effects of an attack on the DNS infrastructure


=== 2. Introduction of an artificial delay to *all* users, regardless of NCC
member/non-member, or login status (known an anonymous users)

Development effort: minimal (est. couple of developer days)

Pro: not helping potential bad guys monitoring the zones/servers in real time

Con: not helping the good guys monitoring the zones/servers in real time either


=== 3. Introduction of an artificial delay to users in general, except for
RIPE NCC members. Authentication is done by RIPE NCC Access (Single
Sign-On), authorization is controlled by the existing LIR portal mechanism.

Development effort: minimal (est. couple of developer days)

Pro: RIPE NCC members have early access to visualisations, others don't

Note: the current number of SSO account belonging to RIPE NCC members is ~24000

Note: we may or may not help the attacker, depending on whether (s)he is a
member of the RIPE NCC or not


=== 4. Introduction of an artificial delay to users in general, except for a
specially designated DNSMON customers (zone operators) group. Authentication
is done by RIPE NCC Access (Single Sign-On), authorization is controlled by
a vetting process managed by the RIPE NCC.

Development effort: moderate (est. more than a couple of developer days)

Con: administration overhead is non-trivial -- we'll have to establish and
keep tracking who is in the privileged group and who isn't; with people
joining/leaving organisations this could be tricky and diverge from reality.

Pro: members of the special group have early access to visualisations,
others don't

Note: people in this special group can come from organisations which may or
may not be RIPE NCC members.

Note: we may or may not help the attacker, depending on whether (s)he is a
member of this group or not


Please give us guidance about your your preferred solution by replying to
this mail to the list.

Regards,
Robert Kisteleki
RIPE NCC