Provided by: libzonemaster-perl_1.0.16-2_all bug


       Zonemaster::Overview - The Zonemaster Test Engine


       The Zonemaster system is a quality control tool for DNS zones, produced in cooperation
       between AFNIC and IIS (the top-level registries for respectively France and Sweden). It is
       a successor both to AFNIC's tool Zonecheck and IIS's tool DNSCheck, and is intended to be
       an improvement over both.

       The system as a whole consists of the test engine and, as distributed by the project, two
       different front ends. One is a command-line interface intended for use by experienced
       technicians, and one is a web interface meant for use by anyone. This document only talks
       about the test engine.


   Brief overview
       Conceptually, the test engine consists of a number of test implementation modules
       surrounded by a support framework. Anyone wanting to use Zonemaster to perform tests
       communicates with the framework from the "outside", and all modules implementing tests see
       the world entirely through the framework. Doing things this way lets us have features like
       the ability to test domains before they are published, to record entire test runs for
       later analysis and to make sure that test restults are (as far as reality allows)
       predictable and repeatable.

   For users of Zonemaster
       If all you want to do is run tests, you need to care about four or five modules.
       Zonemaster is the main access point to the framework, and it is via its methods that you
       set the configuration (if needed), request that tests be started and access the logger.
       The logger is where the test results end up, so that's pretty important. On top of those,
       you may want to use the Zonemaster::Translator to turn the results into human-readable

       There are two ways that you can get the results of a test you've requested: the simple-
       but-inflexible way and the flexible-but-complex way.

       The simple-but-inflexible way is that all the methods in Zonemaster that run tests return
       lists of Zonemaster::Logger::Entry objects. Those lists include all the results that the
       writer of the test module(s) considered important enough to return by default. The
       advantage of this method is that it is extremely easy to use. The following is a
       functional (if not very useful) way to run a full test and print the results from a
       command line prompt:

        perl -MZonemaster -E 'say "$_" for Zonemaster->new->test_zone("")'

       The main drawbacks of this method are that there is no choice about what messages to see,
       and it's entirely asynchronous. The code that started the test does not get a chance to do
       anything at all until the whole test has finished, which may be several minutes later.

       The get around those drawbacks there is the flexible-but-complex way, which consists of
       installing a callback that gets executed every time a message is logged. It's not that
       much more complicated, code-wise. The following example does roughly the same thing as the
       one above:

        perl -MZonemaster -E 'Zonemaster->logger->callback(sub {say "$_[0]"}); Zonemaster->new->test_zone("");'

       If you try running those, you'll notice two main differences. First, the second variant
       prints results as they are generated. Second, it generates a lot more output. On my
       machine right now, the first example gives me 94 lines of output. The second example gives
       me 17684.

       You can do pretty much whatever you want with the message objects in the callback
       (including modifying them, although we don't promise that behavior will stay around). If
       the callback code throws an exception, and that exception is not a subcless of
       Zonemaster::Exception, the callback will be removed. Note also that while the callback is
       running, the test engine itself is not. So think twice before you do potentially time-
       consuming tasks (like sticking the message in a database) in the callback. After waiting
       for responses from remote name servers (which usually stands for more than 90% of the time
       used), the result logging is the single most time-consuming task in a Zonemaster test run.

       From here, you probably want to look at the documentation for Zonemaster,
       Zonemaster::Logger, Zonemaster::Logger::Entry, Zonemaster::Config and

   For developers of Zonemaster Test Modules
       If you want to develop a test module of your own, the Zonemaster::Test::Example module is
       intended to serve as an example. The standard set of modules also fulfil that purpose to
       various degrees, of course. Zonemaster::Test::DNSSEC may be especially interesting, since
       it is an example of including default translation and policy data with the module source

       As an entry point to the "inside" of the Zonemaster framework, you want to read
       Zonemaster::Zone and follow references from there. Of particular interest after the zone
       class should be the Zonemaster::Nameserver and possibly Zonemaster::Recursor classes.

       If you do write your own test module, I would very much appreciate feedback on which parts
       were tricky to figure out, because I'm honestly not sure what I need to explain here. So
       please, if there's somethat that you think really needs to be written about, add an issue
       about at <>.

   For developers of the Zonemaster Test Framework
       Random recommendations and advice. May be replaced with more coherent developer
       documentation in the future.

       ·   Stability, predictability and reliability are more important than performance.

       ·   Don't forget that starting with Perl version 5.18, the order in which you get the keys
           out of a hash will be different every time the script is run. Get used to always
           writing "sort keys %hash".

       ·   If two (or more) test implementation modules implement the same (or very similar)
           thing, it should probably be extracted into the framework.

       ·   The unit tests run against pre-recorded data, unless the environment variable
           "ZONEMASTER_RECORD" is set to a (perl-)true value. In that case, it runs against the
           live DNS world and records all results for future use. Unfortunately this sometime
           means that some tests fail, when we were relying on seeing certain problems in certain
           domains, and those no longer look the same.

       ·   The translation strings returned from a test module are used as keys in the GNU
           gettext system, so if you change anything in them don't forget to also change the
           translation ".po" files in share.

       ·   Adding a new message tag is more work than it first looks, since it needs to be added
           to the test module metadata, the default policy and the translation system in order to
           be fully functional.


           Main repository, holding among other things our test specifications.

   List of all RFCs referred to in the test specifications

       ·   RFC0919 "Broadcasting Internet Datagrams" <>

       ·   RFC0952 "DoD Internet host table specification" <http://www.rfc-

       ·   RFC1033 "Domain Administrators Operations Guide" <http://www.rfc-

       ·   RFC1034 "Domain names - concepts and facilities" <http://www.rfc-

       ·   RFC1035 "Domain names - implementation and specification" <http://www.rfc-

       ·   RFC1112 "Host extensions for IP multicasting" <>

       ·   RFC1122 "Requirements for Internet Hosts - Communication Layers" <http://www.rfc-

       ·   RFC1123 "Requirements for Internet Hosts - Application and Support" <http://www.rfc-

       ·   RFC1912 "Common DNS Operational and Configuration Errors" <http://www.rfc-

       ·   RFC1918 "Address Allocation for Private Internets" <http://www.rfc-

       ·   RFC1930 "Guidelines for creation, selection, and registration of an Autonomous System
           (AS)" <>

       ·   RFC1982 "Serial Number Arithmetic" <>

       ·   RFC1996 "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)"

       ·   RFC2142 "Mailbox Names for Common Services, Roles and Functions" <http://www.rfc-

       ·   RFC2181 "Clarifications to the DNS Specification" <http://www.rfc-

       ·   RFC2182 "Selection and Operation of Secondary DNS Servers" <http://www.rfc-

       ·   RFC2308 "Negative Caching of DNS Queries (DNS NCACHE)" <http://www.rfc-

       ·   RFC2544 "Benchmarking Methodology for Network Interconnect Devices" <http://www.rfc-

       ·   RFC2671 "Extension Mechanisms for DNS (EDNS0)" <http://www.rfc-

       ·   RFC2822 "Internet Message Format" <>

       ·   RFC2870 "Root Name Server Operational Requirements" <http://www.rfc-

       ·   RFC2928 "Initial IPv6 Sub-TLA ID Assignments" <>

       ·   RFC3056 "Connection of IPv6 Domains via IPv4 Clouds" <http://www.rfc-

       ·   RFC3068 "An Anycast Prefix for 6to4 Relay Routers" <http://www.rfc-

       ·   RFC3658 "Delegation Signer (DS) Resource Record (RR)" <http://www.rfc-

       ·   RFC3696 "Application Techniques for Checking and Transformation of Names"

       ·   RFC3701 "6bone (IPv6 Testing Address Allocation) Phaseout" <http://www.rfc-

       ·   RFC3849 "IPv6 Address Prefix Reserved for Documentation" <http://www.rfc-

       ·   RFC3927 "Dynamic Configuration of IPv4 Link-Local Addresses" <http://www.rfc-

       ·   RFC4034 "Resource Records for the DNS Security Extensions" <http://www.rfc-

       ·   RFC4035 "Protocol Modifications for the DNS Security Extensions" <http://www.rfc-

       ·   RFC4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses" <http://www.rfc-

       ·   RFC4193 "Unique Local IPv6 Unicast Addresses" <>

       ·   RFC4291 "IP Version 6 Addressing Architecture" <http://www.rfc-

       ·   RFC4343 "Domain Name System (DNS) Case Insensitivity Clarification" <http://www.rfc-

       ·   RFC4380 "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)"

       ·   RFC4843 "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)"

       ·   RFC5155 "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence"

       ·   RFC5156 "Special-Use IPv6 Addresses" <>

       ·   RFC5180 "IPv6 Benchmarking Methodology for Network Interconnect Devices"

       ·   RFC5321 "Simple Mail Transfer Protocol" <>

       ·   RFC5358 "Preventing Use of Recursive Nameservers in Reflector Attacks"

       ·   RFC5737 "IPv4 Address Blocks Reserved for Documentation" <http://www.rfc-

       ·   RFC5771 "IANA Guidelines for IPv4 Multicast Address Assignments" <http://www.rfc-

       ·   RFC5892 "The Unicode Code Points and Internationalized Domain Names for Applications
           (IDNA)" <>

       ·   RFC5936 "DNS Zone Transfer Protocol (AXFR)" <>

       ·   RFC6052 "IPv6 Addressing of IPv4/IPv6 Translators" <http://www.rfc-

       ·   RFC6333 "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

       ·   RFC6598 "IANA-Reserved IPv4 Prefix for Shared Address Space" <http://www.rfc-

       ·   RFC6666 "A Discard Prefix for IPv6" <>

       ·   RFC6781 "DNSSEC Operational Practices, Version 2" <http://www.rfc-

       ·   RFC6890 "Special-Purpose IP Address Registries" <http://www.rfc-

       ·   RFC6891 "Extension Mechanisms for DNS (EDNS(0))" <http://www.rfc-

       ·   RFC7050 "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"