GitLab

these records will be scrubbed and must be ignored
by the validator

entries in RANGE must be prefixed with ENTRY_BEGIN
anyway, this fixes parser thinking it was a shortened
markup

this allows to make assertions about test environment,
for example number of received queries,
average RTT, number of performed steps etc.

ranges are in variables: `RANGE = [...]`
step is in variable: `STEP`

example:
STEP QUERY
...

; Check whether the query was received
STEP ASSERT 0 < RANGE[0].received < 2
; This fails
STEP ASSERT RANGE[0].received > 100

it also evaluates subexpressions for useful
failure information

the RANGE can now choose to ignore percentage of
received queries, this can be used to simulate
packetloss/server busy

- INTENSIFY=N env variable multiplies the number of
  replayed queries by factor N
- REPLAY bails out when test subject starts dropping
  queries

the output is now machine parseable, supports
following options:

- DO ... for DNSSEC
- PRINT=name ... print replay statistics

the REPLAY can be used during testing to
stress the tested subject and examine its behaviour
under load

* ANSWER alias for CHECK_ANSWER
* MOCK alias for REPLY
* ENTRY_BEGIN ... ENTRY_END not required,
  in that case ENTRY ends with newline, e.g.

; Simplified syntax
STEP QUERY
FLAGS RD
SECTION QUESTION
example.com IN A
; Entry ends here

the client must provide scenario.log object,
that has a `match(self, patterns)` method
the self is a Step instance, patterns is just a list
of parameters passed to `STEP LOG [...]`

this is useful just for setting up the mock server
and keeping it running for live inspection

example:
MATCH all nsid
EDNS 0 1280 nsid=Expected-value

this is a test for a workaround for broken resolution paths,
where a zone cut is first introduced but the final answer is answered
from its parent, which is a bailiwick escape

this test makes no sense if the resolver is built with -DSTRICT_MODE

if the PCAP env variable is present during the test,
all test queries/responses are captured in a pcap
file

the QUERY parameter can now contain key=value map,
where `source=ip` is currently supported.
this allows test to set different source address,
so things like views or source-based filtering
can be tested

it is possible for scenario to play on multiple
test subjects, the [servername] in test case file
should either correspond to test subject symbolic
name or be empty (in that case, the first subject is used)

first parameter to STEP QUERY may be "TCP"
in this case, the test subject is queried over TCP

STEP <id> is optional (incremented if ommited)
e.g.:
STEP 1 REPLY # Id=1
STEP REPLY   # Id=2

CONFIG_END isn't needed
ENTRY_END isn't needed

the pydnstest is a generic library
scenario is not responsible for any socket binding
testserver provides mock servers
deckard picks eligible addresses from scenario,
and tells testserver to listen there

this makes the library standalone useable even
without prebinding