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


Questions about status_member field on DTC objects

Posts: 11
1700     0

In WAPI, I'm wondering if anyone has messed with the search-only field called "status_member" that is associated with dtc:lbdn, dtcSmiley Tongueool, and dtc:server? The docs for the field describe it as, "The name of the status member to search for," which doesn't really say much.


What I was hoping it was is a way to query the health status of a DTC object from the perspective of that member the same way you can use the Member drop-down in the DTC visualization pane in the web GUI. But the testing I've been doing against it makes it seem like that's not the case.


The results I get from a query don't seem to change at all regardless of whether I use status_member or not even though there is a difference when I use the Member drop-down in the GUI. For instance:


GET /wapi/v2.10.5/dtc:lbdn?name=mylbdn&_return_fields=health
GET /wapi/v2.10.5/dtc:lbdn?name=mylbdn&_return_fields=health&
GET /wapi/v2.10.5/dtc:lbdn?name=mylbdn&_return_fields=health&

All of these return the exact same response even though the health in the GUI is different when selecting dtc1 vs dtc2 in the Member drop-down.

Re: Questions about status_member field on DTC objects

[ Edited ]
Posts: 81
1700     0

Hello Rmbolger,


I've tested what you observed in RESTAPI. All 4 searchable fields comment/name/fqdn/status_member for the dtc:lbdn object works(I mean the fields are all  recognized during the call). Except the case of status_member, all other 3 yield the required result as what one would expect. Thinking from DTC use-cases persepctive, i can't find a better fit for the "status_member" field to be something different from what your agenda is. Reading through the pointed documentation, I would also think of it the same as the utility available at visualization panel -> select individual member status in specific. 


I tried the same attribute, "status_member" available for use via Infoblox Perl API module as well. In this case, the call doesn't return any result at all (for GET & SEARCH) when the 'status_member' attribute is used(Wild card doesn't work either). I'll attach a simple perl script for reference. Removing the 'status_member' object from attribute list would return the LBDN asked for.



use strict;
use Infoblox;
use Data::Dumper;
 #Create a session to the Infoblox appliance
 my $host_ip   = "X.X.X.X";
 my $host_name = "infoblox.localdomain";
 my $session = Infoblox::Session->new(
     master   => $host_ip,            #appliance host ip
     username => "<user_id>",         #appliance user login
     password => "<password>"         #appliance password
 unless ($session) {
    die("Construct session failed: ",
        Infoblox::status_code() . ":" . Infoblox::status_detail());
 print "Session created successfully.\n";

 my @retrieved_objs = $session->search(
     object => 'Infoblox::DTC::LBDN',
     name => 'lbdn*',           #replace with your LBDN name
     status_member => '*'       #remove this attribute & the results are pulled

my $found_lbdn = $retrieved_objs[0];

         die("Didn't find the LBDN : ",
           $session->status_code() . ":" . $session->status_detail());
 print "Found the LBDN you're looking for..\n\n\n\n";
 print Dumper $found_lbdn ;


So i think something is not working as per the documentation or may be something could be broken. I would suggest you to open a ticket with Infoblox Technical Support, specifying the call used so that this could be explained further(Be it a documentation issue, bug or an alternate usage method of the object in question).


Best regards,


Showing results for 
Search instead for 
Did you mean: 

Recommended for You