Infoblox’s global team of threat hunters uncovers a DNS operation with the ability to bypass traditional security measures and control the Great Firewall of China. Read about “Muddling Meerkat” and the many other threat actors discovered by Infoblox Threat Intel here.

API & Integration, DevOps,NetOps,SecOps


Poor API performance for certain wildcard WAPI searches

Posts: 12
2848     0

I'm writing a DNS provisioning workflow engine to streamline resource record approvals for CRUD operations. As part of the update and delete functionality, I have an autocomplete field that will give them a dropdown of possible existing records they are looking to update/delete as they type. Basically, until they select from the dropdown, they can't go forward (i.e. the record must exist or they can't do anything with it, which is obvious). The problem came up where a user typed in *.apps.cfdata and nothing pre-populated, even though it exists as a record in our <100k recs. After tracking down what went on on the backend, I found that the search (name~='*.apps.cfdata' or something to that effect) took upwards of 45 seconds to complete whereas the standard www.blah came back at near-realtime. Had the user waited 45 seconds, the dropdown would have appeared, but who waits that long? Is there a more-optimal way for me to do these searches that would benefit the asterisk searches without harming the normal run-of-the-mill search performance?

I'm using a Python library, but I know what it's doing under the hood when it comes to base wapi calls and I can modify as needed.



Re: Poor API performance for certain wildcard WAPI searches

Posts: 187
2849     0

I've also noticed these kinds of delays when doing searches, I'm not sure if the underlying database is particularly optimised for doing searches in the way that a traditional SQL database engine works.


I haven't figure out a way to get around this yet, I have had ideas around pulling all the data into some kind of external storage that can be searched, but that means it's not dynamic and you'd need a scheduler to re-sync the data every so often. Not ideal at all. :-(


Paul Roberts
PCN (UK) Ltd

All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE
Showing results for 
Search instead for 
Did you mean: 

Recommended for You