Extended DNS testing is an advanced feature. If you are just starting out with argus, or are not familiar with the inner workings of DNS [RFC 1035], it is recommended that you stick to the standard built-in DNS tests as described in services
It seems that there is no end to the creativity of people mis-configuring DNS servers, or the number of failure modes that exist in DNS servers.
The extended DNS testing facility attempts to stay one step ahead.
You can specify any arbitrary DNS query, and perform any number of tests on the response
In addition to all of the parameters for a typical UDP test, the following can also be specified:
for example:
Service UDP/DNS { zone: example.com class: IN query: A }
There are several different ways to test the response
for example:
Service UDP/DNS { zone: example.com class: IN query: MX test: answer expect: mail.example.com } Service UDP/DNS { zone: example.com class: IN query: SOA test: serial minvalue: 2002010100 maxvalue: 2004123100 } Service UDP/DNS { zone: example.com class: IN query: NS test: nanswers minvalue: 2 }
The syntax is backwards compatible with the DNS tests in previous versions. So you can still say:
Service UDP/Domain/example.com Service UDP/DNSQ Service UDP/DNS
The backwards compatible syntax is also extended slightly, so you can say things like:
Service UDP/DNS/NS/example.com { expect: ns1.example.com } Service UDP/DNS/Serial/example.com { minvalue: 2002112000 }
Using the backwards compatible shorthand syntax will set things to reasonable default values (such as class: IN and test: answer or test: soa)
When testing the answer, the answer section of the response is decoded into a textual format similar to the format of a DNS zone file or to the output of dig, and it may be multi-line if there is more than one answer. For example:
www.example.com. 23h5m IN A 10.0.1.2 or example.com. 1d IN MX 10 mail1.example.com. example.com. 1d IN MX 20 mail2.example.com.