Run ARK resolver server

[ddeboer]

If I understand correctly, we want to run an instance/replica of the ARK resolver as an alternative to the https://n2t.net global ARK resolver.

Tasks

• Create Docker image based on README and where needed the Ansible scripts: Build and publish Docker image CDLUC3/arksorg-site#12
• Trigger build when the published NAAN records (= ARK prefix to org) at https://cdluc3.github.io/naan_reg_priv/naan_records.json are changed.
• Configure AWS DNS for failover and geolocation routing to the NDE instance of arks.org.

Questions

• Should our resolver have a separate URL (e.g. https://ark.netwerkdigitaalerfgoed.nl) or is it to be added as a DNS A round robin record for n2t.net? Under discussion.
• n2t.net = https://github.com/CDLUC3/N2T. Shouldn’t we run that? In e-mail https://github.com/CDLUC3/arksorg-site was mentioned. No; n2t.net redirects to resolvers for ARK, DOI etc.
• https://arks.org actually runs https://github.com/arks-org/arks.github.io, not https://github.com/CDLUC3/arksorg-site/blob/main/ansible/README.md as mentioned in e-mail correspondence. That’s the static website. CDLUC3/arksorg-site is what we need.
• What is https://github.com/CDLUC3/naan_reg_public / https://cdluc3.github.io/naan_reg_public/? The latter is deprecated.

[ddeboer]

Added a Docker setup in CDLUC3/arksorg-site#12.

[datadavev]

The resolver can have any URL. Adding the resolver as a round robin DNS entry requires coordination with the maintainers of the domain. There are many additional considerations to ensure there's no disruption to existing services.

n2t operates as a scheme resolver, and forwards ark resolution requests to arks.org. Similarly, it forwards doi: requests to doi.org. Instead of DNS round robin, it may be feasible to perform the equivalent functionality by selecting between multiple registered ark resolvers. This may actually be preferable vs the DNS approach.

arks.org is deployed from CDLUC3/arksorg-site. The arks-org/arks.github.io content is the static page visible at arks.org. The resolver functionality is not part of arks-org/arks.github.io.

CDLUC3/naan_reg_public is to be deprecated. It was being used as the public representation of NAAN record curated at CDLUC3/naan_reg_priv. The public records are now served from the gh-pages branch of CDLUC3/naan_reg_priv, visible at https://cdluc3.github.io/naan_reg_priv/

[coret]

Below a quick pros/cons of both solutions.

Aspect	DNS Round Robin	Dynamic Resolution Logic
Ease of Setup	Simple to configure in DNS	More complex; requires custom code
Availability Awareness	No server health checks	Can perform health checks
Latency Optimization	Random; no geographic or load awareness	Can optimize for proximity or speed
Flexibility	Limited; static configurations	Highly flexible and customizable
Scalability	Scales easily with DNS infrastructure	May require careful design to scale
Failure Handling	Slow due to DNS caching	Fast; immediate failover possible

My main questions for @datadavev would be:

• do I understand correctly that we are not looking to replicate n2t.net just arks.org?
• is the "selecting between multiple registered ark resolvers" (Dynamic Resolution Logic) by n2t already available?

[datadavev]

Correct, arks.org is the ark identifier resolver.

The logic for selecting between multiple ark resolvers is not yet implemented

[ddeboer]

So then perhaps we can start with the simpler DNS solution. Because arks.org already runs on AWS, we do have access to failover and geolocation, both of which should work even if one of the instances is hosted outside of AWS (i.e. the NDE cluster).

[jkunze]

This is new territory for ARK (and generally PID) resolution, so I think we'd be making up our own guidelines for monitoring and assessing the reliability of any given resolver instance. My first strawman thought is to ask if each instance would by convention maintain (at a well-known sub-URL endpoint) a publicly readable log of downtimes, reboots, update events, possibly validation and testing events. This would include the primary and all secondaries, whatever would allow us to monitor and correlate health of all active and candidate resolvers. Every resolver might regularly (every day? hour?) run and record whether it passed a set of validation tests, and third party monitors could send alerts.

I'm just rambling now, but I'd like to see automated assurance mechanisms in place so we can sleep better a night! :)

[jkunze]

@datadavev I like the view of records visible at https://cdluc3.github.io/naan_reg_priv/. @coret I also liked the URL you sent me a while ago with a pie chart showing various breakdowns of NAANs (eg, by TLD) and am wondering if it could be updated regularly. With no urgency, might we want to combine some elements or link between those views?

[datadavev]

Setting up RR DNS involves guarantee of availability of participating services, which in turn involves some coordination between participating institutions. I think it would actually be quicker and better long term to implement the multi-target support for n2t than to set up the necessary institutional performance agreements.