Oracle RAC - Reverse zone, backup network

category: solutionz · date: 2016-12-31 · updated: 2026-10-02 · author: LALA

Oracle RAC Solution · Config document · referenced from DNS server: Knot

noteThe SOA record names the primary server as dns1.example.net without the final dot. Do not copy that line as it is; the effect is described below the file.

The reverse zone of the backup network 10.30.30.x: the backup addresses of the two nodes.

Item	Value
Path on the host	`/etc/knot/30.30.10.in-addr.arpa`
Host	`dns1` (`10.30.40.13`), Debian 8.5, Knot DNS
Zone	`30.30.10.in-addr.arpa`
Serial as built	`20161006`
Applied with	`/etc/init.d/knot restart`
Checked with	`dig @10.30.40.13 30.30.10.in-addr.arpa axfr`, 4 records

The file

ini

$TTL    86400
30.30.10.in-addr.arpa.       IN      SOA     dns1.example.net hostmaster.example.net. (
                           20161006 ; serial
                           4h       ; slave refresh
                           2h       ; slave retry interval
                           2w       ; slave data expiration
                           1h )     ; maximum caching time when lookups fail
;

11.30.30.10.in-addr.arpa.   IN      PTR     oradb01-bck.example.net.
12.30.30.10.in-addr.arpa.   IN      PTR     oradb02-bck.example.net.

The mistake in the SOA record

The owner names in this file are all written in full and end with a dot, so the file needs no $ORIGIN line. The first name after SOA does not end with a dot. A name without the final dot is relative, and the server appended the zone name to it. The zone transfer shows what was loaded: the SOA primary of this zone is dns1.example.net.30.30.10.in-addr.arpa.

The primary server of the zone is therefore a name that does not exist. Nothing in the installation depended on that field: no secondary server and no dynamic update is in the notes, and the PTR records came out as written. The mailbox name hostmaster.example.net. has its dot and came out right.

What else to read in it

There is no NS record. Of the four reverse zones only the management one has it. The server loaded the zone all the same, as the transfer shows.
The backup server has an address in this network, mng-backupsrv01-bck at 10.30.30.14 in the forward zone, and no record here. The two address records of the Backup Exec virtual node rac-clsopdb-1234567890 (the number stands in for the real database identifier and is made up) point into this network as well; the reverse records of 10.30.30.11 and 10.30.30.12 name the nodes, not the virtual node.

Checked against Knot DNS 3.6.0

As built	Today
No `NS` record at the top of the zone	RFC 2181 lists the NS records of the zone origin, with the SOA, as "the mandatory records in every zone". Knot 1.6 loaded the zone because that check was off unless `semantic-checks` was turned on. Knot 3.6.0 also loads and serves it and logs a warning, `missing NS at the zone apex`; `kzonecheck` reports the same and exits with an error
SOA primary `dns1.example.net` without the final dot	RFC 1035 calls a name that does not end in a dot relative and completes it with the origin. Knot 3.6.0 produces exactly the same result as in 2016. RFC 1912: "Double check, triple check, those trailing dots, especially in in-addr.arpa zone files, where they are needed the most"
No `$ORIGIN` line	Knot takes the zone name from its configuration as the initial origin, in 1.6 and today
`$TTL 86400` and the last SOA field `1h`	The negative-caching time is the smaller of the two, 3600 seconds; the comment in the file describes that field correctly
Eight-digit serial	A valid, merely smaller number. The recommended form has ten digits, and switching to it later is an increase, so it is safe
PTR records written by hand	Knot can generate reverse records from a forward zone since 3.3.0

Both defects of the reverse zones are of the kind a zone checker finds before the server is restarted. kzonecheck appeared in Knot 2.3.0; the 1.6 server had knotc checkzone, which the notes do not use.