RAINS (RAINS, Another Internet Naming Service) is a name resolution protocol that has been designed with the aim to provide an ideal naming service for the SCION Internet architecture. The RAINS architecture is simple, and resembles the architecture of DNS. A RAINS server is an entity that provides transient and/or permanent storage for assertions about names, and a lookup function that finds assertions for a given query about a name, either by searching local storage or by delegating to another RAINS server. The goal of the SCION RAINS project is to enhance and refine the existing RAINS prototype implementation on top of the newest SCION release, and make it available within the SCIONLab network for developers and end-users to be able to use it. Additionally, the existing RAINS design will be refined with a principled approach to obtain better security and performance properties. At the heart of the redesign is a new authentication architecture for naming systems, where the standard DNSSEC-like authentication infrastructure is replaced with CA-based end-entity PKI. Additionally, the project will make use of the DRKey system to develop mechanisms for secure and highly available RAINS communication.
Task 1. Port RAINS to current SCION version
The first task is to tidy up the RAINS codebase and port a basic working version of RAINS (hereafter, the baseline) to the current SCION release.
- Identify minor unfinished system components and pending issues in the original code-base, and devise a feasible implementation and porting plan.
- Deliver executables for end-to-end name resolution and zone management in SCION networks.
- Additionally, manual test instructions are provided to setup the core RAINS components and verify that they work as expected.
Further information:
- Official release, marking the completion of Task 1.
Task 2. Re-design the data authentication architecture of RAINS based on SCION end-entity PKI system
The baseline RAINS relies on DNSSEC-style authentication that comes with inherent limitations. We seek to replace it with a new authentication architecture based on SCION end-entity PKI for better security and performance.
- Design documents with rationale and expected properties of the new authentication architecture as well as suggested modifications to the baseline RAINS
- Specifications of the modified and new RAINS protocols in formal language
Further information:
- Official release, marking the completion of Task 2.
Task 3. Develop a new prototype for RAINS based on CoreDNS
The legacy RAINS codebase was implemented from scratch and in an ad-hoc way. Since DNS and DNSSEC, the authentication architecture of which is adopted by the baseline RAINS, are very complex protocols with tremendous corner cases to consider, the correct implementation of them is suprisingly demanding and error-prone. The baseline RAINS is far from complete and functional for a real-world naming service. To this end, we decided to rebuild RAINS based on CoreDNS, a mature and extensible framework that allows us to enable the new features of RAINS while readily enjoying the comprehensive DNS functionality.
- Prototype RAINS servers (recursive resolver and authoritative name server) based on CoreDNS
- Improved
rdigtool with E2E data validation option
Further information:
- Documentation of a
docker-compose-based demo setup - Official release, marking the completion of Task 3.
Task 4. Implementation, integration, and testing
We will implement SCION (QUIC) transport for RAINS and deploy test name servers to the SCIONLab network.
- RAINS servers and
rdigwith SCION transport option - Test suite for the new approach based on docker-compose
- Additionally, source code, specifactions, documentation and other results are provided
- Operate test RAINS servers in SCIONLab
Further information:
- Official release, marking the completion of Task 4.
Task 5. Enhanced test deployment
We will enhance the SCION-RAINS test deployment within SCIONLab by adding support and deploying a second name server and by making the deployment permanent as well as fixing bugs, enhancing documentation and up-streaming our code to the parent projects.
- Deployment of redundant root servers
- Server in Magdeburg (Germany) operating at
19-ffaa:1:fe4,127.0.0.1(port 53) - Server in Zürich (Switzerland) operating at
17-ffaa:1:1008,127.0.0.1(port 53)
- Server in Magdeburg (Germany) operating at
- Systemd unit for automatic startup and restart upon failure
- Upstream support for name resolution added to SCION Apps
- Documentation updated to reflect these enhancements
Further information:
- Official release, marking the completion of Task 5.