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

55
zonemaster/docs/internal/requirements/CLI-Combined-Requirements.md Normal file
View File

@@ -0,0 +1,55 @@
*This is the merged requirements from the respective CLI's of
ZoneCheck and DNSCheck.*
**Usability:**
- [1.1] The output from the CLI MUST provide timestamps for each log line,
with an option to remove or add the timestamps in the output.
- [1.2] The output from the CLI MUST be able to provide information about
what test level and test case generated a certain log entry with an
option to remove or add the information in the output.
- [1.3] The CLI MUST be able to report the version used to run the test.
Optional to report any version of each individual test case.
- [1.4] The CLI MUST be able to stop testing and return at a command line
configurable error level (not only CRITICAL)
- [1.5] The CLI MUST be able to run a test over IPv4 or IPv6-only with a
provided flag (read: disable protocol at runtime).
**Input:**
- [2.1] The CLI MUST be able to output a help text, either explicitly or
if user input does not validate.
- [2.2] The CLI SHOULD have a filter parameter to be able to hide log
messages below a certain error level.
- [2.3] The CLI MUST be able to run with a user-provided configuration
(what to test). A default SHOULD be used if none is provided.
- [2.4] The CLI MUST be able to run with a user-provided policy
(error levels). A default SHOULD be used if none is provided.
- [2.5] The CLI MUST be able to run with a user-provided locale (language).
A default SHOULD be used if none is provided.
- [2.6] The user MUST be able to specify name servers and corresponding
IP-addresses as input for undelegated test purposes.
- [2.8] The user MUST be able to specify DS-data as input to be able to
test DNSSEC fully even for undelegated domains.
- [2.9] The user MUST specify no more than one domain to test.
- [2.10] The CLI MUST be able to simply report its version and exit with
a provided flag.
- [2.11] The CLI MUST be able to test all available test cases within one
group, it MAY also work per unique test case (--test=zone or --test=zone03).
**Output:**
- [3.1] The CLI MUST be able to provide an output log that is machine
parseable and this MAY be disabled or enabled with a provided parameter.
- [3.2] The CLI MUST be able to provide output that is human readable and
this SHOULD be the default mode although the default MAY be configurable.
- [3.3] The output from the CLI MUST have several levels of verbosity for
DNS debugging purposes, for example additional messages and module
version reports at a low level up to raw DNS packets and dependency
modules' versions at higher levels.
- [3.4] The CLI MUST have a flag to list all available tests and a brief
text on what these tests do. The CLI MAY also have more detailed
information about each test reachable elsewhere from the CLI.
**Optional (or for future uses):**
- [4.1] Boost policy error level WARNING to ERROR with provided flag.
- [4.2] Possible to activate tool debugging code.
- [4.3] Possibility for the CLI to limit output (filter) by type of errors
or ignore specific hosts.

23
zonemaster/docs/internal/requirements/DNSCheck-Batch-Requirements.txt Normal file
View File

