- Notification system (for cyber threats / anomalities)
- Git interface for zone editing (needs a git server)
- Social login
- eMail verification
- email verification
# Design
@ -29,7 +29,7 @@ A unikernel using Dream and webauthn. It relies on a git remote repository for p
The available services are HTTP/HTTPS.
The data, apart from the zone files, are user accounts and shared secrets for dynamic updates. This data is kept in text files.
Each user has a name, eMail address, authentication data, and a set of domains.
Each user has a name, email address, authentication data, and a set of domains.
The authentication data should be a list of webauthn tokens and optionally a passphrase.
If privileged access is necessary, we can manually shutdown the service and push to the git repository directly.
@ -38,7 +38,7 @@ If privileged access is necessary, we can manually shutdown the service and push
## Enroll a new account
Basically the code from the webauthn demo. The eMail address must be unique across users.
Basically the code from the webauthn demo. The email address must be unique across users.
## Register a second authentication mechanism
@ -48,7 +48,7 @@ There should be no more than 5 authentication mechanisms.
## Pass privileges to another user for that domain
Requires a logged in user with access to that domain. Specifies an eMail address of another registered user to provide them access.
Requires a logged in user with access to that domain. Specifies an email address of another registered user to provide them access.
## Delete an account
@ -83,3 +83,36 @@ Similar to let's encrypt: user requests a domain, and the system asks the user t
## Register ssh public key for dynamically updating an address record
A ssh login with any user from a remote machine should trigger an update.
## Change email address of an user account
TBD
# Data storage
This is meant to work well with [dns-primary-git](https://github.com/roburio/dns-primary-git) unikernel:
- zone data is kept flat at the root in one file per domain named after the domain
- secret keys are at the root in a file with the "._keys" suffix
The user data is kept in the "users/" subdirectory, one file per user named after the email address (currently allowed characters
# Synchronisation, source of truth
The git repository is the single source of truth. Keeping data synchronized is crucial for the operation. Both dns-primary-git and dns-web are using the same git repository for storage of data:
- the "users" subdirectory is only read and written by dns-web
- zone data is read and written by both dns-primary-git and dns-web
- key data is read by dns-primary-git and read and written by dns-web
- if a manual git push is done, both unikernels need to be notified to pull the current HEAD: dns-web via post-commit hook, dns-primary-git via DNS notify
Notification from dns-web to dns-primary-git: this is trivially achieved by sending a DNS notify with a respective key. Likely needs to be done even when only "users" was updated (at the moment, should be improved to handle merges appropriately). The key can be read from the main _keys file. Any zone, even the root one, can be used for this notify.
Notifications from dns-primary-git to dns-web: this cannot be achieved directly since dns-primary-git does not know of the existance of dns-web. So the git repository should have a post-commit webhook installed that requests dns-web to trigger a repo update (but not send a notify to dns-primary-git).
Now, the scenario that a user changes a zone and between the GET and the POST there was some (automated change): the POST should be rejected at first (and later an appropriate merge could be done).
What about the git repo was updated and the dns-primary-git receives a nsupdate? Certainly there's a merge conflict as well, which should be handled (same strategy as above).
TODO:
- For consistency and observation, the commit ID of the last pull (or push) should be exposed via a network request (dns-web: HTTP request, dns-primary-git: some DNS packet)
- For usability, should DNS update packets sent to dns-web be forwarded to dns-primary-git? Otherwise the endpoints for the web service and the DNS update are different (and may be confused).
- Should users be stored in a separate branch or a separate repository?