.\" -*- mode: troff; coding: utf-8 -*-
.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
.ie n \{\
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "Net::DNS::SEC::Tools::Donuts::Rule 3"
.TH Net::DNS::SEC::Tools::Donuts::Rule 3 2023-07-29 "perl v5.38.0" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH NAME
.Vb 1
\&  Net::DNS::SEC::Tools::Donuts::Rule \- Define donuts DNS record\-checking rules
.Ve
.SH DESCRIPTION
.IX Header "DESCRIPTION"
This class wraps around a rule definition which is used by the \fBdonuts\fR
DNS zone file checker.  It stores the data that implements a given rule.
.PP
Rules are defined in \fBdonuts\fR rule configuration files using the
following syntax.  See the \fBdonuts\fR manual page for details on where to
place those files and how to load them.
.SH "RULE FILE FORMAT"
.IX Header "RULE FILE FORMAT"
Each rule file can contain multiple rules.  Each rule is composed of a
number of parts.  Minimally, it must contain a \fBname\fR and a \fBtest\fR
portion.  Everything else is optional and/or has defaults associated
with it.  The rule file format follows this example:
.PP
.Vb 7
\&  name: rulename
\&  class: Warning
\&  <test>
\&    my ($record) = @_;
\&    return "problem found"
\&      if ($record{xxx} != yyy);
\&  </test>
.Ve
.PP
Further details about each section can be found below.  Besides the
tokens below, other rule-specific data can be stored in tokens
and each rule is a hash of the above tokens as keys and their
associated data.  However, there are a few exceptions where special
tokens imply special meanings.  These special tokens include \fItest\fR
and \fIinit\fR.  See below for details.
.PP
Each rule definition within a file should be separated using a blank line.
.PP
Lines beginning with the '#' character will be discarded as a comment.
.IP \fIname\fR 4
.IX Item "name"
The name of the rule.  This is mandatory, as the user may need to
refer to names in the future for use with the \fI\-i\fR flag,
specifying behavior in configuration files, and for other uses.
.Sp
By convention, all names should be specified using capital letters and
\&'_' characters between the words.  The leftmost word should give an
indication of a global test category, such as "DNSSEC".  The
better-named the rules, the more power the user will have for
selecting certain types of rules via \fBdonuts \-i\fR and other flags.
.Sp
Example:
.Sp
.Vb 1
\&  name: DNSSEC_TEST_SOME_SECURE_FEATURE
.Ve
.IP \fIlevel\fR 4
.IX Item "level"
The rule's execution level, as recognized by \fBdonuts\fR.  \fBdonuts\fR will
run only those rules at or above \fBdonuts\fR' current execution level.
The execution level is specified by the \fI\-l\fR option to
\&\fBdonuts\fR; if not given, then the default execution level is 5.
.Sp
The default \fIlevel\fR of every rule is 5.
.Sp
Generally, more serious problems should receive lower numbers and
less serious problems should be placed at a higher number.  The
maximum value is 9, which is reserved for debugging rules only.
8 is the maximum rule level that user-defined rules should use.
.Sp
Example:
.Sp
.Vb 2
\&  name: DNSSEC_TEST_SOME_SECURE_FEATURE
\&  level: 2
.Ve
.IP \fIclass\fR 4
.IX Item "class"
The \fIclass\fR code indicates the type of problem associated with the
rule.  It defaults to "\fIError\fR", and the only other value that should
be used is "\fIWarning\fR".
.Sp
This value is displayed to the user.  Technically, any value could be
specified, but using anything other than the \fIError\fR/\fIWarning\fR
convention could break portability in future versions.
.Sp
Example:
  name: DNSSEC_TEST_SOME_SECURE_FEATURE
  class: Warning
.IP \fIruletype\fR 4
.IX Item "ruletype"
Rules fall into one of two types (currently): \fIrecord\fR or \fIname\fR.
\&\fIrecord\fR rules have their test section evaluated for each record in a
zone file.  \fIname\fR rules, on the other hand, get called once per
record name stored in the database.  See the \fItest\fR description below
for further details on the arguments passed to each rule type.
.Sp
The default value for this clause is \fIrecord\fR.
.Sp
Example:
.Sp
.Vb 2
\&  name: DNSSEC_TEST_SOME_SECURE_FEATURE
\&  ruletype: record
.Ve
.IP \fItype\fR 4
.IX Item "type"
Rules that test a particular type of record should specify the
\&\fItype\fR field with the type of record it will test.  The rule
will only be executed for records of that type.
.Sp
For example, if a rule is testing a particular aspect of an MX record,
it should specify "MX" in this field.
.Sp
Example:
.Sp
.Vb 2
\&  name: DNSSEC_TEST_SOME_SECURE_FEATURE
\&  type: MX
.Ve
.IP \fIinit\fR 4
.IX Item "init"
A block of code to be executed immediately as the rule is being parsed
from the rule definition file. This is useful for boot-strap code to
be performed only at start-up.  For example, perl "\fIuse
MODULE::NAME;\fR" or similar statements should be used in \fIinit\fR sections.
.Sp
\&\fIinit\fR sections are wrapped in an XML-like syntax which
specifies the start and end of the \fIinit\fR section of code.
.Sp
Example:
.Sp
.Vb 4
\&  <init>
\&    use My::Module;
\&    $value = calculate();
\&  </init>
.Ve
.IP \fItest\fR 4
.IX Item "test"
A block of code defining the test to be executed for each record or
record name.  The test statement follows the same multi-line code
specification described in the \fIinit\fR clause above.  Specifically,
all the lines between the <test> and </test> braces are considered
part of the test code.
.Sp
The test contents must be a block of perl code.  If it is not in the
form of an anonymous subroutine (surrounded by "sub {" and "}"
markers), then the code will be automatically put inside a basic
subroutine block to turn it into an anonymous subroutine.
.Sp
EG, the resulting code for a \fIrecord\fR test will look like this:
.Sp
.Vb 7
\&  package main;
\&  no strict;
\&  sub
\&  {
\&    my ($record, $rule) = @_;  
\&    TESTCODE
\&  }
.Ve
.Sp
And for \fIname\fR test will be:
.Sp
.Vb 7
\&  package main;
\&  no strict;
\&  sub
\&  {
\&    my ($records, $rule, $recordname) = @_;  
\&    TESTCODE
\&  }
.Ve
.Sp
(Again, this structure is only created if the \fItest\fR definition
\&\fBdoes not\fRb begin with "sub {" already)
.Sp
When the testcode is run and the test fails, it should return an error
string which will be displayed for the user.  The text will be
line-wrapped before display (and thus should be unformatted text.)  If
the test is checking for multiple problems, a reference to an array of
error strings may be returned.  A test block that has no errors to
report should return either an empty string or a reference to an empty
array.
.Sp
There are two types of tests (currently), and the test code is
called with arguments that depend on the \fIruletype\fR clause of the rule.
These arguments and calling conventions are as follows:
.RS 4
.IP "\fIrecord\fR tests" 4
.IX Item "record tests"
These code snippets are expected to test a single \fBNet::DNS::RR\fR record.
.Sp
It is called with two arguments:
.Sp
.Vb 1
\&  1) $record: The record which is to be tested
\&
\&  2) $recordname: The Net::DNS::SEC::Tools::Donuts::Rule object
\&     reference and rule definition information.
.Ve
.Sp
These are bound to \fR\f(CI$record\fR\fI\fR and \fI\fR\f(CI$rule\fR\fI\fR automatically for the test
code to use.
.IP "\fIname\fR tests" 4
.IX Item "name tests"
These code snippets are expected to test all the records
associated with a given name record.
.Sp
It is called with three arguments:
.Sp
.Vb 7
\&  1) $records: A hash reference to all the record types associated
\&     with that record name (e.g., \*(Aqexample.com\*(Aq might have a hash
\&     reference containing an entry for \*(AqA\*(Aq, \*(AqMX\*(Aq, ...).  Each value of
\&     the hash will contain an array of all the records for that type
\&     (for example, the hash entry for the \*(AqA\*(Aq key may contain an array
\&     with 2 Net::DNS::RR records, one for each A record attached to
\&     the \*(Aqexample.com\*(Aq entry).
\&
\&  2) $rule: The Net::DNS::SEC::Tools::Donuts::Rule object reference
\&     and rule definition information.
\&
\&  3) $recordname: The record name being checked (the name associated
\&     with the data from 1) above which might be "exmaple.com" for
\&     instance, or "www.example.com">).
.Ve
.Sp
These are bound to \fR\f(CI$records\fR\fI\fR, \fI\fR\f(CI$rule\fR\fI\fR and \fI\fR\f(CI$recordname\fR\fI\fR
automatically for the test code to use.
.RE
.RS 4
.Sp
Example rules:
.Sp
.Vb 8
\&  # local rule to mandate that each record must have a
\&  # TTL > 60 seconds
\&  name: DNS_TTL_AT_LEAST_60
\&  level: 8
\&  type: record
\&  <test>
\&    return "TTL for $record\->{name} is too small" if ($record\->ttl < 60);
\&  </test>
\&
\&  # local policy rule to mandate that anything with an A record
\&  # must have an HINFO record too
\&  name: DNS_MX_MUST_HAVE_A
\&  level: 8
\&  type: name
\&  <test>
\&    return "$recordname has an A record but does not have an HINFO record"
\&      if (exists($records\->{\*(AqA\*(Aq}) && !exists($records\->{\*(AqHINFO\*(Aq}));
\&  </test>
.Ve
.RE
.IP "\fIfeature:\fR \fBNAME\fR" 4
.IX Item "feature: NAME"
The feature tag prevents this rule from running unless the \fBNAME\fR
keyword was specified using the \fI\-\-features\fR flag.
.IP "\fIdesc:\fR \fBDESCRIPTION\fR" 4
.IX Item "desc: DESCRIPTION"
A short description of what the rule tests that will be printed to the
user in help output or in the error summary when \fBdonuts\fR outputs the
results.
.IP "\fIrequires:\fR \fBPERLMODULE1\fR \fBPERLMODULE2\fR ..." 4
.IX Item "requires: PERLMODULE1 PERLMODULE2 ..."
This allows rules to depend on installed perl modules.  They'll be
\&\fIrequired\fR and \fIimported\fR as the rule starts executing.  If they
don't exist, an error will be logged using \fBdonuts_error()\fR stating that
the module is required for that rule to work.
.IP "\fIhelp:\fR \fBTOKEN:\fR \fBTOKEN-HELP\fR" 4
.IX Item "help: TOKEN: TOKEN-HELP"
If the rule is configurable via the user's \fB.donuts.conf\fR file, this
describes the configuration tokens for the user when they request
configuration help via the \fI\-H\fR or \fI\-\-help\-config\fR flags.  Tokens may be
used within rules by accessing them using the \f(CW$rule\fR reference passed to
the code (the second argument).
.Sp
Examples:
.Sp
.Vb 1
\&  1) In the rule file (this is an incomplete rule definition):
\&
\&     name:           SOME_TEST
\&     myconfig:       40
\&     help: myconfig: A special number to configure this test
\&     <test>
\&      # ... use $rule\->{\*(Aqmyconfig\*(Aq}
\&     </test>
\&
\&  2) This allows the user to change the value of myconfig via their
\&     .donuts.conf file:
\&
\&     # change SOME_TEST config...
\&     name:     SOME_TEST
\&     myconfig: 40
\&
\&  3) and running donuts \-H will show the help line for myconfig.
.Ve
.IP "\fInoindent: 1\fR" 4
.IX Item "noindent: 1"
.PD 0
.IP "\fInowrap: 1\fR" 4
.IX Item "nowrap: 1"
.PD
Normally \fBdonuts\fR will line-wrap the error summary produced by a rule
to enable automatic pretty-printing of error results.  Sometimes,
however, rules may wish to self-format their outputs.  The \fInowrap\fR
option indicates to \fBdonuts\fR that the output is pre-formatted but
should still be indented to align with the output of the rest of the
error text (currently about 15 spaces.)  The \fInoindent\fR tag, however,
indicates that neither wrapping nor indenting should be performed, but
that the error should be printed as is.
.SH COPYRIGHT
.IX Header "COPYRIGHT"
Copyright 2004\-2013 SPARTA, Inc.  All rights reserved.
See the COPYING file included with the DNSSEC-Tools package for details.
.SH AUTHOR
.IX Header "AUTHOR"
Wes Hardaker <hardaker@users.sourceforge.net>
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fBdonuts\|(8)\fR
.PP
\&\fBNet::DNS\fR, \fBNet::DNS::RR\fR, \fBNet::DNS::SEC::Tools::Donuts\fR
.PP
http://www.dnssec\-tools.org/