bloxHub

www.infoblox.com/community
12 posts / 0 new
Log in or register to post comments
topic-opened
Zone Report
#1 Mon, 08/13/2012 - 09:10
Zone Report

Hello,

I'm not running bloxTools - hoping someone here has written something that might help me.

I need to run a report  showing all DNS records defined in each existent zone.  Unfortunately, the only way to do this is manually via the GUI but, since I've got a couple thousand zones, I need to do this via an automated porcess. 

It's also unfortunate that Infoblox does not provide a "built-in" way to do such a basic report.

Here's hoping someone has run into this before and can share a way of doing it. 

BTW, zone xfers from the SOAs won;t work - the SOAs are in a DMZ, no DNS "routing" allowed from\to them. 

 

 

+1
0
-1
Tags
Automation Change Manager,DNS Zone Report
Top
Re: Zone Report
Sun, 02/26/2012 - 22:40
Re: Zone Report

you could configure another grid member that is inside the DMZ to also be a secondary for the zone and get your AXFR's from there.

There is no 'good' way to use the API to get all the records for all the zones, generally you want to do a specific query for a particular record.

A more interesting question is 'Why do you need ALL the records, what is the report for?'

+1
0
-1
Top
Re: Zone Report
(Reply to #2) Mon, 02/27/2012 - 00:30
Re: Zone Report

Geoff, thanks for the reply....

I can't do AXFRs - the routing is just not there....unless of course I do it from other external DNS box.

The reason for the report is so that the "data owner" can review what's defined in DNS. 

As I alluted to in my original post, I consider this type of reporting fundamental / basic. I'm surprised that a tool as nifty as Infoblox lacks this type of reporting. I mean, my prior and far-inferior tool provided a "zone report" that did just I need.  

+1
0
-1
Top
Re: Zone Report
(Reply to #3) Mon, 02/27/2012 - 01:18
Re: Zone Report

This kinda comes down to the semantics of 'What are you searching for?"

If someone wants to review what's defined in DNS then they want to check
a list of records somewhere for values that may or may not be missing.
They can do this either by:

  •  - searching DNS for an RR set
  •  - making an API call.

The data is in a database (NIOS) you just need to query it.

When you export a dataset to step into the realm of 'data
synchronisation'. Now someone isn't validating the real data, but is using
their own databasse (CSV file, spreadsheet, text file, Accees database) and own methods to examine a COPY of the data that you have exported for
this purpose.

This is not always best practice as it isn't the live data (do you have
DDNS records) and encourages legacy re-use of legacy techniques that may
or should be upgraded or replaced.

You can actually export all the DNS records (either via an AXFR, or via
CSV export of each of the known records type) but it isn't as ideal as
developing a process that just queries the NIOS database directly.

Also. ANY grid member can be a secondary for a zone, as long as it has it
has the DB capacity, even the grid master. So if you need to expose a
zone for data validation, you just need a box, somewhere, anywhere that
firewall rules will let you get to. If you can get to a box via the API,
then that box /should/ also be able to support AXFR.

You make valid points, I'm just trying to point out alternatives

+1
0
-1
Top
Re: Zone Report
(Reply to #4) Mon, 02/27/2012 - 02:06
Re: Zone Report

Your comment regarding setting up a grid member as a secondary for the zones is what I'm going to try ....Should've thought about that option...I'm very new in the Infoblox world.   

Thanks for the help.

+1
0
-1
Top
Re: Zone Report
(Reply to #5) Wed, 02/29/2012 - 00:43
Re: Zone Report

Jose,

Wanted to check in with you and see setting up a grid member as a secondary for the zones worked?  If you need some additional help, let me know and I'll check in with Geoff and/or the product managers.

Best,

Eric S.
Community Manager

+1
0
-1
Top
Re: Zone Report
(Reply to #6) Wed, 02/29/2012 - 02:31
Re: Zone Report

Eric,

decided to go a different route with this:  restored a copy of the prod database in a lab grid, then assigned one of the lab grid members as SOA for the zones. I was then able to run a "zone transfer script" against the lab SOA.

I'm still surprised at the lack of built-in reporting functionality available with the product.  I hear the newer versions offer a "reporting member" - I guess I'll have to see what that is about....

Thanks for offer to help.

 

+1
0
-1
Top
Re: Zone Report
(Reply to #7) Fri, 03/09/2012 - 05:12
Re: Zone Report

I have something similar setup in our pre infoblox environment.   I used a slightly custom version of  Dlint  (http://freecode.com/projects/Dlint) to walk our internal DNS tree(s) and zone transfer every delegated zone.

This allows for lots of cool other scripts if you have an enterprise large enough that you don't control every delegated zone.   You simply have to setup a single server that can zone transfer every zone.

You can then generate reports for:

Every A record,

Every CNAME,

Every NS record (delegated name server)

ect....

We use this to look for lame name servers.  Duplicate host names...   A web site for "is this name available"....  ect.

There are ways to get this info in a 100% infoblox environment using the API, but as long as you have some bind and windows boxes out there, its hard to beat  AXFR's, sed, awlk, dig and sendmail.

+1
0
-1
Top
Re: Zone Report
Mon, 08/06/2012 - 12:02
Re: Zone Report

None of these alternatives are possible for what I need out of this deployment today. Do you have any other solutions people?? I need a list of all the names we serve up to the world too and I cant get it without clicking multiple times per each of our many-hundred zones!

11 clicks to create a host record, no bulk creation mechanism fit for a network engineer either. Shame!

+1
0
-1
Top
topic-solution
Re: Zone Report
Wed, 08/08/2012 - 16:55
Re: Zone Report

It's not hard, it's just different to other systems. But, if you want to avoid a lot of mouse clicks, you need to use the API. You can export data for a single zone from the GUI, but for bulk operations you need to use the API.

There are 2 ways to do this:

A) the fast way, and what you would do if you had a BIND server, using
AXFR:

#!/usr/bin/perl

my $DNSserver = "1.1.1.1";
my $GM = "2.2.2.2";

my $sdb = Infoblox::Session->new(
    master   => $GM,
    password => 'admin',
    username => 'infoblox',
);

my @zonelist = $sdb->get(
    object => 'Infoblox::DNS::Zone'
    name => '.*'
);

foreach my @zobj ( @zonelist ) {
    my $name = $zobj->name
    system( "dig @$DNSserver $zone AXFR > $zone.txt" );
}

B) the SLOW way, using native API calls, this also gets you all the
metadata on the records, so it has a significant (100x) time overhead.

#!/usr/bin/perl

my $GM = "2.2.2.2";

my $sdb = Infoblox::Session->new(
    master   => $GM,
    password => 'admin',
    username => 'infoblox',
);

foreach my $otype qw(
        Infoblox::DNS::Host
        Infoblox::DNS::Record::A
        Infoblox::DNS::Record::PTR
    ) {

    $sdb->export_data(
        object_type => $otype,
        type => 'csv',
        separator => 'comma',
        path => "$otype-records.csv",
    );

}

 

+1
+1
-1
Top
Re: Zone Report
Mon, 04/29/2013 - 13:26
Re: Zone Report

Trying to set up Zone Transfer using dig on a linux client.  Configured Grid Master

(6.5.4-186068) per instructions: Data Management -> DNS -> Zones ->

Grid DNS Properties -> Zone Transfers -> Allow IPv4 Address xxx.xxx.xxx.xxx.

dig @grid_master_ip my.zone axfr returns:

; (1 server found)

;; global options: printcmd

; Transfer failed. 

Syslog message shows:

2013-04-29 15:20:58 EDT daemon named[22642] client xxx.xxx.xxx.xxx#36210: view 13: bad zone transfer request: 'nd.edu/IN': non-authoritative zone (NOTAUTH)

This has got to be something simple.  Can anyone tell what I'm missing here?  Any and

all help would be greatly appreciated.

 

 

+1
0
-1
Top
Re: Zone Report
Tue, 04/30/2013 - 05:40
Re: Zone Report

Ran the perl script above and did get results -- not the results I was expecting but results none

the less.  So proved there isn't a communication problem but a configuration issue.  Will

investigate further.

+1
0
-1
Top