CloudHost/zonemaster.es
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add full Zonemaster stack with Docker and Spanish UI

Browse Source 
- Clone all 5 Zonemaster component repos (LDNS, Engine, CLI, Backend, GUI)
- Dockerfile.backend: 8-stage multi-stage build LDNS→Engine→CLI→Backend
- Dockerfile.gui: Astro static build served via nginx
- docker-compose.yml: backend (internal) + frontend (port 5353)
- nginx.conf: root redirects to /es/, /api/ proxied to backend
- zonemaster-gui/config.ts: defaultLanguage set to 'es' (Spanish)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Malin
2026-04-21 08:19:24 +02:00
commit 8d4eaa1489
1567 changed files with 204155 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
zonemaster/docs/internal/requirements/DNSCheck-GUI-Requirements.txt Normal file
View File

@@ -0,0 +1,35 @@
Requirements for GUI functionality (taken from DNSCheck 1.*'s) for the Zonemaster project. This is the functional requirements from the current DNSCheck.
Link to example: http://dnscheck.iis.se
Link to code: https://github.com/dotse/dnscheck/tree/master/webui
Language:
[1.1] The GUI MUST support multiple languages in a standardized and reasonably easy-to-understand way (especially to make it easy to add more languages in the future).
[1.2] The GUI MUST have a way of identifying preference of connected users' language and this SHOULD be implemented on the client side (for example using language preference settings from connecting browser).
[1.3] The GUI MUST have a easily configurable default language as a fallback from req [1.2].
[1.4] The GUI MUST support IDN 2.0 domains as input.
[1.5] The GUI MUST have an easy-to-understand way to change the language from the first page.
[1.6] When a user has chosen a language the index, faq and results from the database MUST be in the chosen language UNLESS specific messages are missing where in such a case the default language COULD be used for these, or all, messages.
Usability:
[2.1] The GUI MUST have more than one possible view towards the users and the default SHOULD be the most simple one.
[2.2] The GUI MUST have a view containing the "undelegated"-functionality, this view SHOULD be perfectly clear on what this means (for example a small warning that notifies the user when presenting undelegated-results).
[2.3] The simple view SHOULD highlight found errors and warnings for the test being run.
[2.4] The simple view SHOULD give the user the possibility to see more information about encountered errors from within the simple view, if he/she so chooses.
[2.5] The GUI MUST be able to give a simple, summarized verdict on the domain being tested (for example; green/yellow/red).
[2.6] The GUI MUST provide a list with previous runs for the given domain and these SHOULD be kept separate between normal and "undelegated" testruns.
[2.7] The list from [2.6] MUST contain working links to the previous tests and these MAY be the same links as created in [4.2].
Security:
[3.1] The GUI MUST have a chroot-similar design where its config, outside of reach of the web root itself, is read only once at startup.
[3.2] The GUI MUST have all sensitive information in the protected configuration file from [3.1] but MAY have options elsewhere if deemed necessary.
[3.3] The GUI SHOULD have an easy-to-read source code that is well documented and commented.
Functionality:
[4.1] The GUI MUST have the same functionality over IPv6 as is given over IPv4 and SHOULD inform the user from what address they are connecting.
[4.2] The GUI MUST create unique links for every test generated through its interface and these links SHOULD be easy to find for the user.
[4.3] The GUI SHOULD allow links to tests that were generated from other sources than the GUI itself but MAY not allow all available sources to be accessed.