03-31-2018 02:39 PM - edited 03-31-2018 04:03 PM
I am desperately hoping that this has an easy answer that I am missing simply because I haven't figured out the proper search terms.
I recently got access (specifically, to the Web UI) to our Campus' Infoblox setup to manage reverse DNS for an ipv6 /48 delegated to one of the research groups I support.
I want to have reverse DNS lookups on any address in one particular /64 within that subnet to return the same record.
Were I dealing with bind, I'd try something like this:
$ORIGIN [some dotted-hex string].ip6.arpa.
* IN PTR hostname.dept.localhost.edu.
(well, more like: https://lists.isc.org/pipermail/bind-users/2006-December/065294.html)
However, so far as I've read, the documentation only mentions wildcard support for A and MX records, not for PTR or AAAA records, and so far, I haven't found the right things to type in the WebUI's "add a PTR record" interface.
Is the "Bulk Host" interface more appropriate for this, and would I need to work with our Campus' Infoblox administrators to setup a custom name format?
(Or am I doomed to a lifetime of writing out a /64's worth of ipv6 PTRs?)
Thanks from a infoblox-n00b, Jon
Solved! Go to Solution.
04-01-2018 05:03 AM
As you’ve read through, adding wildcard PTR records is not supported in NIOS as of now. Bulk hosts are not supported for IPv6 either. We do have feature enhancement requests for both of these capabilities. In case if these features are critical for your environment, I would suggest you to get in touch with your Infoblox accounts team so that they could work with Infoblox product management team to move forward with this.
Talking about work arounds :
1) There is straight forward method that I can suggest in case of IPv4 PTR records, using CNAMEs. Since you cannot use CNAME records with IPv6 reverse-mapping zones, this work around couldn’t be implemented with IPv6 PTR records.
2) The next one is a bit strange, but looks like its working for me. NSUPDATE utility would let you create wildcard IPv6 PTR records. But the problem is, if there is at least 1 static PTR record in this reverse mapping zone, the dynamic wildcard records created via NSUPDATE doesn’t work.
As an example :
- I’ll call my DNS server to be ‘X’ & has an IP address 10.192.33.220. I’m creating an authoritative IPv6 reverse mapping zone(/64), 3.e.22.214.171.124.126.96.36.199.188.8.131.52.1.1.ip6.arpa. with ‘X’ to be primary.
- In order to allow dynamic updates to the reverse zone, I edit the zone ‘3.e.184.108.40.206.220.127.116.11.18.104.22.168.1.1.ip6.arpa’ -> Updates -> Added my linux machine’s IP address under ‘Allow updates from’.
- Now, using my linux machine’s console :
- update add *.3.e.22.214.171.124.126.96.36.199.188.8.131.52.1.1.ip6.arpa. 28800 IN PTR ns1.jon.com
Now if I try to query for anything inside this IPv6 /64 reverse mapping zone :
rpz > dig @10.192.33.220 1111:1111:1111:11e3::101 +short -x
rpz > dig @10.192.33.220 1111:1111:1111:11e3::65 +short -x
rpz > dig @10.192.33.220 1111:1111:1111:11e3::99 +short -x
Note that adding multiple dynamic wildcard IPv6 PTR record would still work & the results would be in a round robin pattern. You may choose an appropriate TTL at the time of NSUPDATE which would be returned to clients when queried. Ensure that there is no DNS scavenging rule which would remove these dynamic records unexpectedly(You may think about overriding DNS scavenging policies for this specific zone, if there are anything active at higher levels).
An example of the problem that mentioned about :
Now if I add a static record 1111:1111:1111:11e3::67 pointed to ‘host.test.com’, as I mentioned earlier the static record would continue to work, while all the wildcard dynamic PTR records added would fail there after :
rpz > dig @10.192.33.220 1111:1111:1111:11e3::67 +short -x
; <<>> DiG 9.10.2 <<>> +noedns @10.192.33.220 -x 1111:1111:1111:11e3::99
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15017
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;184.108.40.206.0.0.0.0.0.0.0.0.0.0.0.0.3.e.220.127.116.11.18.104.22.168.22.214.171.124.1.1.ip6.arpa. IN PTR
;; AUTHORITY SECTION:
3.e.126.96.36.199.188.8.131.52.184.108.40.206.1.1.ip6.arpa. 900 IN SOA gm.iblab.local. please_set_email.absolutely.nowhere. 10 10800 3600 2419200 900
While I do not know what NIOS version you are running on, I tested this in NIOS 8.2.4 & this looks to be good to me so far. In case if there are no other static records inside your /64 IPv6 reverse mapping zone, I believe this work around should be able to keep things going, at least until the feature gets implemented in NIOS. In case if you decide to go for this work around, I strongly recommend you to try this in a test environment before implementing in production.
Hope this helps! In any case, please feel free to let us know if you have questions.
04-01-2018 05:48 PM
Thanks for confirming my suspicion that NIOS currently does not directly support what I am trying to do with wildcards, PTR records, and IPv6.
Luckily, the IPv6 /64 in question is completely unallocated, so I should be able to avoid the problem with "static PTRs" in the middle of the range you menioned.
If I understand correctly, I'll be sending NSUPDATES from a system on that configured ACE to the "Grid Primary".
I believe that Campus is running NIOS 8.2.1-359366d on their Infoblox appliances, and I appear able to allow NSUPDATEs from a configurable list of sources, so that looks good on our end.
Thanks again, and I'll report back on how this works out --Jon
04-02-2018 07:32 AM
To add to this thread- generally, each of these addresses would have an A record in an authoritative forward mapping zone.
With Infoblox, you will find a Host record construct which greatly simplifies this entire process. With Host records, the corresponding PTR record will automatically be abstracted for you. This means that you only need to add the Host record and any queries for the PTR record, or zone transfers for the ip6.arpa zone, will work as expected where the PTR record is returned.
Host records can be defined a number of different ways so how best to go about handling this depends on where things stand. If this is a new setup, then simply create the Host records and as long as the corresponding IPv6 reverse mapping zone exists (and is assigned to the appropriate name servers, it will work. If this is a migration, you can use the Import Zone feature in the NIOS GUI and in the Import Zone wizard, you will see the option "Create Hosts and Bulk Hosts during import". When this option is enabled, any A records being imported will be converted to Host records upon import. The CSV Import feature and (RESTful) API can also be used to create Host records.
04-02-2018 12:19 PM - edited 04-02-2018 12:24 PM
For a variety of socio-politico-historical reasons, control over the forward DNS zone used by these systems is held by the department in question, not Campus.
So in this case, the forward and reverse DNS entries are managed via separate DNS infrastructures.
I do have what may be somewhat unique use cases in play here, but I don't talk about my users' work until they're ready to share - I'm sure you understand.
04-02-2018 12:24 PM
To followup, your suggestion of using the "nsupdate" command worked out well.
I was able to insert the wildcard PTR record I needed such that
- It was visible via the Infoblox NIOS UI (even if not added via that UI)
- Didn't get rejected by the NIOS UI's "syntax checker/validator"
Of course, trying to edit the LHS of the record doesn't work just as trying to add it de novo doesn't work, but the UI does let me delete the wildcard record if I need to do so (say I find a typo or some other horrible embarrassing mistake).
Thanks again --Jon