Oracle RAC - Reverse zone, public network
Oracle RAC Solution · Config document · referenced from DNS server: Knot
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 public network 10.30.10.x: the public addresses of the two nodes, the two VIPs and the three SCAN addresses, each pointing back to its name.
| Item | Value |
|---|---|
| Path on the host | /etc/knot/10.30.10.in-addr.arpa |
| Host | dns1 (10.30.40.13), Debian 8.5, Knot DNS |
| Zone | 10.30.10.in-addr.arpa |
| Serial as built | 20161007 |
| Applied with | /etc/init.d/knot restart |
| Checked with | dig @10.30.40.13 10.30.10.in-addr.arpa axfr, 9 records |
The file
$TTL 86400 10.30.10.in-addr.arpa. IN SOA dns1.example.net hostmaster.example.net. ( 20161007 ; serial 4h ; slave refresh 2h ; slave retry interval 2w ; slave data expiration 1h ) ; maximum caching time when lookups fail ; 11.10.30.10.in-addr.arpa. IN PTR oradb01.example.net. 12.10.30.10.in-addr.arpa. IN PTR oradb02.example.net. 21.10.30.10.in-addr.arpa. IN PTR oradb01-vip.example.net. 22.10.30.10.in-addr.arpa. IN PTR oradb02-vip.example.net. 31.10.30.10.in-addr.arpa. IN PTR oradb-scan.example.net. 32.10.30.10.in-addr.arpa. IN PTR oradb-scan.example.net. 33.10.30.10.in-addr.arpa. IN PTR oradb-scan.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.10.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
- The three SCAN addresses all point to the same name
oradb-scan.example.net., the mirror image of the three address records in the forward zone. - There is no
NSrecord. Of the four reverse zones only the management one has it. The server loaded the zone all the same, as the transfer shows. - The serial
20161007has eight digits, the serial of the forward zone ten (2016102609). The serial of this zone is one higher than the serial20161006of the other three reverse zones.
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.