NimbostratusGTM DNS reverse zone for SUBNET of an IP range - can't create the legal zone name
ISP's can provide a subnetted chunk of addresses and they delegate the reverse lookups (for PTR records necessary for things like mail exchangers to work in the world) with an extended zone name described by RFC 2317 like 64/27.23.168.192.IN-ADDR.ARPA. This is a legitimate "trick" ( http://www.zytrax.com/books/dns/ch9/reverse.html ) but I cannot get the GTM to accept a zone name with slash in it. I get errors like:
01150213:3: Zone '128/xxx.xxx.xxx.xxx.in-addr.arpa.' in file 'db.external.128-xxx.xxx.xxx.xxx.in-addr.arpa.' contains errors: dns_rdata_fromtext: db.external.128-xxx.xxx.xxx.xxx.in-addr.arpa.:1: near 'ns5.example.com.128/xxx.xxx.xxx.xxx.in-addr.arpa.': bad name (check-names). zone 128/xxx.xxx.xxx.xxx.in-addr.arpa/IN: loading from master file db.external.128-xxx.xxx.xxx.xxx.in-addr.arpa. failed: bad name (check-names). zone 128/xxx.xxx.xxx.xxx.in-addr.arpa/IN: not loaded due to errors.. .
How can I provide reverse lookups for a fraction of a class C if this is the way ISPs are delegating??
If you look carefully, the error is in the NS record that you attempted to create. I'm guessing you used ZoneRunner to create the zone but didn't terminate the "Name Server" entry with a dot; thus, it wrote it to the zone file in that way (and in BIND zones, without the trailing dot, $ORIGIN is appended). So, you likely entered ns5.example.com and it expanded it to ns5.example.com.128/xxx.xxx.xxx.xxx.in-addr.arpa.
I was able to create a zone with a slash and populate it with PTR entries:
dig @10.11.113.200 129.128/26.2.0.192.in-addr.arpa. ptr [ ... ] ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19206 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 [ ... ] ;; ANSWER SECTION: 129.128/26.2.0.192.in-addr.arpa. 86400 IN PTR host1.B.domain. ;; AUTHORITY SECTION: 128/26.2.0.192.in-addr.arpa. 86400 IN NS ns1.f5net.com.I needed to rename the db file, changing the slash to something else (I chose a dash), but this doesn't affect the zone definition. This was done on 11.4.1. I mention this because the underlying BIND version varies between BIG-IP software versions. 'check-names', which is throwing your error above, is a BIND application, so depending on your BIG-IP software version, your mileage may vary.
