At the moment, the configuration system is exceedingly simple: it's just a JSON-serialized hash stored as data in the Zonemaster::Engine::Config module. Eventually, this will be changed to loading a file and providing the ability for local overrides of defaults.
The policy data is already distributed as and loaded from an external JSON file. There isn't yet any ability to override policy data, or specify alternatives.
The configuration data is a nested hash. These are the keys that will be looked for and used.
These are settings for the resolver objects used to send and receive DNS queries.
These are the default values used when creating new resolver objects.
If this flag is true, queries will be sent over TCP. Defaults to false.
The number of seconds to wait for a response before re-sending a query.
If this flag is true, the DO flag will be set in outgoing queries.
DO
If this flag is true, large amounts of debugging data will be printed.
If this flag is true, the RD flag will be set in outgoing queries.
RD
The number seconds to wait for a response to queries sent over UDP. Defaults to 15.
The number seconds to wait for a response to queries sent over TCP. Defaults to 15.
The number of times a query will be sent before the resolver gives up and returns an error. Defaults to 2.
If this flag is false, UDP queries that get responses with the TC flag set will be automatically resent over TCP.
TC
The policy data is also a nested hash. The top-level keys are upper-case-only versions of test module names, and under them is all the policy data for that particular module. The keys in the next level down are, with one exception, logger tags. The exception is the special key DISABLED, which if given a true value will prevent the module from being executed. The values for the tag keys should be the severity level for that tag. For example, under the BASIC top-level key (for the 'Basic' test module), there is a key NO_GLUE. That tag will be emitted by the code in the Zonemaster::Test::Basic module if it fails to get NS records for the zone being tested from its parent zone. Since that is an error that prevents further testing, the message is given the severity level CRITICAL.
DISABLED
BASIC
NO_GLUE
CRITICAL
Zonemaster uses six severity levels. They are as follows, in order from the most severe to the least severe.
This level is intended for problems that are so severe that their effects is to basically render the zone in question impossible to look up. Zones with CRITICAL problems do not, for practical purposes, exist.
This level is intended for problems that can cause problems that directly impact end users. The effect may be an inability to resolve records in the zone, an inability to cryptographically verify its legitimacy (with DNSSEC) or things in that vein.
This level is intended for problems that can cause problems that are less noticeable for end users, or that are only noticeable with less common name resolution software.
This level is intended for problems that are unlikely to be noticed by end users. This may bey things like violations of less-used standards, timing values outside the recommended bounds, and other things along those lines.
This level is for messages that do not indicate problems, but that hold information that may be interesting to the person running the test.
This level is for messages that should not normally hold any interest for the person running the test.
To install Zonemaster::Engine, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Zonemaster::Engine
CPAN shell
perl -MCPAN -e shell install Zonemaster::Engine
For more information on module installation, please visit the detailed CPAN module installation guide.