@@ -0,0 +1,23 @@
Requirements for batch functionality (taken from DNSCheck 1.*'s) for the Zonemaster project. This is the functional requirements from the current DNSCheck.
Today we have several users of batch functionality, for example:
1. The Web interface uses the batch functionality to queue tests and to display history of test results.
2. The automatic support emails going out to IIS's Registrars to test and track domains as they change.
3. To generate DNS delegation quality statistics.
A batch function could be called a user of the Zonemaster test framework with the ultimate goal of easily accessing stored test results in an efficient way for statistics or reporting purposes.
One type of batch user: https://github.com/dotse/dnscheck/tree/master/webui
Another type of batch user: https://github.com/dotse/dnscheck/blob/master/engine/apps/dnscheck-dispatcher
Functions:
[1.1] A batch function MUST support grouping of test results, thus traceable and unique flagged runs for as few as one but as many as millions of zones (Current DNSCheck terminology: SOURCE).
[1.2] The batch function MUST make sure that every single test result has a unique identifier, and the result must be retrievable using the unique identifier, timestamp or test domain (Current DNSCheck terminology: UNIQUE_ID).
[1.3] A batch function MUST be able to keep complete history per test run that is linked to what source generated the test as per [1.1] (Current DNSCheck terminology: HISTORY).
[1.4] A batch function MUST be able to prioritize test runs based on an extendable (0..n) priority number (not "high/low" or similar) (Current DNSCheck terminology: QUEUE).
[1.5] The batch function MUST be able to store complete test results of up to several million tests and make these efficiently retrievable (within seconds) based on the domain as keyword for listing previous test runs.
[1.6] The batch function MUST log when a test was started, when it ended, the complete test result, what source generated the result and at what priority (TRACEABILITY).
[1.7] The batch function MUST support a queue system, running tests based on the level of priority as per [1.4].
[1.9] The batch function MUST support a configurable maximum number of concurrent domain tests it starts and maintains until completed, also based on priority as per [1.4].
[ future IIS special re-delegation test ]
[1.8] The batch function MUST be able to use information (if available) of previously used name servers for any domain being tested (HISTORY #2).

23
zonemaster/docs/internal/requirements/DNSCheck-CLI-Requirements.txt Normal file
View File

@@ -0,0 +1,23 @@
Requirements for CLI functionality (taken from DNSCheck 1.*'s) for the Zonemaster project. This is the functional requirements from the current DNSCheck.
Current code: https://github.com/dotse/dnscheck/blob/master/engine/apps/dnscheck
Usability:
[1.1] The output from the CLI MUST provide timestamps for each log line, with an option to remove or add the timestamps in the output.
[1.2] The output from the CLI MUST be able to provide information about what test level and test case generated a certain log entry with an option to remove or add the information in the output.
[1.3] The CLI MUST be able to report the version used to run the test. Optional to report any version of each individual test case.
Input:
[2.1] The CLI MUST be able to output a help text, either explicitly or if user input does not validate.
[2.2] The CLI SHOULD have a filter parameter to be able to hide log messages below a certain error level.
[2.3] The CLI MUST be able to run with a user-provided configuration. A default SHOULD be used if none is provided.
[2.4] The CLI MUST be able to run with a user-provided policy. A default SHOULD be used if none is provided.
[2.5] The CLI MUST be able to run with a user-provided locale (language). A default SHOULD be used if none is provided.
[2.6] The user MUST be able to specify name servers and corresponding IP-addresses as input for undelegated test purposes.
[2.8] The user MUST be able to specify DS-data as input to be able to test DNSSEC fully even for undelegated domains.
[2.9] The user MUST specify no more than one domain to test.
Output:
[3.1] The CLI MUST be able to provide an output log that is machine parseable and this MAY be disabled or enabled with a provided parameter.
[3.2] The CLI MUST be able to provide output that is human readable and this SHOULD be the default mode although the default MAY be configurable.
[3.3] The output from the CLI MUST have several levels of verbosity for DNS debugging purposes, for example additional messages and module version reports at a low level up to raw DNS packets and dependency modules' versions at higher levels.

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.

39
zonemaster/docs/internal/requirements/DefineTests.md Normal file
View File

@@ -0,0 +1,39 @@
Can we Discard these existing Test Cases
========================================
* serial number of the form YYYYMMDDnn
* Reasons for not discarding : The recommended syntax is YYYYMMDDnn (YYYY=year, MM=month, DD=day, nn=revision number. This would not overflow until the year 4294. (RFC 1912 [page 3])
* Reasons for discarding : Even though some BIND versions allow you to use a decimal in a serial
number, don't. A decimal serial number is converted to an unsigned 32-bit integer internally anyway. The formula for a n.m serial number is n*10^(3+int(0.9+log10(m))) + m which translates to
something rather unexpected. For example it's routinely possible with a decimal serial number (perhaps automatically generated by SCCS) to be incremented such that it is numerically larger, but after the above conversion yield a serial number which is LOWER than before. Decimal serial numbers have been officially deprecated in recent BIND versions. (RFC 1912 [page 3])
* Delegated domain is not an openrelay
* Reasons for discarding : Not required for testing DNS
* Domain of the hostmaster email is not an openrelay
* Reasons for discarding : Not required for testing DNS
* Can deliver email to 'postmaster'
* Reasons for discarding : This test conforms to the requirements in RFC 1123 [Page 52] "A host that supports a receiver-SMTP MUST support the reserved mailbox "Postmaster"". The RFC is setting up the
requirements for Internet hosts. But this test requirements is not really the responsibility of DNS. D
o we need this ?
* Can deliver email to hostmaster
* Reasons for not discarding : It is imperative that this address get to one or more real persons, because it is often used for everything from reporting bad DNS data to reporting security incidents (RFC 1912 [page 3])
* Domain able to receive email (delivery using MX, A, AAAA)
* Reasons for discarding : Not required for testing DNS
* Test if mail delivery possible
* Reasons for discarding : Not required for testing DNS
Defining the Test Cases
=======================
* ICMP answer
* root servers list present
* root servers list identical to ICANN
* root servers addresses identical to ICANN
* coherence between NS and ANY records
* coherence between SOA and ANY records
* coherence between MX and ANY records

53
zonemaster/docs/internal/requirements/Engine-Functional-Test-Requirements.md Normal file
View File

@@ -0,0 +1,53 @@
Engine - Functional Test requirements
======================================
Objective
----------
The purpose of Zonemaster tool is to test the quality of a DNS delegation.
The tool comprises of three different functional blocks:
1. Test engine – which comprises of necessary source code to run test
implementations and report results
2. Web GUI – will enable users to provide input (such as a domain name
with different options) and call the test engine and read results from a web
browser
3. CLI – will enable users to provide input (such as a domain name with
different options) and call the test engine and read results from a text
console
The objective of this document is to run functional tests for the two
functional blocks – Test engine and GUI. As of now CLI is not within the
scope of this document.
Scope
------
The test specification (which is part of the test engine) implemented has already
gone/going through the process of unit testing. Unit testing is done to
confirm that a unitary code (such as a single test case source code)
component provides the correct output for a given input.
Functional tests are intended to verify whether the code (written as part of
the test engine) accurately detects the DNS problem's it is meant to detect
with neither false positive nor false negative.
|Req| Test requirement |Explanation|Status|
|:--|:-------------------------------------------|-----------|------|
|FR01|A DNS query with a label that exceeds the maximum length - 63 characters|[RESTRICTION01](../functional-tests/Restriction-TP/restriction01.md)|Cannot test|
|FR02|A FQDN that exceeds the maximum length - 255 octets|[RESTRICTION02](../functional-tests/Restriction-TP/restriction02.md)|Cannot test|
|FR03|A host name label with other than letters, digits and '-'character|[RESTRICTION03](../functional-tests/Restriction-TP/restriction03.md)|Not Verified|
|FR04|CNAME RRs collision (If a CNAME RR is present at a node, no other data should be present; (3.6.2) - RFC 1034)|[CONFIGURATION01](../functional-tests/Configuration-TP/configuration01.md)|Did not test|
|FR05|Zone cyclic dependency|[CONFIGURATION02](../functional-tests/Configuration-TP/configuration02.md)|Results inconclusive|
|FR06|Lame delegation |[CONFIGURATION03](../functional-tests/Configuration-TP/configuration03.md)|OK|
|FR07|Delegation Inconsistency|[CONFIGURATION04](../functional-tests/Configuration-TP/configuration04.md)|OK|
|FR08|Test whether the tool correctly treats the name error with "NXDOMAIN" in response|[BEHAVIOR01](../functional-tests/Behavior-TP/behavior01.md)|OK|
|FR09|Test whether the tool correctly treats when "no such data exist" with "NODATA" in response|[BEHAVIOR02](../functional-tests/Behavior-TP/behavior02.md)|OK|
|FR10|Appropriate results when certain protocols are disabled (e.g.IPv6)|[BEHAVIOR03](../functional-tests/Behavior-TP/behavior03.md)|OK|
|FR11|Test whether the tool run only appropriate tests when the default test profile is modified|[BEHAVIOR04](../functional-tests/Behavior-TP/behavior04.md)|KO|
|FR12|Capable of running the test when the delegation parameters are specified|[BEHAVIOR05](../functional-tests/Behavior-TP/behavior05.md)|OK|
|FR13|Able to test non delegated domain|[BEHAVIOR05](../functional-tests/Behavior-TP/behavior05.md)|OK|
|FR14|Check whether timestamps are being displayed|[BEHAVIOR06](../functional-tests/Behavior-TP/behavior06.md)|OK|
|FR15|IDN verification|[BEHAVIOR07](../functional-tests/Behavior-TP/behavior07.md)|OK|
|FR16|Displays verbose information when it is launched with appropriate flags|[BEHAVIOR08](../functional-tests/Behavior-TP/behavior08.md)|OK|
|FR17|Triggers appropriate error code when the zone is misconfigured|[BEHAVIOR09](../functional-tests/Behavior-TP/behavior09.md)|OK|

18
zonemaster/docs/internal/requirements/ExistingZCFeatures.md Normal file
View File

@@ -0,0 +1,18 @@
# ZoneCheck Features
* Powerful XML based configuration file (allowing changes in test severity,
order, zone of application, ...)
* Does not depend on policies
* Fine grained test selection (by test, by categories, by zones)
* Full IPv6 support (connectivity and AAAA records)
* Supports several input/output interfaces such as CLI, CGI, GUI, inetd
* Dedicated mode for use inside shell scripts
* Batch mode available (ideal when dealing with several domains)
* Use of stylesheets for easy integration and javascript for enhancement only
* Generates reports either by severity or by hosts
* I18N and L10N support (available: French, English)
* Multi-threaded application in order to cut down checking time
* Extensible: new tests, new interfaces, new reports, ...
* Exception and cache mechanisms to simplify test writing
* Open source

40
zonemaster/docs/internal/requirements/ExistingZCFeaturesGUI.md Normal file
View File

@@ -0,0 +1,40 @@
Existing ZC GUI Features
========================
ZoneCheck GUI Features which could be included in "Zonemaster"
Link to example : http://www.zonecheck.fr/demo/
Language:
---------
1. Multiple language support (French and English) is available based on the
browser language settings of the user
2. Easy to add more languages other than English and French
3. Configuration settings available to select the language of the result of
the test other than that of the default page
Usability:
----------
1. Possible to test only with domain name as input
2. Possible to test undelegated domains
3. Possible to select the output format (html/text) of the test report
4. Possible to test with different test profiles
5. Has a progress bar which allows the client to have an idea that the tests
are being conducted even if there is a delay
6. Possible to select the type of the report generated
7. Possible to stop the tests on the event of a fatal error
8. Possible to have a detailed report which shows the test done, condition
for passing the test and the results of the test with details from the zone
that is being tested
9. Possible to limit testing the zone based on the needs of the user (such
as IPv4 only, TCP only etc..)
10. Provides a brief description of the test when it is performed
Functionality:
---------------
1. Possible to add new output formats easily
2. Possible to include different profile tests easily
3. Possible to add extra test easily

43
zonemaster/docs/internal/requirements/FunctionalRequirements.md Normal file
View File

@@ -0,0 +1,43 @@
Existing Functionalities
=========================
| *Input* | *Explanation* |
|:-------------------------------------------|:--------------------------------------------|
|Able to disable testing certain protocols at run time|no IPv4, IPv6, UDP, TCP etc.|
|Able to modify the test profile |Able to modify the test profile easily without modifying the code. Such as possibility to specify what tests to be run (or) not to run|
|Able to specify delegation parameters | For example to test a hypothetical zone delegation from its parent zone|
|Able to have certain defaults in initial config file to minimize configuration time for new users| |
|Possibility to use non default configuration file for specific runs| |
|Able to test non delegated domain| |
|Multiple input interfaces | Should be able to be used by normal users, DNS professionals and by an API |
| *Output* | *Explanation* |
|:-------------------------------------------|:--------------------------------------------|
|Different output format for the results | For example; HTML, XML etc. |
|Multiple output results | Comprehensible for normal user as well as DNS professionals |
|Possibility to output only a summary of results | |
|Multiple language support |Such as English, French and Swedish |
|Different Levels of verbosity | Not only on/off with decent debugging possibility |
|Sort output by errors or hosts | |
|Output a list of the tests we can run | |
|Error results clarity | Return Codes |
| Others | Explanation |
|:-------------------------------------------|:--------------------------------------------|
|Modular | * Functionality of the tool could be enhanced by adding more modules preforming additional tests
| | * Reuse of functions from one module to another
| | * Each module could have a list of dependencies on other modules. A module should be able to process the results of other modules.|
|Able to Cache the results | Helps in reducing resource consumption, thus improving performance|
|Timestamp on the test being run | As done by dnsCheck now |
|Modules should be able to report tests as they are being run | As done by dnsCheck using the "--raw"-flag|
|Separate running of tests, evaluation of results and preparing reports | |
|Ability to store results in a database | |
|Performance - optimization of network as well as system resources when compared to dnscheck and ZoneCheck | |
|Maintaining Bug report | |
|Web User Interface | |
|DNS Packet Serialization | |
| DNSSEC tests | |
|Statistics on network performance, RTT: min, max, stddev, avg, per protocol and #queries sent per name server||

69
zonemaster/docs/internal/requirements/GUI-Combined-Requirements.txt Normal file
View File

@@ -0,0 +1,69 @@
This is the merged requirements from the respective GUI's of ZoneCheck and
DNSCheck.
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 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].
[2.8] The GUI MUST be able to run on delegated zones with the zone itself
exclusively as input (name servers as input is optional)
[2.9] The GUI MUST be able to run on undelegated zones with the zone and at
least one name server as input. [2.10] The GUI MUST be able to support HTML/TXT
as output and SHOULD be designed with further output formats in mind.
[2.11] The GUI MUST be able to run with different test profiles (meaning: what
tests are being run at all).
[2.12] The GUI MUST be able to show a progress bar with a rough estimate of
total test progress and it SHOULD also tell the user what specific test is
currently running.
[2.13] The GUI MUST be able to stop a test on a fatal error if the user has
given the GUI input to do so.
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.
[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.
[4.4] The GUI MUST be designed so that it is easy to add new tests easily.
[4.5] The GUI MUST be able to take DS record(s) as input to test DNSSEC
properly on undelegated domains.
[4.6] The GUI SHOULD report to the user what IP-address he/she is connecting
from.
[4.7] The GUI MUST report what version of the engine was used to generate the
result(s) displayed.

44
zonemaster/docs/internal/requirements/GUI-Functional-Test-Requirements.md Normal file
View File

@@ -0,0 +1,44 @@
GUI - Functional Test requirements
======================================
Objective
----------
The objective of this document is to run functional tests for the Web GUI.
Scope
------
The scope of the testing will limited to the functional testing (End-to-End testing) of the GUI.
Security and Performance testing are not included.
[![Build Status](https://travis-ci.org/zonemaster/zonemaster-gui.svg?branch=master)](https://app.travis-ci.com/github/zonemaster/zonemaster-gui)
|Req| Test requirement |How Verified|
|:--|:-------------------------------------------|------------|
|FR01|A Home button that sends the user to the default simple view |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR01.e2e-spec.ts)|
|FR02|All menus should be clickable in latest version of different browsers such as Firefox, IE, Chrome, Safari etc. |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR02.e2e-spec.ts)|
|FR03|All appropriate fields should be writable |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR03.e2e-spec.ts)|
|FR04|Valid title for the Web interface|[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR04.e2e-spec.ts)|
|FR05|Supports Swedish language|[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR05.e2e-spec.ts)|
|FR06|Supports French language|[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR06.e2e-spec.ts)|
|FR07|Supports English language |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR07.e2e-spec.ts)|
|FR08|Presence of a default fallback language - English |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR08.e2e-spec.ts)
|FR09|Once a language is chosen, all other links should open in that respective language |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR09.e2e-spec.ts)
|FR10|On launching the URL opens with a default simple view | [Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR10.e2e-spec.ts)|
|FR11|The simple view should look the same in latest version of different browsers such as Firefox, Internet Explorer, Chrome, Safari etc. | [Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR05.e2e-spec.ts) |
|FR12|The simple view should support an advanced view expanding when the checkbox is enabled|[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR12.e2e-spec.ts)|
|FR13|The advanced view should support the possibility of enabling or disabling IPv4 or IPv6 |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR13.e2e-spec.ts)|
|FR14|The advanced view should support the possibility of choosing a profile from multiple profiles|[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR14.e2e-spec.ts)|
|FR15|The advanced view should look the same in latest version of different browsers such as Firefox, Internet Explorer, Chrome, Safari etc. |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR15.e2e-spec.ts)|
|FR16|The advanced view should have a text describing what undelegated means? |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR16.e2e-spec.ts)|
|FR17|Able to specify delegation parameters |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR17.e2e-spec.ts)|
|FR18|The GUI should be able to run tests by just providing the domain name |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR18.e2e-spec.ts)|
|FR19|The GUI should be able to run the test with at least one name server as input |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR19.e2e-spec.ts)|
|FR20|The user must be able to submit one or more DS record(s) for use with DNSSEC |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR20.e2e-spec.ts)|
|FR21|Able to provide a summarized result of the test being run (possibility in different colours for error, warning, success etc.) |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR21.e2e-spec.ts)|
|FR22|Provide the possibility to see more information about encountered errors within the simple view |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR22.e2e-spec.ts)|
|FR23|Provide a list of previous runs for the domain and should be paginated |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR23.e2e-spec.ts)|
|FR24|The list of previous runs should contain links to the previous tests |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR24.e2e-spec.ts)|
|FR25|Should be able to export the result in multiple formats (HTML, CSV, JSON, TEXT) |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR26.e2e-spec.ts)|
|FR26|Should be able to show a progress bar with a rough estimate of the total test progress |[Script](https://github.com/zonemaster/zonemaster-gui/blob/master/e2e/FR26.e2e-spec.ts)|

10
zonemaster/docs/internal/requirements/README.md Normal file
View File

@@ -0,0 +1,10 @@
Requirements (internal)
=======================
## Purpose of this directory
This contents of this directory includes different files which were used by the
AFNIC and IIS team internally for the ZM project. Any of the contents of this
directory will not be useful for any type of users of the Zonemaster software,
other than the Afnic and IIS team.