Infoblox Administrator Guide
NIOS 4.1
for Infoblox Core Network Services Appliances
Copyright Statements
© 2007, Infoblox Inc.— All rights reserved.
The contents of this document may not be copied or duplicated in any form, in whole or in part, without the prior
written permission of Infoblox, Inc.
The information in this document is subject to change without notice. Infoblox, Inc. shall not be liable for any
damages resulting from technical errors or omissions which may be present in this document, or from use of this
document.
This document is an unpublished work protected by the United States copyright laws and is proprietary to Infoblox,
Inc. Disclosure, copying, reproduction, merger, translation, modification, enhancement, or use of this document by
anyone other than authorized employees, authorized users, or licensees of Infoblox, Inc. without the prior written
consent of Infoblox, Inc. is prohibited.
For Open Source Copyright information, see Appendix C, Open Source Copyright and License Statements on page
329.
Trademark Statements
Infoblox, the Infoblox logo, DNSone, NIOS, Keystone, IDeal IP, bloxSDB, bloxHA and bloxSYNC are trademarks or
registered trademarks of Infoblox Inc.
All other trademarked names used herein are the properties of their respective owners and are used for identification
purposes only.
Company Information
Infoblox is located at:
4750 Patrick Henry Drive
Santa Clara, CA 95054-1851, USA
Web: www.infoblox.com
support.infoblox.com
Phone: 408.625.4200
Toll Free: 888.463.6259
Outside North America: +1.408.716.4300
Fax: 408.625.4201
Product Information
Hardware Models: Infoblox-500, -550, -1000, -1200, -1050, -1550, and -1552, -2000
Document Number: 400-0120-002, Rev. A
Document Updated: May 9, 2007
Warranty Information
Your purchase includes a 90-day software warranty and a one year limited warranty on the Infoblox appliance, plus
an Infoblox Warranty Support Plan and Technical Support. For more information about Infoblox Warranty information,
refer to Infoblox Web site, or contact Infoblox Technical Support.
Contents
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Document Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Documentation Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Documentation Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
What’s New . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Related Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Customer Care . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Software Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Part 1 Device Administration
Chapter 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Infoblox Device Software Packages and Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Product Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Scenario 1 — Independent Infoblox Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Scenario 2 — Basic Grid with Independent Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Scenario 3 — Multiple Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Scenario 4 — Primary and Secondary Infoblox Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Chapter 2 Infoblox GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Management System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Accessing the Infoblox GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Connecting to an Infoblox Device with JWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Clearing Cache on a Linux Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A Single Infoblox GUI Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
SSL (Secure Sockets Layer) Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Understanding the GUI Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Main Interface Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Customizing a Perspective Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Creating a Login Banner on an Infoblox Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Using Global Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Printing from the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Chapter 3 Managing Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Local and Remote Admin Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Local Admin Groups and Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Creating a Superuser Admin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Creating a Limited-Access Admin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Creating an Admin Account. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Modifying and Removing an Admin Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
3
Authentication Using RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Configuring RADIUS Server Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Configuring a RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Remote Admin Groups and Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Configuring a RADIUS Server for Remote Admin Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Creating a Remote Admin Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Configuring a RADIUS Server for Remote Admin Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Changing Password Length Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Notifying Administrators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Chapter 4 Managing Device Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Managing Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Changing Time and Date Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Changing Time Zone Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Using NTP for Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Authenticating NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Infoblox Device as NTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Infoblox Device as NTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Managing Security Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Enabling Support Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Enabling Remote Console Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Permanently Disabling Remote Console and Support Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Restricting HTTP Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Enabling HTTP Redirection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Modifying GUI Session Timeout Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Disabling the LCD Input Buttons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Modifying Security for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Ethernet Port Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Modifying Ethernet Port Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Using the MGMT Port. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Device Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Grid Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Setting Static Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Enabling DNS Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Managing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Viewing the Installed Licenses on an Infoblox Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Obtaining a 60-Day Temporary License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Obtaining and Adding a License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Removing Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Shutting Down, Rebooting, and Resetting an Infoblox Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Rebooting a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Shutting Down a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Resetting a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Managing the Disk Subsystem on the Infoblox-2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
About RAID 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Evaluating the Status of the Disk Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Replacing a Failed Disk Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Disk Array Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 5 Monitoring the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Viewing Detailed Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Device Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Service Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
DB Capacity Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Disk Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
FAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
HA, LAN, or MGMT Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
LCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Memory Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
RAID Battery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Temperatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Using a Syslog Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Specifying Syslog Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Configuring Syslog for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Setting DNS Logging Categories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Viewing the System Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Searching for Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Downloading the Syslog File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Monitoring Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Using the Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Using the Replication Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Using the Traffic Capture Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Chapter 6 Monitoring with SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Understanding SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
SNMP MIB Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
MIB Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Infoblox MIBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Loading the Infoblox MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
RADIUS MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
ibTrapOne MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
ibPlatformOne MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
ibDHCPOne MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ibDNSOne MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Configuring SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Accepting SNMP Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Setting System Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Adding SNMP Trap Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Configuring SNMP for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Chapter 7 Changing Software and Merging Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Upgrading Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Acquiring Software Upgrade Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Distributing Software Upgrade Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Running the Software Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Downgrading Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Reverting to the Previously Running Software Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
5
Merging Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Backing Up and Restoring a Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Back Up and Restore Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Automatically Backing Up a Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Downloading a Backup File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Restoring a Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Loading a Configuration File on a Different Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Downloading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Downloading PERL Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Downloading a Support Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Part 2 Device Deployment
Chapter 8 Deploying Independent Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Independent Deployment Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Deploying a Single Independent Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Method 1 – Using the LCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Method 2 – Using the CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Method 3 – Using the Infoblox NIOS Startup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Method 4 – Using the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Configuration Example: Deploying an Infoblox Device for External DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Cable the Device to the Network and Turn On Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Specify Initial Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Specify Device Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Define a NAT Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Enable Zone Transfers on the Legacy Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Import Zone Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Designate the New Primary on the Secondary Name Server (at the ISP Site) . . . . . . . . . . . . . . . . . . . . . . . . . 179
Configure NAT and Policies on the Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Deploying an Independent HA Pair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Method 1 – Using the Infoblox NIOS Startup Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Method 2 – Using the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Cable Devices to the Network and Turn On Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Specify Initial Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Specify Device Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Enable Zone Transfers on the Legacy Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Import Zone Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Define Networks, Reverse-Mapping Zones, DHCP Ranges, and Infoblox Hosts. . . . . . . . . . . . . . . . . . . . . . . . 192
Define Multiple Forwarders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Enable Recursion on External DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Modify the Firewall and Router Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Enable DHCP and Switch Service to the Infoblox Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Manage and Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Verifying the Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Single Independent Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Independent HA Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Forcing an HA Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Infoblox Tools for Migrating Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 9 Deploying a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Introduction to Grids . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Grid Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
NAT Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Automatic Software Version Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Grid Bandwidth Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Creating a Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
VRRP Advertisements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Port Numbers for Grid Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Creating an HA Grid Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Creating a Single Grid Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Adding Grid Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Adding a Single Member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Adding an HA Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Configuration Example: Configuring a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Cable All Devices to the Network and Turn On Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Create the Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Define Members on the Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Join Devices to the Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Import DHCP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Import DNS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Using the Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
After Using the Wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Enabling IPv6 On a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Introduction to IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Configuring IPv6 on a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Configuration Example: Configuring IPv6 on a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Managing a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Changing Grid Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Setting the MTU for VPN Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Removing a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Promoting a Master Candidate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Replacing a Failed Grid Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Using the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Part 3 Service Configuration
Chapter 10 Managing DNS Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Configuring DNS Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
DNS Configuration Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Restarting Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Using Infoblox Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Default View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Creating Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Specifying Match Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Adding Zones to a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Adding Records to a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Managing Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Configuration Example: Configuring a View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
7
Understanding DNS for IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
IPv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Configuring DNS for IPv6 Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Delegating Zone Authority to Name Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Specifying a Primary Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Specifying a Secondary Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Configuring Authoritative Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Creating an Authoritative Forward-Mapping Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Creating an Authoritative Reverse-Mapping Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Adding an Authoritative Subzone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Creating a Root Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Importing Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Allowing Zone Transfers for a Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Importing Data into Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
How Specific Zones and Records Are Imported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Configuring Delegated, Forward, and Stub Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Configuring a Delegated Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Configuring a Forward Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Configuring Stub Zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Using Name Server Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Creating a Name Server Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Applying a Name Server Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Managing Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Locking and Unlocking Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Modifying Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Removing Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Enabling and Disabling Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Using the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Specifying Host Name Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Obtaining a List of Invalid Record Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Adding a Host or Bulk Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Adding a Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Adding a Bulk Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Adding Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Adding an A Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Adding an NS(A) Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Adding an AAAA Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Adding a PTR Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Adding an MX Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Adding an SRV Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Adding a TXT Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Adding a CNAME Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Adding a DNAME Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Specifying Time To Live Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Managing Hosts and Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Modifying, Disabling, or Removing a Host or Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Disabling or Enabling a Host or Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Viewing DNS Record Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
8
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 11 Configuring DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Configuring DNS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Changing General DNS Properties for a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Enabling Zone Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Specifying DNS Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Specifying Root Name Servers for a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Specifying Sortlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Using Forwarders with a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Using Forwarders with a Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Specifying Minimal Response Returns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Disabling and Enabling DNS Service for a Grid Member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Configuring Additional IP Addresses for a Grid Member. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Configuring DNS Zone Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Disabling Forwarding for a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Specifying TTL Settings for a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Changing the SOA Name for a Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Setting the Serial Number in the SOA Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Adding an E-mail Address to the SOA Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Allowing Zone Transfers for a Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Allowing Query Access for a Zone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Supporting Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Active Directory and Unauthenticated DDNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Active Directory and GSS-TSIG-Authenticated DDNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Importing the Keytab File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Viewing DNS Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Viewing DNS Cache Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Viewing a DNS Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Viewing DNS Zone Statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Chapter 12 Configuring IP Routing Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Multiple IP Addresses on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
IP Addressing on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Configuring IP Addresses on the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Advertising Loopback IP Addresses to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Configuration Example: Configuring IP Addresses on the Loopback Interface . . . . . . . . . . . . . . . . . . . . . . . . 341
Anycast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Network Communication Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Configure OSPF on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Configure an Anycast Address on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Configuration Example: Configuring Anycast Addressing on the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Chapter 13 Managing DHCP Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Configuring a DHCP Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Adding a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Splitting a Network into Subnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Expanding/Joining a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Adding a Shared Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Modifying a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Removing a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Enabling and Disabling a Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
9
Configuring IP Addresses and Address Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Adding a Fixed Address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Adding a DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Using Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Creating and Managing Network Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Creating Network Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Creating and Managing DHCP Range Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Creating and Managing Fixed Address Templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Viewing Network Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Adding a Network Using Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Network Templates Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Using the Recycle Bin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Chapter 14 Configuring DHCP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Configuring DHCP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
DHCP Configuration Checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Configuring DHCP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Enabling DHCP and Setting Member Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Specifying Ping Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Specifying DHCP Lease Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Specifying BOOTP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Specifying Custom DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Configuring Advanced DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Configuring the DHCP Option Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Adding Vendor Option Spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Configuring DNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Enabling DHCP Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Defining Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Configuring a MAC Address Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Configuring Option Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Example DHCP Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Configuring a Relay Agent Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Managing DHCP Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Configuring DHCP Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
DHCP Failover Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Creating a Failover Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Monitoring the Failover Association. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Failover Association Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Viewing DHCP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Viewing a DHCP Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Viewing DHCP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
10
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 15 Configuring DDNS Updates
from DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Understanding DDNS Updates from DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Configuring DHCP for DDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Specifying a Domain Name for DHCP Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Configuring DDNS on the DHCP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Sending Updates to DNS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Client FQDN Option (Option 81) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Generating Host Names for DNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Updating DNS for Clients with Fixed Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Resending DNS Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Configuring DNS for DDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Enabling the DNS Server to Receive Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Forwarding Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Authenticating Updates with TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Chapter 16 Managing IP Data – IPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Viewing and Modifying IP Address Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Classifying a Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Adding, Modifying, and Removing Host Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Adding, Modifying, and Removing DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Modifying DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Converting DHCP Leases, Fixed Addresses, and Reserved Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Monitoring Overall DHCP Address Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Setting Watermark Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Viewing IPAM Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Viewing IPAM Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Viewing DHCP and DNS Usage and Device Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Searching and Sorting IPAM Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Viewing Historical DHCP Lease Records. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Logging Member and Selective Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Searching DHCP Lease Event Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Viewing Lease Event Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Exporting and Importing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Chapter 17 NAC Foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
About the NAC Foundation Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
DHCP Authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Configuring the NAC Foundation Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Configuring DHCP Ranges for Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Quarantined DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Guest DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Authorized DHCP Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Binding DHCP Ranges to the Quarantined and Authorized Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Uploading Files for Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Configuring the Captive Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
About Client Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Configuring the McAfee Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Enabling Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
11
About Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Managing the Local User Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Configuring the Self Service Portal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Importing Accounts from an Active Directory Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Configuring an Active Directory Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Configuring an LDAP/LDAPS Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Specifying an External RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Configuring the Authentication Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
About Guest Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Configuring Guest Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Chapter 18 File Distribution Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
File Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Enabling and Configuring TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Enable TFTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Specify Hosts for TFTP Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Enabling and Configuring HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Rules for Using HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Enable HTTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Specify Hosts for HTTP Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Managing Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Upload Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Create a Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Modify File Distribution Storage Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
View Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Chapter 19 RADIUS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Understanding RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Infoblox RADIUS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Authentication Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Configuring RADIUS Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Adding User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Importing User Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Managing Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Generating a Self-Signed Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Generating a Certificate Signing Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Uploading Certificates to the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Downloading Certificates from the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Network Access Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Enabling RADIUS Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
RADIUS Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Understanding RADIUS Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
RADIUS Home Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Configuring a RADIUS Authentication Home Server Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Configuring a RADIUS Accounting Home Server Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Managing RADIUS Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Proxying RADIUS Access-Requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Proxying RADIUS Accounting-Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Removing Home Servers and Shared Secret Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
12
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 20 VitalQIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
About VitalQIP on a Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
HA Pair Grid Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Deploying Grid Members as VitalQIP Remote Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Uploading and Enabling VitalQIP Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Launching VitalQIP on the Grid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Configuring Grid Members on the VitalQIP Enterprise Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Using LDRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
DHCP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Monitoring VitalQIP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Troubleshooting Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Part 4 Reference Material
Appendix A Product Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Power Safety Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
AC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Agency Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
FCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Canadian Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
VCCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
RFC Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
DNS RFC Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
DHCP RFC Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Appendix B Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Supported Expressions for Search Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Appendix C Open Source Copyright and License Statements . . . . . . . . . . . . . . . . . . . . 507
GNU General Public License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
GNU Lesser General Public License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Apache Software License version 1.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
perl Artistic License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
ISC BIND Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
ISC DHCP Copyright. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Julian Seward Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Carnegie Mellon University Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Thai Open Source Software Center Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Ian F. Darwin Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Lawrence Berkeley Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
MIT Kerberos Copyright. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
BSD License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
David L. Mills Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
OpenLDAP License. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
OpenSSL License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
VIM License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
13
ZLIB License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Wietse Venema Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
ECLIPSE SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
Appendix D Hardware Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
About the Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Identifying the Front Panel Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Using the LCD Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Using the Serial Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
About Back Panel Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Connecting the Ethernet Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Independent Device Cabling Using the LAN or Serial Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
HA Pair Appliance Cabling Using the LAN and HA Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Cabling for the MGMT Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Rack Mounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Chassis Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Rack Mounting and Safety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
Hardware Platform Specifications and Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
System Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Environmental Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
AC Electrical Power Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
DC Electrical Power Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
14
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Preface
This guide explains how to install, configure, and manage the Infoblox device. This preface describes the content and
organization of this guide, and provides information about how to find additional product information, including
accessing Technical Support:
•
•
•
Document Overview on page 16
— Documentation Organization on page 16
— Documentation Conventions on page 18
— What’s New on page 20
Related Documentation on page 20
Customer Care on page 21
— User Accounts on page 21
— Software Upgrades on page 21
— Technical Support on page 21
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
15
Preface
Document Overview
This guide describes how to install, configure, and manage Infoblox devices using NIOS (Network Identity Operating
System) version 4.1r3. This manual was last updated on May 9, 2007. For updated documentation, visit our Support
site at: http://support.infoblox.com.
Documentation Organization
This guide is comprised of seven parts, as described in the following table.
Section
Content
Part 1 Product Overview
Chapters 1 – 7
Chapter 1, Overview, on page 25
Provides general information about the Infoblox device software,
plus provides definitions of the terms used to explain how
Infoblox devices operate. It provides examples of how the
devices can be used in your network.
Chapter 2, Infoblox GUI, on page 33
Explains how to use the GUI of the Infoblox device by defining
what the GUI components are and how to use them.
Chapter 3, Managing Administrators, on
Explains how to configure and manage administrator groups and
accounts in the local database and on external RADIUS servers.
page 49
Chapter 4, Managing Device Operations,
on page 67
Chapter 5, Monitoring the Device, on page
111
Chapter 6, Monitoring with SNMP, on page
Explains how to configure NTP, secure administrative access, set
routes, enable DNS resolution, activate licenses, and reset the
device. It also provides information about ethernet and service
port usage.
Explains the purpose of the various logs and provides
information on using syslog to monitor the device.
125
Explains how to configure SNMP to monitor the device. It also
describes the SNMP traps that the device can send and the
Infoblox MIBs.
Chapter 7, Changing Software and
Merging Files, on page 151
Explains how to upgrade and downgrade software, and how to
backup, merge, revert, and restore configuration files.
Part 2 Device Administration
Chapters 8 – 9
Chapter 8, Deploying Independent Devices,
Explains how to deploy single independent devices and
independent HA (high availability) pairs.
on page 167
Chapter 9, Deploying a Grid, on page 201
Addresses grid deployment considerations and explains how to
deploy single devices and HA pairs as grid masters and
members.
Part 3 Data Management
Chapters 10 – 18
Chapter 10, Managing DNS Data, on page
Explains how to manage grid data configurations that are
inherited by DNS members and zones, such as zone type and
mapping information. This chapter also describes how to
configure Infoblox views and how to modify, remove and disable
authoritative, delegated, and forward zones. It concludes with
how to add, modify, remove, and disable hosts and records.
245
16
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Document Overview
Section
Content
Chapter 11, Configuring DNS Services, on
Explains how to configure the DNS services provided by the grid,
which includes time-to-live (TTL) settings, zone transfers,
queries, root name servers, dynamic updates, sort lists, and
Transaction Signatures (TSIG) for DNS. This chapter also
describes how to specify broadcast addresses, routers, and DNS
servers. It describes how to specify and update zones on
external servers and for fixed addresses. This chapter concludes
with how to use the view DNS configuration files and statistical
reports.
page 313
Chapter 12, Configuring IP Routing Options,
on page 339
Chapter 13, Managing DHCP Data, on page
349
Chapter 14, Configuring DHCP Services, on
page 369
Explains how to enable and configure anycast addressing as well
as configure multiple IP address on loopback interfaces on the
Infoblox device.
Explains how to configure networks, and features such as
creating split and shared networks. This chapter also describes
how to modify, remove and disable networks. This chapter
concludes with how to add, modify, remove, and disable fixed
addresses and DHCP address ranges.
Explains how to manage grid data configurations that are
inherited by DHCP members and networks, DHCp address
ranges, and fixed addresses. This chapter explains how to
configure the DHCP services provided by each member, which
includes lease times, BOOT servers, and custom options. This
chapter concludes with how to use the view DHCP configuration
files and statistical reports.
Chapter 15, Configuring DDNS Updates
from DHCP, on page 401
Explains how to set up DHCP and DNS services to work together
to support DDNS (dynamic DNS) updates.
Chapter 16, Managing IP Data – IPAM, on
Explains how to monitor IP address usage using the IPAM (IP
address management) software module.
page 419
Chapter 17, NAC Foundation, on page 437
Provides an overview of the NAC Foundation module and its
components, and describes how to set parameters and
configure various security functions.
Chapter 18, File Distribution Services, on
Explains the TFTP service that the Infoblox device provides for
uploading and downloading data to and from an Infoblox device.
page 457
Chapter 19, RADIUS Services, on page 463 Explains how to configure the RADIUS services on an Infoblox
device.
Chapter 20, VitalQIP, on page 483
Explains how to configure Infoblox devices as VitalQIP® DNS
and DHCP remote servers. This chapter describes how to
configure Infoblox devices to upload and manage VitalQIP binary
bundles and policy files in a grid.
Part 4 Reference Material
Appendices A – D
Appendix A, "Product Compliance", on
Provides product information, such as hardware and software
specification and requirements. This appendix also supplies
agency compliance and safety information and concludes with
RFC compliance information for the product.
page 499
Appendix B, "Regular Expressions", on
page 505
NIOS 4.1r3
Lists regular expressions that the Infoblox device supports for
searches.
Infoblox Administrator Guide (Rev. A)
17
Preface
Section
Content
Appendix C, "Open Source Copyright and
License Statements", on page 507
Provides the Open Source copyright and license information for
the product.
Appendix D, "Hardware Information", on
Describes the hardware components and explains how to
rackmount and cable an device. It also lists the hardware
requirements and specifications.
page 531
Documentation Conventions
The text in this guide follows these style conventions.
Style
Usage
bold
Indicates anything that you input by clicking, choosing, selecting, or typing in the GUI, or by
pressing on the keyboard.
input
Signifies command line entries that you type.
variable
Signifies variables typed into the GUI that you need to modify specifically for your
configuration, such as command line variables, file names, and keyboard characters.
Variables
Infoblox uses the following variables to represent values that you type, such as file names and IP addresses:
Variable
Value
admin_group
Name of a group of administrators
admin_name
Name of the device administrator
addr_range
IP address range
domain_name
Domain name
directory
Directory name
filter_name
Filter name
grid_master
Grid Master
grid_member
Grid Member
hostname
Host name of an independent device
grid
Grid name
ip_addr
IPv4 address
member
Grid member name
netmask
Subnet mask
network
IP address of a network
policy
Name of a policy on RADIUSone
18
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Document Overview
Variable
Value
RADIUS_server
Name of a RADIUS server
view
Infoblox view
zone
DNS zone
Navigation
Infoblox technical documentation uses an arrow “->” to represent navigation through the GUI. For example, to access
Grid Properties, the description is as follows:
From the Grid perspective, click grid -> Edit -> Grid Properties.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
19
Preface
What’s New
The following sections are new or have been updated in this version of this guide:
•
Data Printing: You can easily select and print data in a table format from any view (such as all records in a zone).
You can also print to the PDF format. (See Printing from the GUI on page 47.)
•
Enhanced Audit Log: In NIOS 4.1r3, the audit log also shows the value of the properties changed. You can select
the detailed (selected by default) or brief version of the audit log. The detailed audit log provides
comprehensive information on the change to enable compliance with Sarbanes Oxley and change management
systems. (See Using the Audit Log on page 121.)
•
IPv6 Support: The Infoblox NIOS 4.1r3 integrates IPv6 address management into many of the same places
where IPv4 addresses are entered. Data validation occurs on all IP fields and automatic validation is done to
ensure proper entry of either an IPv4 address or an IPv6 address. (See Enabling IPv6 On a Grid Member on page
235 and Understanding DNS for IPv6 on page 259.)
•
Recycle Bin: The Recycle Bin provides the capability to protect against major deletion of data. It is intended to
provide a way to restore data where the deletion of the object (such as a zone) would result in a major data loss.
(See Using the Recycle Bin on page 240, Using the Recycle Bin on page 289, and Using the Recycle Bin on
page 366.)
•
Zone Locking: Administrators can lock a zone before changing its properties or records so that other
administrators cannot make conflicting changes. Administrators can select a zone, lock it, make changes, and
then unlock it. If you lock a zone and other administrators try to make changes to it, then the system displays a
warning message that you have locked the zone. (See Locking and Unlocking Zones on page 286.)
•
Advanced DHCP Options Configuration: You can easily and graphically configure custom vendor options such as
parameters for VoIP phones, wireless access points, or Sun Ray clients. It supports vendor option spaces,
vendor options, filtering based on any predefined DHCP option, and applying conditional OR logic in filters. You
can use this feature to filter the options and determine which vendor options to use. (See Configuring Advanced
DHCP Options on page 380.)
•
NAC Foundation Module: This feature automates the process of populating the DHCP server MAC filters and
enables administrators to specify the network segment to which a DHCP client is assigned based on
user-configurable policies. The NAC Foundation module provides integration with a range of back-end
authentication systems including Microsoft Active Directory, RADIUS, and LDAP servers, as well as local
authentication. The NAC Foundation module includes a built-in captive web portal that supports interactions
with users via their web browsers. This module is designed to support a variety of third-party products and
includes built-in integration with McAfee ePolicy Orchestrator (ePO). (See Chapter 17, NAC Foundation, on page
437.)
Related Documentation
Other Infoblox device documentation:
•
•
•
•
•
•
•
•
•
20
Infoblox CLI Guide
Infoblox-500, Infoblox-1000 and Infoblox-1200 Quick Start
Infoblox User Guide for the Infoblox-1050, 1550, and 1552 Appliances
Infoblox User Guide for the Infoblox-500, 550 Appliance
Infoblox Installation Guide for the Infoblox--550, -1050, 1550, and 1552 Appliances
Infoblox Installation Guide for the Infoblox-250 Appliance
Infoblox Installation Guide for the Infoblox-2000 Appliance
Infoblox Safety Guide
Introduction to the Infoblox DMAPI
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Customer Care
Customer Care
This section addresses user accounts, software upgrades, licenses and warranties, and technical support.
User Accounts
The Infoblox device ships with a default user name and password. Change the default admin account password
immediately after the system is installed to safeguard its use. Make sure the device has at least one administrator
account with superuser privileges at all times, and keep a record of your account information in a safe place. If you
lose the admin account password, and did not already create another superuser account, the system will need to be
reset to factory defaults, causing you to lose all existing data on the device. You can create new administrator
accounts, with or without superuser privileges. For more information, refer to Managing Administrators on page 41.
Software Upgrades
Software upgrades are available according to the Terms of Sale for your system. Infoblox notifies you when an
upgrade is available. Register immediately with Infoblox Technical Support at
http://www.infoblox.com/support/product_registration.cfm to maximize your Technical Support.
Technical Support
Infoblox Technical Support provides assistance via the Web, e-mail, and telephone. The Infoblox Support web site at
http://support.infoblox.com provides access to product documentation and release notes, but requires the user ID
and password you receive when you register your product online at:
http://www.infoblox.com/support/product_registration.cfm.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
21
Preface
22
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Part 1 Device Administration
This section provides basic information about the Infoblox device, including a description of the various modules and
a list of product terminology, a description of the user interface and information about basic configuration tasks. It
includes the following chapters:
•
Chapter 1, "Overview", on page 25
•
Chapter 2, "Infoblox GUI", on page 33
•
Chapter 3, "Managing Administrators", on page 49
•
Chapter 4, "Managing Device Operations", on page 67
•
Chapter 5, "Monitoring the Device", on page 111
•
Chapter 6, "Monitoring with SNMP", on page 125
•
Chapter 7, "Changing Software and Merging Files", on page 151
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
23
24
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 1 Overview
This chapter provides general information about the Infoblox device operating system and software modules. It
defines terms used in this manual and describes various deployment scenarios. The topics in this chapter include:
•
•
•
Infoblox Device Software Packages and Upgrades on page 26
Product Terminology on page 26
Deployment Scenarios on page 28
— Scenario 1 — Independent Infoblox Devices on page 28
— Scenario 2 — Basic Grid with Independent Devices on page 29
— Scenario 3 — Multiple Grids on page 30
— Scenario 4 — Primary and Secondary Infoblox Devices on page 31
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
25
Overview
Infoblox Device Software Packages and Upgrades
All Infoblox devices run the NIOS™ (Network Identity Operating System) operating system. NIOS provides core
services and a framework for integrating all the components of the modular Infoblox solution. NIOS supports local
HA (high availability) both at the device and database levels via bloxHA device failover and bloxSYNC database
synchronization. (For information about HA pairs, see Deploying an Independent HA Pair on page 181 and Adding an
HA Member on page 221.)
Infoblox devices support the following software packages:
•
The DNSone software package is fully-BIND compliant. It provides integrated DNS and DHCP services with
built-in IPAM services. DNSone stores all DNS and DHCP data in the integrated bloxSDB™ semantic database,
which is built into NIOS. It includes a TFTP server for downloading firmware and configuration files to VoIP
phones.
•
The NSQ (Network Services for Alcatel-Lucent VitalQIP® )software package provides support for Lucent’s
VitalQIP IP address management software.
•
The Keystone upgrade provides a real-time, integrated services and data management framework that
integrates a collection of distributed devices into a unified grid.
•
The Network Services for VoIP package provides integrated DNS, DHCP, TFPT, and RADIUS proxy services.
•
The NSA (Network Services for Authentication) software package provides support for the RADIUS (Remote
Authentication Dial-In User Service) protocol and the underlying authentication methods required for 802.1X
authentication, as well as the Infoblox grid module.
•
The Network Services Suite (NSS) provides integrated DNS, DHCP, TFPT, RADIUS, and the grid services.
Product Terminology
Before you begin, review Table 1.1 for a description of some key terminology. Some terms, such as grids and high
availability, are used in different ways by other networking-product vendors. The alphabetically arranged table can
help you understand the terms and concepts as Infoblox uses them and as they are used in this guide.
Table 1.1 Product Terminology
Term
Description
DNSone
The software package that enables the Infoblox device to provide DNS, DHCP
and TFTP services. You can add the Keystone upgrade to Infoblox devices
running DNSone.
Gateway
The default router for the immediate network segment of an interface.
HA address
The IP address of the HA port. The active node of the grid master uses this
address for grid communications, network data and services, and—if the
MGMT port is disabled—GUI access. See Ethernet Port Usage on page 84.
HA pair
Two physical Infoblox devices that are linked to perform as a single virtual
device in an HA (high availability) configuration. In this configuration, one
device is the active node and the other is the passive node.
Host name
The fully qualified domain name(s) of the Infoblox device that you are
configuring.
Grid
A group of Infoblox devices that are connected together to provide a single
point of device administration and service configuration in a secure, highly
available environment.
26
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Product Terminology
Term
Description
Grid Master
The grid member that maintains the semantic database that is distributed
among all members of the grid. You connect to the GUI of the grid master to
configure and monitor the entire grid.
Grid Member
Any single Infoblox device or HA pair of Infoblox devices that belong to a grid.
Each member can use the data and the services of the grid. You can also
modify settings so that a member can use unique data and member-specific
services.
Keystone
The Keystone upgrade provides grid capabilities.
LAN address
The IP address of the LAN port. The active node of the grid master uses this
address for management protocols if the MGMT port is disabled. The passive
node uses its LAN port for grid communications and management protocols
if the MGMT port is disabled. See Ethernet Port Usage on page 84.
Master Candidate
Enables a grid member to assume the role of grid master as a disaster
recovery measure.
MGMT Address
The IP address that both nodes comprising the grid master use for
management protocols. Also, when you enable the MGMT port, the active
node of the grid master uses the MGMT address for GUI access. See Ethernet
Port Usage on page 84.
Network
The primary objects used to manage DHCP data and specify DHCP services.
The term network is generally used to mean LAN or specifically to mean a
network that you define and manage.
Node
A single component of an HA (high availability) pair. An HA pair consists of an
active node and a passive node.
Service
configuration
Specifying the services provided by your Infoblox devices, such as enabling
DNS and DHCP, configuring dynamic updates, creating sort lists, using
custom options and filters at the grid, member, zone, and network level.
Virtual IP
The shared IP address of an HA pair. A VIP address links to the HA port on the
active node.
Virtual Router ID
The virtual router ID (VRID) identifies the VRRP (Virtual Router Redundancy
Protocol) HA pair to which the Infoblox device belongs. Through this ID, two
HA nodes identify each other as belonging to the same HA pair and they
obtain a virtual MAC address to share together with a virtual IP (VIP) address.
The VRID can be any number between 1 and 255, and it must be unique on
the local LAN so that it does not conflict with any other devices using VRRP on
the same subnet.
Zone
A portion of the domain name space for which an Infoblox device or another
name server is authoritative (for example, has the start of authority [SOA]
record). A zone can also be delegated or forwarded. Zones are the primary
objects used to manage DNS data and DNS services.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
27
Overview
Deployment Scenarios
The Infoblox devices can fit into network topologies in a variety of ways, and can provide DNS and DHCP services in
a variety of ways. This section introduces some typical ways that you can deploy your Infoblox devices:
•
•
•
•
Scenario 1 — Independent Infoblox Devices on page 28
Scenario 2 — Basic Grid with Independent Devices on page 29
Scenario 3 — Multiple Grids on page 30
Scenario 4 — Primary and Secondary Infoblox Devices on page 31
Scenario 1 — Independent Infoblox Devices
The simplest type of deployment is one that uses the devices as independent devices, as shown in Figure 1.1.
Figure 1.1 Independent Infoblox Devices
Network
Clients
Independent HA Pair
Providing DNS
Services
Internet
GUI Client
Independent Device
Providing DHCP
Services
In the sample deployment that is shown above, three devices are deployed as independent devices as follows:
•
An independent HA pair of Infoblox devices that provides DNS services
•
An independent standalone Infoblox device that provides DHCP services
A device can provide network services as an HA pair or as an independent device without being part of a grid.
Independent devices can provide DNS and DHCP services at the same time.
Note: When an Infoblox device is used as an independent device, that device assumes the identity of the grid master
in the GUI, even though it is not part of an actual grid.
28
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deployment Scenarios
Scenario 2 — Basic Grid with Independent Devices
Multiple Infoblox devices can be deployed within a grid (see Figure 1.2). A grid consists of a master and at least one
member. A member can be a single Infoblox device or an HA pair that provides DNS and DHCP services seamlessly
across an entire network. The Infoblox device also provides connectivity for external primary name servers that
operate independently from a grid.
Figure 1.2 Grid and Independent Devices
Independent Standalone
Primary Server
Network
Clients
GUI
Client
Internet
Independent DNS
Secondary Server
Grid
Grid Master
Grid Member
HA Grid Member
A grid is controlled through a single GUI. The Infoblox device GUI allows you to centrally configure and monitor any or
all grid members. This approach reduces the time normally required to configure multiple network devices and
services because you can enter all of the settings, device data, and network services for each member using one
interface, not all the individual interfaces of each member on a recurring basis.
The Infoblox distributed database architecture enables all grid members to instantaneously receive changes to the
grid configuration settings because there is automatic synchronization between all of the Infoblox devices via a
secure link.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
29
Overview
Scenario 3 — Multiple Grids
The Infoblox device is designed to manage independently-controlled grids, each from a unique location (see
Figure 1.3). For example, a global network could be managed by four independent grids. The Infoblox device is
designed for scalable implementations to ease your network management needs. Each grid is centrally managed,
which significantly reduces costs associated with DNS and DHCP management tasks.
Figure 1.3 Multiple Grids
European
Grid
Americas
Grid
Asia/PAC
Grid
Australian
Grid
GUI Clients
30
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deployment Scenarios
Scenario 4 — Primary and Secondary Infoblox Devices
The Infoblox devices can also be deployed with other network servers. For example, Figure 1.4 shows how an Infoblox
device can operate as the primary DNS server along with two secondary name servers (a local secondary name server
and an Infoblox device external secondary server) without the Infoblox devices being part of a grid.
The primary DNS server is deployed inside the corporate internal firewall. In this case, the primary DNS server is an
HA pair of Infoblox devices, which provides redundancy in the event of hardware failure. The Infoblox device external
secondary name server is deployed outside of the company’s internal firewall. In this case, the Infoblox device
external secondary name server is a single Infoblox device, but it could have been an HA pair.
Figure 1.4 Primary and Secondary Servers
Network Clients
Independent HA Pair
(Primary Server)
Internet
GUI Client
DNS Server
Independent
Standalone Device
(Secondary Server)
(External Secondary Server)
Because the external secondary name server is outside of the corporate network, it provides an offsite source of name
resolution for the corporate customers and partners should the corporate connection to the Internet fail. Moreover,
even when the corporate link to the Internet is up, the external secondary server receives most of the queries for data
in the corporate external zones. This type of deployment results in the following benefits:
•
The use of the corporate Internet connection for name resolution traffic is minimized.
•
Name resolution by Internet name servers is faster.
Infoblox devices can also operate as forwarders or caching-only servers, either as a single node or as part of an HA
pair. A forwarder is responsible for handling queries from the internal name servers for Internet domain names
(queries that they cannot process themselves because they lack Internet connectivity).
Just as the primary DNS server is located inside the corporate internal firewall, the forwarder is also located inside
the firewall. Consequently, you must configure firewall rules that allow the forwarder to perform the following tasks:
•
Send queries to the Internet name servers
•
Receive responses from those Internet name servers
•
Block unsolicited DNS messages from the Internet name servers
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
31
Overview
32
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 2 Infoblox GUI
This chapter introduces the two versions of the Infoblox GUI (Graphical User Interface):
•
Infoblox Grid Manager GUI for Infoblox devices running a software package, such as DNSone or the NSQ
(Network Services for Lucent VitalQIP® ) package, with the Keystone upgrade
•
Infoblox Device Manager GUI for Infoblox devices running a software package without the Keystone upgrade
The chapter lists the requirements for the management system you use to access an Infoblox device, explains how to
access it, and describes the components of the Infoblox Manager GUI, including the online help. The topics in this
chapter include:
•
•
•
•
Management System Requirements on page 34
Accessing the Infoblox GUI on page 34
— Connecting to an Infoblox Device with JWS on page 35
— A Single Infoblox GUI Application on page 38
SSL (Secure Sockets Layer) Protocol on page 39
— Managing Certificates on page 41
Understanding the GUI Components on page 43
— Main Interface Components on page 43
— Customizing a Perspective Layout on page 45
— Creating a Login Banner on an Infoblox Device on page 46
— Using Global Search on page 46
— Printing from the GUI on page 47
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
33
Infoblox GUI
Management System Requirements
The management system is the computer from which you configure and manage the Infoblox device. The
management system must meet the following requirements to operate an Infoblox device.
Figure 2.1 Software and Hardware Requirements for the Management System
Management System Software Requirements
GUI ACCESS
•
Management System Hardware Requirements
•
Minimum System: 500 MHz CPU with 256
MB RAM available to the product GUI, and
56 Kbps connectivity to an Infoblox device
•
Recommended System: 1 GHz (or higher)
CPU with 512 MB RAM available for the
product GUI, and network connectivity to an
Infoblox device
•
Monitor Resolution: 1024 x 768 (minimum)
to 1600 x 1200 (maximum)
®
Microsoft Internet Explorer 6.0 or higher on
Microsoft Windows® 2000, Microsoft
Windows XP®
or
•
Mozilla 1.7 or higher on Linux
•
Fedora, Red Hat
and
•
Sun® Java Runtime Environment (JRE)
versions 1.5.0_06 through 1.5_xx
•
JWS application, which is automatically
installed with JRE 1.5.0_06 through 1.5_xx
CLI ACCESS
•
Secure Socket Shell (SSH) client that
supports
SSHv2
•
Terminal emulation program, such as
minicom or Hilgraeve Hyperterminal®.
Note: If the browser used to manage the device has a pop-up blocker enabled, you must turn off the pop-up blocker
for the IP address used to manage the device.
Accessing the Infoblox GUI
Before you access the Infoblox GUI, connect your device to the network as described in the user guide or quick start
guide that shipped with your product. Refer to Hardware Information on page 531 for more information on cabling
and powering up the device.
Note: Before proceeding, make sure your computer meets the current requirements for the GUI client as described
in Management System Requirements.
You can then access and log in to an Infoblox device using JWS (Java Web Start). You can use any computer on your
network that has the following applications:
•
JRE (Java Runtime Environment) version 1.5.0_06 through 1.5_xx
•
JWS application, which is automatically installed with JRE 1.5.0_06 through 1.5_xx
•
Standard browser that associates JNLP (Java Network Launching Protocol) file types with the JWS
34
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Accessing the Infoblox GUI
The Java installation typically makes this association automatically, although not in all UNIX environments. If the
browser does not automatically associate a JNLP file with the JWS application, when you click Launch Grid Manager
or Launch Device Manager, you receive a prompt. Internet Explorer running on a Windows system and Mozilla running
on a Linux system provide different prompts:
•
Internet Explorer prompts you to save the JNLP file. Click Cancel, and make the file association as follows:
1. Click Start -> Control Panel -> Folder Options -> File Types -> New.
2. In the File Extension field, type JNLP, and then click Advanced.
3. From the Associated File Type drop-down list, choose JNLP File, and then click OK.
4. To close the Folder Options dialog box, click Close.
You can now continue logging in to the device.
•
Mozilla prompts you to save the JNLP file or choose an application to open it.
1. Select the Open with button, and then choose Other from the drop-down list.
2. Navigate to the Java directory—typically in a standard system directory like /usr/java/ on Linux systems.
3. Open the jre1.5.0_06 (or later) subdirectory, and locate and select the JWS application, which is usually
named javaws. Although the exact path structure and directory names can differ, it might be in a directory
named javaws or bin.
You can now continue logging in to the device.
When using JWS to run the GUI application, you download the GUI application to a container within a Java sandbox
on your computer and start it from there. JWS provides mechanisms to ensure automatic updates for JRE (Java
Runtime Environment) and the GUI application.
Connecting to an Infoblox Device with JWS
To make an initial management connection to the Infoblox device:
1. Start your browser, and enter https://ip_addr, where ip_addr is the IP address of the Infoblox device that you
entered through the LCD or serial port, or the default IP address 192.168.1.2. (For more information, see Using
the LCD Panel on page 533 and Using the Serial Console on page 533.)
The Infoblox device sends its server certificate to the browser to authenticate itself during the SSL (Secure
Socket Layer) handshake. Because the default certificate is self-signed, your browser does not have a trusted
CA (certificate authority) certificate or a cached Infoblox device server certificate (saved from an earlier
connection) to authenticate the device certificate. Also, the host name in the default certificate is
www.infoblox.com, which is unlikely to match the host name of your Infoblox device. Consequently, messages
appear warning that the certificate is not from a trusted certifying authority and that the host name on the
certificate is either invalid or does not match the name of the site that sent the certificate.
Note: To eliminate certificate warnings, you can replace the default self-signed certificate with a different
certificate that has the host name of your Infoblox device. You can either generate another self-signed
certificate with the right host name and save it to the CA certificate store of your browser (and, later in the
procedure, to the certificate stores for JWS and the downloaded GUI application), or request a CA-signed
certificate with the right host name and load that on the device. For information, see Managing Certificates
on page 41.
2. Either accept the certificate just for this session or save it to the certificate store of your browser.
3. When the Infoblox device home page opens, click Launch Grid Manager or Launch Device Manager.
The browser and JWS perform the following operations:
a.
The browser requests the JNLP (Java Network Launching Protocol) file from the Infoblox device and
sends the file it receives to JWS (Java Web Start).
b. JWS checks for the JNLP file in its cache and, if it finds it, compares it with the recently received JNLP file.
Because this is the initial connection attempt, JWS does not yet have this file cached. In subsequent
connection attempts, comparing the newly downloaded JNLP file with the cached file can indicate
whether JWS needs to update any items that the file specifies.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
35
Infoblox GUI
c.
If JWS discovers there is no cached JNLP file or that the new JNLP file differs from the earlier file, JWS
builds an SSL tunnel to the sources specified in the JNLP file. For this initial connection, JWS must make
an SSL connection to the Infoblox device to download the GUI application.
JWS displays a security warning prompting you to accept or reject the Infoblox device certificate the
device sends to authenticate itself. If the default certificate is in use, warning messages appear stating
the certificate is not from a trusted certifying authority, and that the host name on the certificate is either
invalid or does not match the name of the site. This is the same certificate that the Infoblox device uses
to authenticate itself during all SSL handshakes.
4. Either accept the Infoblox device server certificate just for this SSL session, or save it permanently to the JWS
server certificate store.
After the SSL tunnel is established, the device begins to download the GUI application, which is signed with a
different certificate than the server certificate the device uses to authenticate itself during SSL handshakes. The
certificate authenticating the GUI application is signed by Verisign. When received by JWS, it displays a security
warning prompting you to accept or reject the signed application.
5. Do one of the following:
— Click Yes to accept the authenticity of the Infoblox appliance GUI application for this download.
— Click Always to accept the authenticity of the Infoblox appliance GUI application for this and future
downloads by saving the certificate to the JWS application certificate store.
Note: To manage server certificates in JWS, open the Java Application Cache Viewer, and then click Edit ->
Preferences -> Security -> Certificates.
JWS downloads the Infoblox GUI application and any other items it needs—or, for subsequent connections, just
the items it needs to update. (For this initial connection, JWS downloads the GUI application. It might also
download a different version of JRE. The Infoblox device supports JRE 1.5.0_06 or later.)
6. After the Infoblox GUI application download is complete, begin the login process by choosing the host name of
the Infoblox device from the Hostname drop-down list and entering the user name and password. The default
user name is admin, and the default password is infoblox.
Note: The user name and password are case-sensitive. Infoblox recommends changing them after you log in. For
more details, refer to Creating an Admin Account on page 56.
The GUI application initiates an SSL connection to the Infoblox device. The device sends its server certificate to
authenticate itself to the application. If the default certificate is in use, warning messages appear stating the
certificate is not from a trusted certifying authority and that the host name on the certificate is either invalid or
does not match the name of the site.
7. Accept the certificate for this session, or save it permanently to the server certificate store of the GUI application.
Note: To manage CA and server certificates in the Infoblox GUI application, open the GUI application login
prompt, and then click Certificates.
The SSL tunnel completes, and the login process continues. If the login is successful, the connection between
the Infoblox GUI application and the Infoblox device is complete. If the login is not successful, an error message
appears and the login prompt returns.
When the session ends, the Infoblox GUI application remains in the Java sandbox. You can launch it from this
location the next time you want to connect to the Infoblox device.
36
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Accessing the Infoblox GUI
Figure 2.2 Java Web Start Initial Access
= CA (Certificate Authority) Certificates
= Infoblox Server Certificate
(authenticates the device when
establishing an SSL tunnel)
= Server Certificates
= Application Certificate
(authenticates GUI application
during download)
= Java Application Certificates
Management Client
Browser
Certificates
Browser
Infoblox Device
SSL Tunnel
JNLP File Download
1 The browser and device form an SSL
tunnel. The browser either accepts the
device certificate automatically or the
administrator accepts it manually. Then
the browser downloads the JNLP file and
passes it to the Java application.
Java
Certificates
Java
Sandbox
GUI Application Download
2 The JNLP files instructs Java to check if it
has the latest GUI application and
downloads it if necessary. Java and the
device form a new SSL tunnel between
themselves. If Java automatically accepts
the two certificates—one authenticating
the device and the other authenticating the
GUI application—or if the administrator
accepts them manually, the GUI
application download proceeds.
Infoblox GUI
Application
GUI
Certificates
GUI
Application
Certificate
authenticating
the device to
management
system browser
+
Certificates
authenticating
device and
downloaded GUI
application to
Java application
Commands
Infoblox GUI application and the device
3 The
form a third SSL tunnel. If the GUI
application accepts the device certificate
automatically or the administrator accepts it
manually, the administrator can complete the
login and begin sending commands to the
device.
Certificates
authenticating
device to GUI
application
After you make the initial connection, you can start the Infoblox GUI application with one of these methods:
•
Browser – This is identical to the initial connection. Start your browser, and enter https://domain_name or
https://ip_addr to reach the Infoblox device.
•
Infoblox GUI Application Shortcut – If you created a shortcut (when prompted by JWS), double-click the shortcut
icon on your desktop. JWS checks the JNLP file and the Infoblox device resource files (.jar files containing
components of the Infoblox GUI application) for updates. JWS downloads any updated items it might find, and
then the GUI application login prompt appears.
•
Java Application Cache Viewer – Open the Java Application Cache Viewer, and click the Infoblox GUI application
that you want to use. Then click either Launch Online or Launch Offline. When you select Launch Online, JWS
checks the JNLP file and the Infoblox device resource files for updates before the GUI application connects to the
device. When you select Launch Offline, JWS does not check for updates before the Infoblox GUI application
connects to the device.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
37
Infoblox GUI
Clearing Cache on a Linux Computer
The following error message usually indicates that you must clear your Linux computer cache:
Server software version xx-xx-xx is not compatible with this GUI application. Obtain a
compatible GUI version by pointing a browser at https://xx.xx.xx."
1. Enter the following commands on a Linux terminal window to clear your computer's cache:
cd /.java/deployment/cache/javaws
rm -rf https
This clears the cache.
2. Open a web browser and go to the same web address (https://xx.xx.xx).
3. Click the Launch ID Grid.
A Single Infoblox GUI Application
JWS can use the same Infoblox GUI application for different devices as long as each device is running the same
version of software. However, each time you use the browser to initiate a connection to a different Infoblox device,
JWS downloads the GUI application to the Java sandbox—even if you have already downloaded the same version of
the application when connecting to another device. If you manage a number of independent Infoblox devices, this
can result in many unnecessary downloads. To use the same GUI application for multiple Infoblox devices running
the same software version, do not begin the connection process from the browser. Instead, do the following:
1. Use the GUI application shortcut or open the Java Application Cache Viewer.
2. Click the GUI application that you want to use, and then click Launch Online (to check for updates) or Launch
Offline (to bypass update checks).
Figure 2.3 Java Application Cache Viewer
GUI Application for
the Infoblox Device
3. When the login prompt appears, either select an existing host name from the Hostname drop-down list, or type
a new host name in the Hostname field. Then enter the correct user name and password, and click .
38
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
SSL (Secure Sockets Layer) Protocol
Figure 2.4 GUI Application Login Prompt
Choose an existing host
name from the drop-down
list, or type a new host name
in the Hostname field.
Custom banner text (if defined)
appears under the words
Restricted Access - Login Required
as soon as you enter a valid IP
address or DNS name in the
Hostname field.
Entering an invalid IP address or
DNS name, causes JWS to hang.
If JWS does not have the right version of the GUI application for an Infoblox device to which you connect—and you are
launching the application online—then JWS downloads it. For example, if another administrator upgrades the
software on an Infoblox device for which you previously downloaded an Infoblox GUI application and you then log in
through JWS, the GUI application on your computer no longer matches the software on the Infoblox device. JWS then
downloads the correct application (or just the changed components of the application that it needs to update to the
newer version).
SSL (Secure Sockets Layer) Protocol
When you log in to the Infoblox device, your computer makes an HTTPS (Hypertext Transfer Protocol over Secure
Sockets Layer protocol) connection to the Infoblox device. HTTPS is the secure version of HTTP, the client-server
protocol used to send and receive communications throughout the Web. HTTPS uses SSL (Secure Sockets Layer) to
secure the connection between a client and server. SSL provides server authentication and encryption. The Infoblox
device supports SSL versions 2 and 3.
When a client first connects to a server, it starts a series of message exchanges, called the SSL handshake. During
this exchange, the server authenticates itself to the client by sending its server certificate. A certificate is an electronic
form that verifies the identity and public key of the subject of the certificate. (In SSL, the subject of the certificate is
the server.) Certificates are typically issued and digitally signed by a trusted third party, the Certificate Authority (CA).
A certificate contains the following information: the dates it is valid, the issuing CA, the server name, and the public
key of the server.
A server generates two distinct but related keys: a public key and a private key. During the SSL handshake, the server
sends its public key to the client. Once the client validates the certificate, it encrypts a random value with the public
key and sends it to the server. The server decrypts the random value with its private key.
The server and the client use the random value to generate the master secret, which they in turn use to generate
symmetric keys. The client and server end the handshake when they exchange messages indicating that they are
using the symmetric keys to encrypt further communications.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
39
Infoblox GUI
Figure 2.5 SSL Handshake
Client contacts the Infoblox device and recommends
certain parameters, such as SSL version, cipher
settings, and session-specific data.
The device either agrees or recommends other
parameters. It also sends its certificate which
contains its public key.
Plain
Text
Client encrypts random number with the public
key and sends it to the device. The device uses
its private key to decrypt the message.
Cipher The client and the device generate the master
secret, and then the symmetric keys.
Text
Cipher
Text
Cipher
Text
The client and the device agree to encrypt all
messages with symmetric keys.
The client and the device send all their messages through the SSL tunnel
which uses the cipher settings and encryption to secure their connection.
Public Key
Private Key
40
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
SSL (Secure Sockets Layer) Protocol
Managing Certificates
The Infoblox device generates a self-signed certificate when it first boots up. (A self-signed certificate is signed by the
subject of the certificate, and not by a CA.) This is the default certificate. When your computer first connects to the
Infoblox device, it sends this certificate to authenticate itself to your browser.
Because the default certificate is self-signed, your browser does not have a trusted CA certificate or a cached Infoblox
device server certificate (saved from an earlier connection) to authenticate the device certificate. Also, the host name
in the default certificate is www.infoblox.com, which is unlikely to match the host name of your device. Consequently,
messages appear warning that the certificate is not from a trusted certifying authority and that the host name on the
certificate is either invalid or does not match the name of the site that sent the certificate. Either accept the certificate
just for this session< or save it to the certificate store of your browser.
To eliminate certificate warnings, you can replace the default self-signed certificate with a different certificate that has
the host name of your device. The device supports X.509 certificates in .PEM format. After initial login, you can do
one of the following:
•
Generate another self-signed certificate with the correct host name and save it to the certificate store of your
browser.
•
To generate a self-signed certificate, see Generating a Self-Signed Certificate on page 41.
•
Request a CA-signed certificate with the correct host name and load that on the Infoblox device.
•
To use a certificate from a CA, generate a certificate signing request as described in Generating a Certificate
Signing Request on page 42. When you receive the certificate from the CA, you can import it as described in
Importing a Certificate on page 42.
Generating a Self-Signed Certificate
You can replace the default certificate with a self-signed certificate that you generate. When you generate a
self-signed certificate, you can specify the correct host name and change the public/private key size, enter valid
dates and specify additional information specific to the device. If you have multiple devices, you can generate a
certificate for each device with the appropriate host names.
To generate a self-signed certificate:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Members ) -> grid_member -> Tools -> HTTPS
Certificate -> Generate Self-Signed Certificate.
For an independent device or HA pair: From the Device perspective, click hostname) -> Tools -> HTTPS Certificate
-> Generate Self-Signed Certificate.
2. In the Create Self-Signed Certificate dialog box, enter the following:
— Key Size: Select either 2048 or 1024 for the length of the public key.
— *Days Valid: Specify the validity period of the certificate.
— *Common Name: Specify the domain name of the Infoblox device. You can enter a fully qualified domain
name (FQDN).
— Organization: Type the name of your company.
— Organizational Unit: Type the name of your department.
— Locality: Type a location, such as the city or town of your company.
— State or Province: Type the state or province.
— Country Code: Enter the 2-letter code that identifies the country, such as US.
— Administrator’s E-mail Address: Enter the e-mail address of the device administrator.
— Comment: Enter additional notes.
An asterisk (*) indicates the field is required.
3. Click OK to close the Create Self-Signed Certificate dialog box.
4. Click the Save icon.
The Infoblox device logs you out, or you can log out yourself. When you log in to the device again, it uses the
certificate you generated.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
41
Infoblox GUI
Generating a Certificate Signing Request
You can generate a certificate signing request (CSR) that you can use to obtain a signed certificate from your own
trusted CA. Once you receive the signed certificate, you can import it into the Infoblox device, as described in
Importing a Certificate.
To generate a CSR:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Members ) -> grid_member -> Tools -> HTTPS
Certificate -> Generate Signing Request.
or
For an independent device or HA pair: From the Device perspective, click hostname) -> Tools -> HTTPS Certificate
-> Generate Signing Request.
2. In the Create Certificate Signing Request dialog box, enter the following:
— Key Size: Select either 2048 or 1024 for the length of the public/private key pair.
— *Common Name: Specify the domain name of the Infoblox device. You can enter a fully qualified domain
name (FQDN).
— Organization: Type the name of your company.
— Organizational Unit: Type the name of your department.
— Locality: Type a location, such as the city or town of your company.
— State or Province: Type the state or province.
— Country Code: Enter the 2-letter code that identifies the country, such as US.
— Administrator’s E-mail Address: Enter the e-mail address of the device administrator.
— Comment: Enter additional notes.
An asterisk (*) indicates the field is required.
3. Click OK to close the Create Certificate Signing Request dialog box.
4. In the Download filename dialog box, navigate to where you want to download the CSR, enter the file name and
click Save.
Importing a Certificate
You can replace the default server certificate with a signed certificate from your own trusted CA. First, generate a
certificate signing request as described inGenerating a Certificate Signing Request on page 42.
When you import a certificate, the Infoblox device finds the matching CSR and takes the private key associated with
the CSR and associates it with the newly imported certificate. The device then automatically deletes the CSR.
To import a certificate:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Members ) -> grid_member -> Tools -> HTTPS
Certificate -> Upload Certificate.
or
For an independent device or HA pair: From the Device perspective, click hostname) -> Tools -> HTTPS Certificate
-> Upload Certificate.
2. Navigate to where the certificate is located and click Open.
The device imports the certificate and logs out. When you log in to the device again, it uses the certificate you
imported.
42
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Understanding the GUI Components
Understanding the GUI Components
You can view data and configuration settings and make configuration changes through the Infoblox GUI using the
following two methods:
•
Device Manager: When an Infoblox device functions as an independent device, you launch the Device Manager
to access the GUI. The name appears in the title bar of the browser window.
•
Grid Manager: When the device is in a grid, you log in to the grid master and launch the Grid Manager. The name
appears in the title bar of the browser window.
Main Interface Components
The following figure illustrates the typical layout of the Infoblox GUI. You can detach and move the GUI components
and customize the GUI as necessary.
Figure 2.6 Infoblox GUI Overview
Menu
Tool Bar
Perspective
Editor
Enter and edit information.
Panels
View and select items
to edit.
Detach and move panels,
viewers and editors to
customize the GUI layout.
Properties Viewer
View object properties.
Menu
Each item in the menu is a drop-down list of available options. The menu items change dynamically according to the
perspective you are in.
Tool Bar
The tool bar contains a Save icon which you click to save your configuration changes, and a Restart Services icon,
which you click to restart services on a device or grid.
Save
NIOS 4.1r3
Restart Services
Infoblox Administrator Guide (Rev. A)
43
Infoblox GUI
Perspectives
A perspective is a container for tools used to manage the grid or device and its services. The Infoblox GUI application
provides a set of perspectives, each focusing on a specific functional area. You display a perspective by clicking the
appropriate icon on the tool bar:
DNS
Perspective Icon
Grid or Device
Perspective Icon
Authentication, Authorization, and
Accounting Perspective Icon
DHCP and IPAM
Perspective Icon
Administrators
Perspective Icon
File Distribution
Perspective Icon
Global Search
Perspective Icon
•
Device: In this perspective, you configure an independent device and set its operational parameters.
•
Grid: In this perspective, you configure a grid and set operational parameters. A Keystone license is required for
this feature.
•
DNS: In this perspective, you enable and configure DNS services on the device or grid.
•
DHCP and IPAM: In this perspective, you enable and configure DHCP service and IP Address Management
features.
•
Administrators: In this perspective, you configure administrators.
•
File Distribution: In this perspective, you enable and configure HTTP and TFTP (Trivial File Transfer Protocol)
services.
•
AAA: In this perspective, you configure RADIUS services to authenticate and authorize users, as well as manage
user accounts.
•
Global Search: In this perspective, you search the entire database for a specific text string. All database objects
matching the text string are displayed in this perspective.
•
VitalQIP: In this perspective, you can configure the device to function as a VitalQIP remote server. A VitalQIP
license is required for this feature.
Note: The VitalQIP icon only displays when the NSQ software module and required licensing are installed.
Panel
Panels list objects that you can select and edit. You can expand or collapse lists by selecting the + or - sign beside
an object. Panels can be opened and closed from the View menu on the top menu bar.
Shortcuts
— Double-click the tab of a panel to fully expand; double-click the tab again to reset the panel.
— Select an object and right-click to display options.
— Double-click an item to edit it (open its editor).
— Ctrl+click to select multiple items.
Editor
You can enter information and configure objects in an editor. You can open multiple editors at one time. After you
enter information in an editor, you must click the Save icon to save your changes.
44
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Understanding the GUI Components
Properties Viewer
Viewers display information about a selected object. You cannot edit or select objects in a viewer. However, you can
expand, collapse, detach and move viewers to different locations.
Online Help
The Infoblox device ships with online help you can access from anywhere in the GUI.
•
To access the main Help system, click Help -> Help Contents.
•
To access Help for the active panel, editor, or viewer, click Help -> Dynamic Help. A window is active when its title
bar is highlighted.
•
To access Help for a dialog box, click the question mark (?) icon in the bottom left corner of the dialog box.
In addition, you can download the Infoblox Administrator Guide by clicking Help -> Download Admin Guide.
Customizing a Perspective Layout
You can customize the layout of a perspective by detaching and rearranging panels and views. In this way, you can
structure your workspace for optimum efficiency.
To customize a perspective layout:
1. Right-click the tab of the panel or view, and select
Detached from the context menu.
2. Left-click and drag to the desired location.
3. Resize and tile multiple detached panels or views to
create a custom layout.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
45
Infoblox GUI
Creating a Login Banner on an Infoblox Device
To create a statement that appears on the top of the Login screen, follow the procedures in this section. This function
is useful for posting security warnings or user-friendly information well above the user name and password fields on
the Login screen. A login banner message can be up to 3000 characters long. In a grid, perform this task on the grid
master.
To create a login banner:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security.
3. Select Enable Login Banner and enter the text you want displayed in the Banner Text field.
4. Click the Save icon.
Using Global Search
This function allows you to search through the entire Infoblox device database for any instances matching a specific
text string. The global search option allows you to search across different perspectives and views, instead of
searching under each perspective or view individually. For example, you can search for a specific hostname across
both the DNS perspective and DHCP perspective with a single global search. You can search for all occurrences of a
specific MAC address within the database.
The Global Search perspective is located next to the other perspectives in the GUI toolbar. The Global Search
perspective opens up a panel called Search Results and displays all matches within the panel. All match results are
displayed with the following information:
•
Name: Name of the matching object.
•
Type: Object type matching the global search. For example, the Type field identifies the type of record or type of
address of the matching object.
•
Matched Attribute: Attribute of the matching object. For example, if the global search matched the address
corresponding to a hostname, then field displays the address of the hostname.
•
Matched Value: The value of the matching object. For example, if the global search matched the address of a
hostname, then the field displays the hostname.
Note: NIOS displays search results based upon the page size setting from the administrator settings. For
information about page size configuration, see Creating an Admin Account on page 56.
To search globally:
1. From the Global Search perspective, type the text string to search on the device database.
2. Click Search.
NIOS supports regular expression for global search. Regular expressions, commonly known as regex are a set of key
combinations that are meant to allow the user to have a variety of control over what they are searching for.
From the Search Results panel, you can do the following:
•
Open up a panel to view the properties of a matching object.
•
Open up a panel to edit the properties of a matching object.
•
Remove a matching object from the database.
You can perform these operations by clicking matching object -> Edit.
46
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Understanding the GUI Components
Printing from the GUI
NIOS supports the ability to print the contents of the GUI screen from any perspective. Printing from the GUI allows
you to print out the contents of a view within any perspective shown on the display. All page modifications that are
applied to the display contents, such as filters and sorting, affects the print output as well.
You can print to the following outputs:
•
Paper copy to the printer
•
PDF
•
Text File (MS WIndows only)
The amount of content printed depends on the page size configuration set by the administrator. For information on
configuring the page size, see Creating an Admin Account on page 56.
Note: GUI printing is supported on the Microsoft Windows operating system only.
To print out a hard copy or PDF file from the GUI:
1. From any perspective, click File -> Print. The print dialog box appears.
2. Set the print options you want for the print job. You can set the following print options:
— Selected printer
— Print preferences: portrait or landscape page orientation, legal or letter page size, and page margins.
— Print to file (for PDF generation).
— Page range.
— Number of copies.
3. Click Print.
To print to a text file in the Windows operating system:
1. Install a new generic printer to Windows called “GenericText’.
2. From any perspective, click File -> Print. The print dialog box appears.
3. Set the print options you want for the print job. You can set the following print options:
— Select the new ‘GenericText’ printer.
— Print preferences: portrait or landscape page orientation, legal or letter page size, and page margins.
— Page range.
— Number of copies.
4. Click Print.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
47
Infoblox GUI
48
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 3 Managing Administrators
This chapter describes the various tasks associated with setting up admin groups and accounts. These tasks apply
to both independent and grid installations. This chapter contains the following sections:
•
•
•
•
•
•
Local and Remote Admin Accounts on page 50
Local Admin Groups and Accounts on page 52
— Creating a Superuser Admin Group on page 52
— Creating a Limited-Access Admin Group on page 53
— Creating an Admin Account on page 56
— Modifying and Removing an Admin Account on page 56
Authentication Using RADIUS on page 57
— Configuring RADIUS Server Authentication on page 58
— Configuring a RADIUS Server on page 61
Remote Admin Groups and Accounts on page 62
— Configuring a RADIUS Server for Remote Admin Groups on page 62
— Creating a Remote Admin Group on page 64
— Configuring a RADIUS Server for Remote Admin Accounts on page 65
Changing Password Length Requirements on page 65
Notifying Administrators on page 66
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
49
Managing Administrators
Local and Remote Admin Accounts
Infoblox uses the concept of administrator groups to which you add one or more individual administrators. The
administrators inherit the privileges and properties for the group to which they belong. You can add the
administrators locally (that is, on the Infoblox device) or remotely (on a RADIUS server). The tasks involved in storing
administrator accounts locally and remotely are listed in Table 3.1.
Table 3.1 Storing Admin Accounts Locally and Remotely
Infoblox device
To store admin
accounts locally
To store admin
accounts remotely
•
Use the default admin group
(“admin-group”) or define a new group
•
Set the privileges and properties for the
group
•
Add admin accounts to the group
•
Configure communication settings with
a RADIUS server
RADIUS server
•
Configure communication settings with
the Infoblox device
If you use admin groups on the RADIUS
server:
If you use admin groups on the RADIUS
server:
•
Use an existing admin group or define a
new one
•
Import Infoblox VSAs (vendor-specific
attributes)
•
Set the privileges and properties for the
group
•
Define an admin group with the same
name as that on the Infoblox device
If you do not use admin groups on the
RADIUS server:
•
Define admin accounts and link them to
an admin group
•
If you do not use admin groups on the
RADIUS server:
Assign an admin group as the default
•
Define admin accounts
Some general points about admin groups and admin accounts:
•
Regardless of the location of an admin account, the group from which the admin receives privileges and
properties is stored locally.
•
An admin account can only belong to one admin group at a time.
•
All local admin accounts must belong to a local admin group.
•
Remote admin accounts can—but do not have to—belong to a remote admin group.
— If a remote admin account belongs to a remote admin group, the name of the remote admin group must
match the name of a local admin group.
— If the name of a remote admin group does not match the name of a local group and there is a default admin
group on the Infoblox device, the device applies the privileges and properties of the default group to
admins belonging to the remote group.
— If the name of a remote admin group does not match the name of a local group and there is no default
admin group on the device, admins belonging to the remote group cannot access the device.
— If a remote admin account does not belong to a remote admin group, you must specify a default admin
group on the Infoblox device from which the remote admin account receives its privileges and property
settings.
For an illustration showing the relationship of local and remote admin accounts, admin groups, and privileges and
properties, see Figure 3.1 on page 51.
50
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Local and Remote Admin Accounts
Figure 3.1 Privileges and Properties Applied to Local and Remote Admin Accounts
Infoblox Device
RADIUSone
Local
Admin
Groups
Remote
Admin
Groups
Admin
Users
The Infoblox device first
checks if an admin account
is stored locally.
Access privileges and properties come
from local admin group definitions.
Login
Admin-Group1
Adam
Login
When remote admin
accounts are not in
an admin group (or in a
group whose name does
not match that of a local
group), the Infoblox
device applies the
Default Admin-Group
privileges and properties.
Default
Admin-Group
Balu
Login
Group
names
must
match.
Admin-Group2
When admin
accounts are in
a remote admin
group, there must
be a local admin
group with the
same name so
that the device can
apply the privileges
and properties to
the admin
belonging
to that group.
Admin-Group2
Christine
Login
Login
Admin-Group3
Dan
Admin-Group3
Eve
Assigned from local admin group definitions:
Access Privileges
(for Infoblox views, zones, networks,
members and DHCP lease history)
Properties
(for page and tree sizes)
There can be admin
accounts in a local and
remote admin group with
the same group name.
Note:
= Admin Account
To set up local admin accounts, see Local Admin Groups and Accounts on page 52. To store admin accounts on a
remote RADIUS server, see Local Admin Groups and Accounts on page 52.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
51
Managing Administrators
Local Admin Groups and Accounts
All local admin accounts must belong to a local admin group. The privileges and properties that you set for the group
apply to all the admin accounts that you assign to that group.
There are three types of privilege settings:
•
Superuser – Superuser admin groups provide their members with unlimited access and control of all the
operations that an Infoblox device performs. There is a default superuser admin group with one superuser
admin. You can add users to this default admin group and create additional admin groups with superuser
privileges.
•
Limited-Access – Limited-access admin groups provide their members with read-only or read/write access to
specific zones, networks, and grid members. You can create admin groups with specific access privileges.
•
ALL USERS – The ALL USERS group is a default group in which you define global privileges for all limited-access
users. This group implicitly includes all limited-access users configured on the device.
You can configure multiple admin accounts for local or remote authentication. However, there must always be one
superuser admin account stored in the local database to ensure that at least one administrator can log in to the
device in case the Infoblox device loses connectivity to the RADIUS server.
Creating a Superuser Admin Group
To create a superuser admin group:
1. Log in as a superuser. (Only a superuser can create admin groups.)
2. From the Administrators perspective, click Groups -> Edit -> Add Group.
3. In the Add Administrator Group editor, click Group Properties and enter the following:
— Group Name: Enter the name for the admin group.
— Comment: Enter pertinent information about the group, such as location or department. The data entered
here appears in the list view of the GUI when you select an admin group name in the tree view.
— Superuser: Select this check box to grant the admin accounts that you assign to this group full authority to
view and configure all types of data. Clear this check box to set limited privileges for this admin group.
— Allow DHCP lease history access: Select this check box to allow administrators that belong to this group to
view the DHCP lease history log. Note that an administrator who has the right to view the DHCP lease history
log can access the entire log and see log entries for networks and grid members that he or she might
otherwise not have access. Clear this check box to restrict access to the DHCP lease history log for
administrators that belong to this group.
— Page Size: Enter a value for the number of lines of data that you want a single GUI list view to contain for
administrators that belong to this group. When there is a lot of data, you can improve the display
performance by setting a smaller page size, such as 100 instead of 1000. You can set the page size from 10
to 2000. The default page size is 100.
— Disable this admin group: Select this check box to retain an inactivated profile for this admin group in the
configuration. For example, you might want to define a profile for recently hired administrators who have
not yet started work. Then when they do start, you simply need to clear this check box to activate the
profile.
52
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Local Admin Groups and Accounts
Creating a Limited-Access Admin Group
When you create a limited-access admin group, you determine the resources—networks, DHCP templates, zones,
resource records, and grid members—that administrators in that group can access with read-only or read/write
privileges.
To create a limited-access admin group:
1. Log in as a superuser. (Only a superuser can create admin groups.)
2. From the Administrators perspective, click Groups -> Edit -> Add Group.
3. Click Group Properties and enter the following:
— Complete the fields as described in Creating a Superuser Admin Group.
— Superuser: Clear this check box to set limited privileges for this admin group.
4. Click Group Privileges.
5. Click Add, enter the following in the Group Permissions dialog box, and then click OK:
— Select the object for which you want to grant privileges. For example, to grant privileges to the
test.corp100.com zone, click + (for All Zones) -> + (for default) -> + (for Forward Mapping Zones) ->
test.corp100.com.
— Select the appropriate privileges: Read-Only, Read-Write, Deny.
6. Click Advanced Zone Permissions to specify resource record type permissions for all resource record types in the
zone. The Advanced Zone Permissions dialog displays the selected zone name and the list of resource record
types for the zone. The resource record types displayed depend on the selected zone. The dialog also enables
you to select Read-Only, Read/Write, or Deny permissions for each resource record type using the drop-down
menu next to it.
If a zone has Read-Only permissions, the default permission for all resource record types is Read-Only.
If a zone has Read/Write permissions, the default permission for all resource record types is Read/Write.
Specify the following permissions for each resource record type in the zone using the drop-down menu next to
it, and then click OK:
— Read-Only: Grant read-only permission to the resource record type. Users can view the record, but cannot
add, modify, or delete it.
— Read/Write: Grant read-write permissions to the resource record type. Users can view, add, modify, and
delete the record.
— Deny: Deny read or write permissions to the resource record type. Users cannot view, add, modify, or delete
the record.
7. Click OK to close the Group Permissions dialog box.
The object for which you set access privileges appears in the Privileges list in the Add Administrator Group
editor.
8. Click the Save icon to save your changes.
Assigning Privileges to All Users
By default, granting read-only or read/write privileges for a zone also grants read-only privileges for all zones and
subzones in the same view. (For information about Infoblox views, see Using Infoblox Views on page 250.)
To limit access to zones within a view, you must do the following:
•
Grant read-only or read-write privileges for specific zones to the appropriate user groups.
•
Add deny rules for each zone in the same view in the ALL USERS group.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
53
Managing Administrators
In the example shown in Figure 3.2, two zones, corp100.com and corp200.com are in the default view. The
corp100.com zone has two subzones, eng.corp100.com and finance.corp.100.com. The corp200.com zone also has
two subzones, eng.corp200.com and finance.corp200.com. You create Admin Group A and grant it read/write
privileges for the eng.corp100.com zone, as follows:
1. From the Administrators perspective, click Groups -> Edit -> Add Group.
2. Click Group Properties and enter the following:
— Group Name: Admin Group A
— Complete the other fields as described in Creating a Superuser Admin Group.
— Superuser: Clear this check box.
3. Click Group Privileges.
4. Click Add, enter the following in the Group Permissions dialog box, and then click OK:
— Select Read/Write.
— Click + (for All Zones) -> + (for default) -> + (for Forward Mapping Zones) -> + (for corp100.com) ->
eng.corp100.com.
5. Click the Save icon to save your changes.
6. View the group privileges of Admin Group A by selecting it and clicking View -> Properties. The Group Privileges
section displays the privileges of Admin Group A, which are the read/write privileges to eng.corp100.com that
you configured and the read-only privileges to the default view that the device automatically created.
Figure 3.2 Admin Group with Privileges to All Zones in Default View
Default View
When you grant read-write
privileges for Admin Group A to the
eng.corp100.com zone, the device
automatically grants read-only
privileges to all the other zones in
the same view.
View
corp100.com
Zone
eng.corp100.com
Subzones
finance.corp100.com
corp200.com
Zone
Admin Group A
eng.corp200.com
Subzones
Read/Write Privileges
finance.corp200.com
Read-Only Privileges
If you do not want admin groups, such as Admin Group A in the example, to receive automatically read-only access
to all zones in the same view as a zone to which they have access, you must create a deny rule for each zone in the
view in the ALL USERS group. Setting a deny rule for each zone in a view in the ALL USERS group effectively denies
access to zones for which admin groups do not have explicit read-only or read/write privileges. Therefore, in the
example, in addition to granting privileges to Admin Group A, you must also create deny rules in the ALL USERS group
for all the other zones in the default view.
54
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Local Admin Groups and Accounts
Rules set at the zone level override rules set at the subzone level. Therefore, creating a deny rule for a particular zone,
automatically denies access to all its subzones, even if an admin group has explicit read-only or read-write privileges
to the subzone. If you want to grant some admin groups read-only and read-write privileges to subzones, you must
set the deny rules at the subzone level only.
In the example, you set a deny rule for each subzone, as follows:
1. From the Administrators perspective, click + (for Groups) -> ALL USERS -> Edit -> Group Properties.
2. In the Administrator Group editor, click Group Privileges -> Add.
3. In the Group Permissions dialog box, enter the following and click OK:
— Deny: Select check box.
— Click + (for All Zones) -> + (for default) -> + (for Forward Mapping Zones) -> + (for corp100.com) ->
finance.corp100.com.
4. Repeat steps 2 to 4 for eng.corp200.com and finance.corp200.com.
5. Click the Save icon.
Admin Group A now has read/write privileges to eng.corp100.com and no access to the other zones in the default
view, as shown in Figure 3.3 on page 55.
Figure 3.3 All Users Group with Read-Only Deny Rules
Default View
corp100.com
X
X
eng.corp100.com
finance.corp100.com
X
corp200.com
X
ALL USERS
NIOS 4.1r3
X
eng.corp200.com
finance.corp200.com
X
Admin Group A
X
Infoblox Administrator Guide (Rev. A)
55
Managing Administrators
Creating an Admin Account
When you create an admin account, you must specify the name, password, and admin group of the admin. You can
optionally provide an e-mail address and specify the page size of the GUI.
In addition, you can also control in which time zone the device displays the time in the DHCP and IPAM perspective
windows, such as the DHCP Lease History and DHCP Leases panels. The device can use the time zone that it
automatically detects from the management system that the admin uses to log in. Alternatively, you can override the
time zone auto-detection feature and specify the time zone.
To create an admin account and add it to an admin group:
1. Log in using a superuser account.
2. From the Administrators perspective, click + (for Groups) -> admin_group -> Edit -> Add Local Admin.
3. Enter the following:
— Admin Name: Enter the name of the administrator. This is the name that the administrator uses to log in.
— Group: Choose the admin group of the administrator. An admin can belong to only one admin group at a
time.
— Email Address: Enter the e-mail address for this administrator. Note that this address simply provides
contact information. The Infoblox device does not send e-mail notifications to it. You define the e-mail
address for notifications on the Email section of the Device or Grid Editor.
— Comment: Enter pertinent information about the administrator, such as location or department.
— Password: Enter a password for the administrator to use when logging in.
— Re-Type Password: Enter the same password.
— Override admin group page size: Clear this check box to use the same page length specified for the admin
group. Select this check box to enter a different page length.
— Page Size: Enter a value for the number of lines of data that you want a single GUI list view to contain for
this administrator. When there is a lot of data, you can improve the display performance by setting a smaller
page size, such as 100 instead of 1000. You can set the page size from 10 to 2000. The default page size is
100.
— Override auto-detect time zone: Select this check box if you want to specify the time zone for the
administrator. Clear this check box if you want the device to automatically detect the time zone from the
management system that the administrator uses to connect to the device.
— Time Zone: Select the time zone that the device uses when it displays the time in the DHCP and IPAM
perspective windows.
— Disable this admin: Select this check box to retain an unactivated profile for this administrator in the
configuration. For example, you might want to define a profile for a recently hired administrator who has not
yet started work. Then when he or she does start, you simply need to clear this check box to activate the
profile.
4. Click the Save icon to save your changes.
Modifying and Removing an Admin Account
You can modify and remove the admin accounts you create, but you can only partially modify the default superuser
account “admin”—and only when you are logged in as the superuser “admin”. Furthermore, because there must
always be a superuser account on the device, you can only remove the default “admin” account after you create
another superuser account.
56
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Authentication Using RADIUS
Authentication Using RADIUS
RADIUS provides authentication, accounting, and authorization functions. The Infoblox device supports
authentication using the following RADIUS servers: RADIUSone, FreeRADIUS, Microsoft, Cisco, and Funk.
You must be a superuser to configure admin accounts and RADIUS server properties on the Infoblox device. When
you configure the device to authenticate administrators using a RADIUS server, the device acts similarly to a network
access server (NAS), which is a RADIUS client that sends authentication and accounting requests to the RADIUS
server. Figure 3.4 illustrates the authentication process.
Figure 3.4 Authentication using a RADIUS server
Administrator
1
NIOS 4.1r3
Infoblox Device
A user makes an HTTPS connection
to the Infoblox device and sends a
user name and password.
RADIUS Server
2
The device checks if an admin account
in its local database matches the login
name. It does not find a match.
3
The device sends an Access-Request
packet to the RADIUS server.
The device lets the user log in and
applies the authorization profile.
4a If the RADIUS server authenticates the
The device does not allow the user to
log in.
4b If the RADIUS server rejects the
user, it sends back an Access-Accept
packet.
authentication request, it sends back an
Access-Reject packet.
Infoblox Administrator Guide (Rev. A)
57
Managing Administrators
Authentication
When you configure the Infoblox device for remote authentication with a RADIUS server, you must specify the
authentication method of the RADIUS server. You can specify either PAP (Password Authentication Protocol) or CHAP
(Challenge Handshake Authentication Protocol).
PAP tries to establish the identity of a host using a two-way handshake. The client sends the user name and password
in clear text to the Infoblox device. The device uses a shared secret to encrypt the password and sends it to the
RADIUS server in an Access-Request packet. The RADIUS server uses the shared secret to decrypt the password. If the
decrypted password matches a password in its database, the user is successfully authenticated and allowed to log
in.
With CHAP, when the client tries to log in, it sends its user name and password to the Infoblox device. The device then
creates an MD5 hash of the password together with a random number that the device generates. It then sends the
random number, user name, and hash to the RADIUS server in an Access-Request package. The RADIUS server takes
the password that matches the user name from its database and creates its own MD5 hash of the password and
random number that it received. If the hash that the RADIUS server generates matches the hash that it received from
the device, then the user is successfully authenticated and allowed to log in.
Authorization
You can specify authorization privileges for an admin group on the Infoblox device only. The device ignores
authorization settings from the RADIUS server. Therefore, you must configure all admin groups on the Infoblox device,
regardless of where the admin accounts that belong to those groups are stored—on the Infoblox device or on the
RADIUS server. For information about specifying superuser and limited-access authorization privileges, see Creating
a Superuser Admin Group on page 52 and Creating a Limited-Access Admin Group on page 53.
Accounting
You can enable the accounting feature on the RADIUS server to track an administrator’s activities during a session.
After an administrator successfully logs in, the device sends an Accounting-Start packet to the RADIUS server.
Configuring RADIUS Server Authentication
To configure the Infoblox device to authenticate administrators using a RADIUS server, you must configure admin
accounts for these administrators on the RADIUS server. Then, on the Infoblox device, you must do the following:
•
Enable RADIUS authentication and, optionally, modify the default settings.
•
Add one or more RADIUS servers.
•
Define one or more admin groups and specify its privileges and settings. If these names match admin group
names defined on the RADIUS server, the Infoblox device applies these privileges and settings to users
belonging to those groups on the RADIUS server.
•
If there are no admin groups defined on the RADIUS server, designate an admin group as the default group.
Enabling RADIUS Server Authentication
To enable RADIUS server authentication:
1. From the Administrators perspective, click + (for Remote Admins) -> RADIUS Servers -> Edit -> General RADIUS
Properties.
2. Enter the following:
— Enable RADIUS for admin authentication: Select check box.
— Use MGMT port: Select check box if the MGMT port is enabled and you want the Infoblox device to
communicate with all RADIUS servers through its MGMT port. If you clear the check box, you can still
selectively use the MGMT port for one or more specific RADIUS servers (see Adding a RADIUS Server on
page 59).
58
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Authentication Using RADIUS
— Default Group Name: Select an admin group from the drop-down list if there are admin accounts on the
RADIUS server that do not belong to a remote admin group. The Infoblox device can then apply the
privileges defined for the default admin group to those admin accounts.
— Optionally, modify the Authentication settings. These settings apply to all RADIUS servers that you
configure on the Infoblox device.
•
Retry Period: Specify the number of seconds that the device waits for a response from the RADIUS
server. The default is 5.
•
Maximum Retries: Specify how may times the device attempts to contact an authentication RADIUS
server. The default is 6.
If you configured multiple RADIUS servers for authentication and the Infoblox device fails to contact the first
server in the list, it tries to contact the next server, and so on.
— Optionally, modify the Accounting settings.
•
Retry Period: Specify the number of seconds that the device waits for a response from the RADIUS
server. The default is 5.
•
Maximum Retries: Specify how may times the device attempts to contact an accounting RADIUS
server. The default is 1000.
If you configured multiple RADIUS servers for accounting and the Infoblox device fails to contact the first
server in the list, it tries to contact the next server, and so on.
3. Click the Save icon to save your changes.
Adding a RADIUS Server
You configure RADIUS server settings at the grid level. Therefore all members in a grid use the same set of RADIUS
servers. You can configure multiple RADIUS servers for redundancy. When you do, the device tries to connect to the
first RADIUS server on the list and if the server does not respond within the maximum retransmission limit, then it
tries the next RADIUS server on the list.
To configure the properties of a RADIUS server:
1. From the Administrators perspective, click + (for Remote Admins) -> RADIUS Servers -> Edit -> Add RADIUS Server.
2. Enter the following:
— Server Name: Type a name for the RADIUS server. This name is for internal reference; for example, “auth1”.
It does not need to be the FQDN (fully qualified domain name) of the RADIUS server.
— Comment: Enter additional information about the RADIUS server.
— Authentication
•
Type: Specify the authentication method of the RADIUS server. You can specify either PAP
(Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol). The
default is PAP.
•
IP Address: The IP address of the RADIUS server that is used for authentication.
•
UDP Port: The destination port on the RADIUS server. The default is port 1812.
•
Shared Secret: Enter the shared secret that the Infoblox device and the RADIUS server use to
encrypt and decrypt their messages. This shared secret is a value that is known only to the Infoblox
device and the RADIUS server.
— Accounting
NIOS 4.1r3
•
Enable Accounting: Select this check box to enable the accounting feature, so you can track an
administrator’s activities during a session.
•
IP Address: The IP address of the RADIUS server that is used for accounting. The default is the IP
address of the authentication RADIUS server.
•
UDP Port: The destination port on the RADIUS server. The default is port 1813.
•
Shared Secret: Enter the shared secret that the device and the RADIUS server use to encrypt and
decrypt their accounting messages. A shared secret is a value that is known only to the device and
the RADIUS server.
Infoblox Administrator Guide (Rev. A)
59
Managing Administrators
— Use MGMT port: If you clear the Use MGMT port check box in the General RADIUS Properties editor and
select this check box, the Infoblox device uses the MGMT port for administrator authentication
communications with just this RADIUS server.
If you select the Use MGMT port check box in the General RADIUS Properties editor, this check box becomes
irrelevant. Whether you select or clear it, the Infoblox device always uses the MGMT port for
communications with all RADIUS servers, including this one.
— Disable this server: Select this check box to disable a RADIUS server if, for example, the connection to the
server is down and you want to stop the Infoblox device from trying to connect to this server.
3. Click the Save icon to save your changes.
Testing the RADIUS Server
After you add a RADIUS server to the Infoblox device, you can validate the configuration. The device uses a
pre-defined user name and password when it tests the connection to the RADIUS server. The pre-defined user name
is “infoblox_test_user” and the password is “infoblox_test_password”. Do not use these as your administrator user
name and password.
To test the configuration
1. From the Administrators perspective, click + (for Remote Admins) -> + (for RADIUS Servers) -> RADIUS_server ->
Edit -> RADIUS Server Properties.
2. In the RADIUS Server Properties editor, click Test Configuration.
If the Infoblox device connects to the RADIUS server using the configuration you entered, it displays a message
confirming the configuration is valid. If it is unable to connect to the RADIUS server, the device displays a
message indicating an error in the configuration.
Maintaining the RADIUS Server List
When you add multiple RADIUS servers, the device lists the servers in the order in which you added them. This list
also determines the order in which the Infoblox device attempts to contact a RADIUS server. You can change the order
of the list, as follows:
1. From the Administrators perspective, click + (for Remote Admins) -> RADIUS Servers -> Edit -> General RADIUS
Properties.
2. The RADIUS Server Group table lists the RADIUS servers. Do the following:
— To move a server up on the list, select it and click Move Up.
— To move a server down on the list, select it and click Move Down.
3. Click the Save icon to save your changes.
Disabling a RADIUS Server
You can disable a RADIUS server if, for example, the connection to the server is down and you want to stop the
Infoblox device from trying to connect to this server. To disable a RADIUS server:
1. From the Administrators perspective, click + (for Remote Admins) -> + (for RADIUS Servers) -> RADIUS_server ->
Edit -> RADIUS Server Properties.
2. Click Disable this server.
3. Click the Save icon to save your changes.
60
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Authentication Using RADIUS
Configuring a RADIUS Server
In addition to setting up the Infoblox device to communicate with a RADIUS server, you must also set up the RADIUS
server to communicate with the Infoblox device.
Note: If you have two Infoblox devices in an HA pair, enter both the members of the HA pair as separate access
devices and use the LAN IP address of both devices (not the VIP address).
For example, to configure an Infoblox RADIUSone device for communication with an Infoblox device:
1. Log in to the RADIUSone device.
2. Click User Management -> RADIUS Global Properties.
3. In the Modify RADIUS Global Properties dialog box, enter the following:
— Authentication Port: Enter the same port number that you set for RADIUS authentication on the Infoblox
device. The default authentication port number is 1812.
— Accounting Port: If you enabled RADIUS accounting on the Infoblox device, enter the same port number that
you set for accounting on the Infoblox device. The default accounting port number is 1813.
4. Click OK to close the Modify RADIUS Global Properties dialog box.
5. Click Device Management -> Add -> Access Device.
6. In the Add Access Device dialog box, enter the following:
— Domain Name/IP Address: Enter or IP address of the LAN interface of the Infoblox device.
— Shared Secret: Enter the same shared secret that you entered on the Infoblox device.
— Re-type Shared Secret: Enter the shared secret again to ensure accuracy.
7. Click OK to close the Add Access Device dialog box.
8. If you want to use remote admin groups on the RADIUSone device, load the Infoblox dictionary file (Importing an
Infoblox Dictionary File on page 63), and then click Device Management -> ip_addr (for the Infoblox device with
which you want the RADIUSone device to communicate) -> Modify -> Vendors Types.
9. In the Vendor List dialog box, select Infoblox from the Vendor drop-down list, and then click Add.
10. Click OK to close the Vendor List dialog box.
11. Click OK to close the Modify Access Device dialog box.
12. Click Publish Changes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
61
Managing Administrators
Remote Admin Groups and Accounts
Infoblox supports admin accounts on one or more RADIUS (Remote Authentication Dial-In User Service) servers.
Remote admin accounts can belong to a remote admin group, whose name must match the name of a local admin
group defined on the Infoblox device. When an admin belonging to a remote admin group logs in, the Infoblox device
applies the privileges and settings specified for the local admin group of the same name.
Note: You can add local admin accounts to a local admin group, and you can create a remote admin group with the
same name and add remote admin accounts to that. When an admin whose account belongs to that group logs
in, the Infoblox device applies the locally defined set of privileges and settings for that group—whether the
account is stored locally or remotely.
If a remote admin account does not belong to a remote admin group (that is, an admin group defined on the RADIUS
server), you must specify a local admin group as a default group (on the Infoblox device). The Infoblox device can then
apply the privileges set for the default group to the remote admin account.
The tasks for defining remote admin accounts on a RADIUS server differ depending on whether you use remote admin
groups. Both sets of tasks are presented below.
Configuring a RADIUS Server for Remote Admin Groups
To set up remote admin accounts and associate them with a remote admin group on a RADIUS server, do the
following:
•
Import Infoblox VSAs (vendor-specific attributes) to the dictionary file on the RADIUS server
•
For third-party RADIUS servers, import the Infoblox vendor file (the Infoblox vendor ID is 7779)
•
Define a local admin group on the Infoblox device (or use an existing group)
•
Define a remote admin group—with the same name as the group defined on the Infoblox device—on the RADIUS
server
•
Associate one or more remote admin accounts on the RADIUS server with the remote admin group
Note: You must also set up the RADIUS server to communicate with the Infoblox device as explained in Configuring
a RADIUS Server on page 61.
62
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Remote Admin Groups and Accounts
Importing an Infoblox Dictionary File
You need to import the Infoblox dictionary file, which contains Infoblox VSAs, to the RADIUS server so that you can
define remote admin groups and associate remote admin accounts with remote admin groups.
1. Download the Infoblox dictionary file from support.infoblox.com, and save it to a local directory.
The Infoblox dictionary file looks like this:
Infoblox Dictionary
-------- ---------VENDORInfoblox7779
BEGIN-VENDORInfoblox
ATTRIBUTEInfoblox-windows-group1string
ATTRIBUTEInfoblox-variable-12string
ATTRIBUTEInfoblox-variable-23string
ATTRIBUTEInfoblox-variable-34string
ATTRIBUTEInfoblox-variable-45string
ATTRIBUTEInfoblox-variable-56string
ATTRIBUTEInfoblox-Version7string
ATTRIBUTEInfoblox-Product-Name8string
ATTRIBUTEInfoblox-Group-Info9string
END-VENDORInfoblox
Note: If you already have a previous Infoblox dictionary file installed on an Infoblox device running RADIUSone 1.4
or later, export the entire set of dictionary files, add lines for attributes #7–9, and then reimport the file.
2. Log in to the RADIUSone device.
3. Click Policy Management -> Import Dictionary.
A new browser window opens.
4. Enter the full path and file name of the dictionary file or browse to its location and select it, and then click Import.
5. Click Publish Changes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
63
Managing Administrators
Creating a Remote Admin Group
You can create an admin group on the RADIUS server when you add a policy group to a policy.
To add a policy to the RADIUSone device:
1. Click Policy Management -> Policies -> Add -> Policy.
2. In the Add Policy dialog box, enter a name in the Policy Name field for the policy that you want to apply to the
Infoblox admin users, and then click OK.
Note: For policy and policy group names, you cannot use blank spaces or any of the following special characters:
@#(),:;<=>?[]^`{|}*+&"~/\%$'
To add a policy group to the RADIUSone device:
Note: You must first add a default policy group before adding the policy group referencing the
infoblox-group-info attribute that you want to apply to the policy. You then give the second policy group a
higher priority value (further from 1) than the default policy group.
1. Click Policy Management -> + (for Policies) -> policy_name -> Add -> policy group.
2. In the Add Policy Group dialog box, enter the following:
— Group Name: Type Default.
— Sort Priority: Enter a low priority number. (The lowest priority number is 1.) The RADIUSone server uses
priority settings to determine the order in which it applies policy groups to a policy.
3. To close the Add Policy Group dialog box, click OK.
4. Click Policy Management -> + (for Policies) -> policy_name -> Add -> policy group.
5. In the Add Policy Group dialog box, enter the following:
— Group Name: Type a name that is meaningful for you.
— Sort Priority: Enter a higher priority number than the one you set for the default policy group. (If the default
policy group priority number is 1, make this number anything greater than 1.)
6. From the Add Policy Group dialog box, click Replies -> Vendor Specific Attributes -> Select Vendor/Attribute -> +
(for Vendors) -> Infoblox, and select infoblox-group-info in the Attribute column.
7. To close the Select Vendor Specific Attribute dialog box, click OK.
In the Vendor Specific Attributes dialog box, you can see “infoblox” in the Vendor field and
“infoblox-group-info” in the Attribute field.
8. In the Vendor Specific Attributes dialog box, type the admin group name in the Value field, and then click Add.
9. To close the Vendor Specific Attributes dialog box, click OK.
10. From the Add Policy Group dialog box, click Conditions -> Attributes.
11. In the Policy Group Condition dialog box, enter the following:
— User-Realm: Choose NULL or a previously defined user realm from the drop-down list. If you specify the
NULL realm, the administrator enters user_name and password during the login. If you specify a specific
realm, the administrator enters user_name@realm_name and password.
12. To close the Policy Group Condition dialog box, click OK.
13. To close the Add Policy Group dialog box, click OK.
To activate the policy:
1. Click Policy Management -> + (for Policies) -> policy_name -> Policy Method.
2. In the Decision Point dialog box, choose the policy name set in step 2 from the Authentication Policy drop-down list.
3. To close the Decision Point dialog box, click OK.
4. Click Publish Changes.
After creating the remote admin group, add one or more admin accounts. (See RADIUSone documentation.)
64
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Changing Password Length Requirements
Configuring a RADIUS Server for Remote Admin Accounts
To set up admin accounts on a RADIUSone server and apply the privileges and properties of the admin group
designated as the default group on the Infoblox device, do the following:
•
Define an admin group on the Infoblox device and specify it as the default group.
1. From the Administrators perspective, click + (for Remote Admins) -> RADIUS Servers -> Edit -> General
RADIUS Properties.
2. In the RADIUS Authentication editor, choose an admin group from the Default Group Name drop-down list.
The Infoblox device then applies the privileges defined for the default admin group to those admin
accounts.
3. Click the Save icon.
•
On the RADIUS server:
— Create one or more admin accounts. (See RADIUSone documentation.)
— Add and activate a policy for the admin accounts, but do not associate the policy with a policy group that
contains an infoblox-group-info attribute.
When an administrator, whose account is stored on a RADIUS server, attempts to log in to an Infoblox device, the
device forwards the user name and password for authentication to the RADIUS server. When the server successfully
authenticates the administrator and it responds to the Infoblox device without specifying an admin group, the device
applies the privileges and properties of the default admin group to that administrator.
Changing Password Length Requirements
Password length requirements control how long a password must be for an Infoblox device admin account. Increasing
this value reduces the likelihood of hackers gaining unauthorized access.
To change password length requirements:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security.
3. Enter a number from 4 to 64 in the Minimum Password Length field.
4. Click the Save icon to save your changes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
65
Managing Administrators
Notifying Administrators
You can notify individual administrators about system status via e-mail, or notify a group of people using an alias
e-mail address. If you have configured DNS resolution on your network, the E-mail relay configuration function is not
required. If you did not configure the settings on the DNS Resolver section, you must enter a static IP address of the
target system in the Relay Name/IP Address field. Use the Test e-mail settings button to test the E-mail settings and
to verify that the recipient received the notification.
You can define the e-mail settings at the grid and member levels.
Grid Level
To notify an administrator of an independent device or a grid:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Email, and then enter the following:
— Enable e-mail notification: Select this check box.
— E-mail address: Enter the e-mail address of the administrator. Use an e-mail alias to notify multiple people.
— Use e-mail relay: Select this check box if the Infoblox device must send e-mail to an intermediary SMTP
(Simple Mail Transfer Protocol) server that relays it to the SMTP server responsible for the domain name
specified in the e-mail address. Some SMTP servers only accept e-mail from certain other SMTP servers and
might not allow e-mail from the Infoblox device. In this case, specify the DNS name or IP address of a
different SMTP server that does accept e-mail from the Infoblox device and that will then relay it to the SMTP
server that can deliver it to its destination.
Clear this check box if it is unnecessary to use an e-mail relay server.
— Relay Name/IP Address: If you have configured DNS resolution, enter the DNS name of the relay server.
If DNS resolution is not configured, enter the IP address of the relay server.
3. Optionally, click Test e-mail settings to confirm this feature is operating properly.
4. Click the Save icon to save your changes.
Member Level
To define e-mail settings for a member, follow the navigational path below and override the grid-level settings. Click
the Save icon to save your changes.
•
66
From the Grid perspective, click Grid -> + (for grid ) -> + (for Members) -> member -> Edit -> Member Properties ->
Email.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 4 Managing Device Operations
Managing the operations of an Infoblox device involves defining system parameters such as time, security and port
settings. It also describes how to set up a static route when the Infoblox device can send and receive traffic through
multiple gateways. The operations covered in this chapter include:
•
•
•
•
•
•
•
•
Managing Time Settings on page 69
— Changing Time and Date Settings on page 69
— Changing Time Zone Settings on page 69
Using NTP for Time Settings on page 70
— Authenticating NTP on page 71
— Infoblox Device as NTP Client on page 73
— Infoblox Device as NTP Server on page 76
Managing Security Operations on page 80
— Enabling Support Access on page 80
— Enabling Remote Console Access on page 80
— Permanently Disabling Remote Console and Support Access on page 81
— Restricting HTTP Access on page 81
— Enabling HTTP Redirection on page 82
— Modifying GUI Session Timeout Settings on page 82
— Disabling the LCD Input Buttons on page 82
— Modifying Security for a Grid Member on page 83
Ethernet Port Usage on page 84
— Modifying Ethernet Port Settings on page 87
Using the MGMT Port on page 88
— Device Management on page 90
— Grid Communications on page 92
— DNS Services on page 95
Setting Static Routes on page 97
Enabling DNS Resolution on page 100
Managing Licenses on page 102
— Viewing the Installed Licenses on an Infoblox Device on page 102
— Obtaining a 60-Day Temporary License on page 102
— Obtaining and Adding a License on page 103
— Removing Licenses on page 103
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
67
Managing Device Operations
•
•
68
Shutting Down, Rebooting, and Resetting an Infoblox Device on page 105
— Rebooting a Device on page 105
— Shutting Down a Device on page 105
— Resetting a Device on page 105
Managing the Disk Subsystem on the Infoblox-2000 on page 107
— About RAID 10 on page 107
— Evaluating the Status of the Disk Subsystem on page 107
— Replacing a Failed Disk Drive on page 108
— Disk Array Guidelines on page 109
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Time Settings
Managing Time Settings
You can define the date and time settings for your Infoblox device when its first starts up, using the Infoblox Appliance
Startup Wizard. You can also set the date and time of the device anytime after you first configure it if you did not do
so using the startup wizard or if you need to change it if, for example, you move a device from a location in one time
zone to a location in a different time zone. To set the date and time of the device, you can either manually enter the
values or configure the device to synchronize its time with a public NTP server.
Changing Time and Date Settings
You can set the date and time on grid members and on independent devices or HA pairs. For devices in a grid, you
can set the date and time at the grid level and at the member level. Grid-level date and time settings apply to all
members unless you override them at the member level.
Note: You cannot manually set the date and time if you have previously enabled NTP service.
To change the time and date for a grid or for an independent device or HA pair:
1. From the Grid or Device perspective, click Grid (or Device) -> Set Date and Time.
2. In the Date and Time dialog box, enter the date (in MM/DD/YYYY format) and time (in HH:MM format) in the
appropriate fields. For PM hours, use the integers 13-24.
3. To close the Date and Time dialog box, click OK.
Note: Changing the date and time resets the application and terminates the management session.
To change the time and date for a grid member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Grid -> Set Date and Time.
2. In the Date and Time dialog box, enter the date (in MM/DD/YYYY format) and time (in HH:MM format) in the
appropriate fields. For PM hours, use the integers 13-24.
3. To close the Date and Time dialog box, click OK.
Note: Changing the date and time resets the application and terminates the management session.
Changing Time Zone Settings
Whether you enable NTP (Network Time Protocol) or manually configure the date and time, you must always set the
time zone manually. For a grid, you can set the time zone at the grid level, which then applies to all members. If
different members are in different time zones, you can choose the time zone that applies to most members at the grid
level, and then override the setting at the member level for the remaining members.
Note: Changing the time zone does not reset the application nor does it terminate the management session.
To change the time and date for a grid or for an independent device or HA pair:
1. From the Grid or Device perspective, click Grid (or Device) -> Set Time Zone.
2. Choose an appropriate time zone from the drop-down list, and then click OK.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
69
Managing Device Operations
To change the time zone for a grid member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Grid -> Set Member Time Zone.
2. In the Member Time Zone dialog box, enter the following:
— Override Grid Time Zone: Select check box.
— Member Time Zone: Choose an appropriate time zone for the location of the selected member.
3. To close the Member Time Zone dialog box, click OK.
Using NTP for Time Settings
NTP (Network Time Protocol) is a standard protocol that system clocks use to ensure their time is always accurate.
Devices that use NTP try to get their time as close as possible to UTC (Coordinated Universal Time), the standard
timescale used worldwide. NTP uses UDP (User Datagram Protocol) on port 123 for communications between clients
and servers.
NTP is based on a hierarchy where reference clocks are at the top. Reference clocks use different methods such as
special receivers or satellite systems to synchronize their time to UTC. NTP servers on the first level of the hierarchy
synchronize their time with the reference clocks, and serve time to clients as well. Each level in the hierarchy is a
stratum; stratum-0 is a reference clock. Stratum-1 servers synchronize their clocks with reference clocks. Stratum-2
servers synchronize their clocks with stratum-1 servers, and so forth. The stratum number indicates the number of
levels between the NTP server and the reference clock. A higher stratum number could indicate more variance
between the NTP server and the reference clock.
You can configure an Infoblox device to function as an NTP client that synchronizes its clock with an NTP server. NTP
clients typically use time information from at least three different sources to ensure reliability and a high degree of
accuracy. There are a number of public NTP servers on the Internet with which the Infoblox device can synchronize its
clock. For a list of these servers, you can access http://www.ntp.org.
An independent device can also function as an NTP server that provides time to client devices. In a grid, the grid
master can function as an NTP client, synchronizing its time with an external NTP server. The grid master then
automatically functions as an NTP server to the grid members. The grid members, in turn, can function as NTP servers
for other devices in the network. This allows you to deploy multiple NTP servers to ensure accurate and reliable time
across the network.
70
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using NTP for Time Settings
Figure 4.1 Infoblox Appliances as NTP Servers
Internet
Stratum-1 NTP Servers use reference
clocks to synchronize their time to
UTC (Coordinated Universal Time).
Reference Clocks
Stratum-1 NTP Servers
As an NTP client, the grid master
synchronizes its time with stratum-1
NTP servers. The grid master also
functions as a stratum-2 NTP server
to grid members. NTP messages
between the grid master and grid
members go through encrypted VPN
tunnels.
As NTP clients, the grid members
synchronize their clocks with the grid
master. The grid members also
function as stratum-3 NTP servers to
external devices on their networks.
Grid Master
Grid
Member
Grid
Member
VPN
Tunnel
2 Network
1 Network
Authenticating NTP
To prevent intruders from interfering with the time services on your network, you can authenticate communications
between an Infoblox device and a public NTP server, and between a device and external NTP clients. NTP
communications within the grid go through an encrypted VPN tunnel, so you do not have to enable authentication
between members in a grid.
NTP uses symmetric key cryptography, where the server and the client use the same algorithm and key to calculate
and verify a MAC (message authentication code). The MAC is a digital thumbprint of the message that the receiver
uses to verify the authenticity of a message.
As shown in Figure 4.2, the NTP client administrator must first obtain the secret key information from the
administrator of the NTP server. The server and the client must have the same key ID and data. Therefore, when you
configure the device as an NTP client and want to use authentication, you must obtain the key information from the
administrator of the external NTP server and enter the information on the device. When you configure an Infoblox
device as an NTP server, you must create a key and send the key information to clients in a secure manner. A key
consists of the following:
•
Key Number: A positive integer that identifies the key.
•
Key Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication code)
of a message.
— M: The key is a 1-31 character ASCII string using MD5 (Message Digest).
— S: The key is a 64-bit hexadecimal number in DES (Data Encryption Standard) format. The high order 7 bits
of each octet form the 56-bit key, and the low order bit of each octet is given a value so that the octet
maintains odd parity. You must specify leading zeros so the key is exactly 16 hexadecimal digits long and
maintains odd parity.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
71
Managing Device Operations
— A: The key is a DES key written as a 1-8 character ASCII string.
— N: The key is a 64-bit hexadecimal number in NTP format. It is the same as the S format, but the bits in each
octet have been rotated one bit right so the parity bit is in the high order bit of the octet. You must specify
leading zeros and odd parity must be maintained.
•
Key String: The key data used to calculate the MAC. The format depends on the Key Type you select.
When the NTP client initiates a request for time services to the NTP server, it creates the MAC by using the agreed
upon algorithm to compress the message and then encrypts the compressed message (which is also called a
message digest) with the secret key. The client appends the MAC to the message it sends to the NTP server. When the
NTP server receives the message from the client, it performs the same procedure on the message — it compresses
the message it received, encrypts it with the secret key and generates the MAC. It then compares the MAC it created
with the MAC it received. If they match, the server continues to process and respond to the message. If the MACs do
not match, the receiver drops the message.
Figure 4.2 NTP Client Administrator Obtaining Secret Key from NTP Server Administrator
NTP Client
Administrator
NTP Server Secret Key
Administrator Information
NTP Client
NTP server administrator sends the secret key
information to the NTP client administrator, who
adds the key to the NTP client.
Message
When the NTP client sends a request for time
services to the NTP server, it uses the agreed
upon algorithm and secret key to create the MAC
(message authorization code). It then sends the
MAC and message to the NTP server.
MAC
MD5 or DES
Message Digest
MAC
MD5 or DES
Message Digest
Message
+
MAC
Encrypted with
Secret Key
NTP server uses the agreed upon
algorithm and secret key to create the
MAC. It compares this MAC with the MAC
it received. If they match, the server
responds to the request of the client for
time services. If the MACs do not match,
the server ignores the message from the
client.
Encrypted with
Secret Key
72
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using NTP for Time Settings
Infoblox Device as NTP Client
You can configure an independent device or the grid master in a grid as an NTP client that synchronizes its system
clock time with an external NTP server.
When you enable an Infoblox device to function as an NTP client, you must specify at least one NTP server with which
the device can synchronize its clock. If you specify multiple NTP servers, you should specify servers that synchronize
their time with different reference clocks and that have different network paths. This increases stability and reduces
risk in case a server fails. For a list of public NTP servers, you can access www.ntp.org.
When you specify multiple NTP servers, the NTP daemon on the device determines the best source of time by
calculating round-trip time, network delay, and other factors that affect the accuracy of the time. NTP periodically
polls the servers and adjusts the time on the device until it matches the best source of time. If the difference between
the device and the server is less than five minutes, the device adjusts the time gradually until the clock time matches
the NTP server. If the difference in time is more than five minutes, the device immediately synchronizes its time to
match that of the NTP server.
To secure communications between an Infoblox device and an NTP server, you can authenticate communications
between the device and the server. When you configure authentication, you must obtain the key information from the
administrator of the NTP server and enter the key on the device. For more information, see Authenticating NTP on
page 71.
For appliances in a grid, only the grid master can synchronize its clock with an external NTP server. When you enable
NTP on the grid master in a grid, the grid master automatically functions as an NTP server to the grid members. A grid
member can synchronize its time only with the grid master, and not with an external NTP server or another grid
member. Like all other grid communications, the grid master and its members send NTP messages through an
encrypted VPN tunnel.
Figure 4.3 Grid Master as NTP Client
NTP Server 1
NTP Server 2
NTP Server 3
Secret Keys
The grid master uses three public NTP
servers to calibrate its clock to the correct
time. It uses symmetric key cryptography to
authenticate NTP messages.
Internet
The grid master serves time to the grid
members. All NTP communications with
the grid go through encrypted VPN tunnels.
Grid Master
VPN Tunnels
Grid Member
NIOS 4.1r3
Grid Member
Infoblox Administrator Guide (Rev. A)
73
Managing Device Operations
Following are the tasks to configure an independent device or a grid master as an NTP client:
•
Enable NTP
•
Specify one or more NTP servers
•
Optionally, enable authentication between the device and the NTP server. For more information, see
Authenticating NTP Clients on page 76.
Configuring an Infoblox Device as an NTP Client
In a grid, the grid master communicates directly with an external NTP server from which it receives its date and time.
The master then forwards the date and time to the other grid members. Likewise, in an independent HA pair, the
active node communicates directly with an external NTP server. The passive node then synchronizes its clock with the
active node.
To configure a grid master or independent device or HA pair to synchronize its time with an external NTP server:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent device or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service
Properties.
2. In the NTP Properties editor, select Enable NTP.
3. To define external NTP servers, click Add, enter the following information, and then click OK.
— NTP Server Address: Type the IP address of an NTP server. You can see a list of NTP servers at ntp.isc.org.
— Enable Authentication: Select the check box to enable authentication of NTP communications between the
external NTP server and the Infoblox device (grid master, active node in an independent HA pair, or single
independent device).
Note: To prevent intruders from interfering with the time services on your network, you can authenticate
communications between a grid master and external NTP servers, and between grid members and
external NTP clients. NTP communications within the grid go through an encrypted VPN tunnel, so you do
not have to enable authentication between grid master and members.
— Authentication Key: Enter the authentication key string, which you have previously obtained from the
administrator of the NTP server.
or
Select Key: Click to open the Select NTP Authentication Key dialog box, select a key that you previously
entered in the NTP Authentication Keys section (see below), and then click OK.
4. Click the Save icon to save your changes.
5. Click the Restart Services icon if it flashes.
Entering an NTP Authentication Key
To add an NTP authentication key:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent device or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service
Properties.
2. In the NTP Properties editor, select Enable NTP.
3. To enter a new key, click Add, enter the following information, and then click OK.
— Number: A positive integer that identifies a key.
— Key Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication
code) of a message.
— MD5 in ASCII format (M): The key is a 1-31 character ASCII string using MD5 (Message Digest).
74
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using NTP for Time Settings
— DES in hex format (S): The key is a 64-bit hexadecimal number in DES (Data Encryption Standard)
format. The high order 7 bits of each octet form the 56-bit key, and the low order bit of each octet is
given a value so that the octet maintains odd parity. You must specify leading zeros so the key is
exactly 16 hexadecimal digits long and maintains odd parity.
— DES in ASCII format (A): The key is a DES key written as a 1-8 character ASCII string.
— DES in NTP format (N): The key is a 64-bit hexadecimal number in NTP format. It is the same as the S
format, but the bits in each octet have been rotated one bit right so the parity bit is in the high order bit
of the octet. You must specify leading zeros and odd parity must be maintained.
— String: The key data used to calculate the MAC. The format depends on the Key Type you select.
4. Click OK to close the Add NTP server dialog box.
Note that if you entered a new key, the device checks if the key already exists in the key list. If the key does exist,
but either the key type or key string does not match, the device sends an error message.
5. Click the Save icon to save your changes.
6. Click the Restart Services icon if it flashes.
Managing Keys
After you enter an authentication key, you can modify or delete it. Note that you cannot delete a key that is an NTP
server references. You must first delete all NTP servers that reference that key and then delete the key.
To delete a key from the list:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent device or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service
Properties.
2. In the NTP Properties editor, select the key you want to delete from the NTP Authentication Keys list, and then
click Delete.
3. Click the Save icon to save your changes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
75
Managing Device Operations
Infoblox Device as NTP Server
After you enable NTP on a grid, the grid members—including the grid master—can function as NTP servers to clients
in different segments of the network. Similarly, after you enable NTP on an independent device or HA pair and it
synchronizes its time with an NTP server, you can configure it to function as an NTP server as well.
Access Control
The NTP access control list limits which clients can use an Infoblox device functioning as an NTP server. If you do not
use the access control list, then any client that has access to the device can use it as an NTP server. If you enter one
or more IP addresses, then only the clients you specify can access NTP services from that device.
To restrict access for a grid or for an independent device or HA pair:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent device or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service
Properties.
2. Click Add (for NTP Access Control), enter the following information, and then click OK.
— IP Address Option
— Address: To allow a client from a single IP address to access grid members functioning as NTP servers,
select this option and enter the IP address in Address field.
— or
— Network: To restrict access to grid members functioning as NTP servers to a subnet, select this option
and enter the network address in the Address field and choose an appropriate netmask from the
drop-down list.
— or
— Any: Select this option to allow access to grid members functioning as NTP servers from any address. If
you do not make any access restrictions, the grid members allow access from any address.
3. If necessary, click Move up and Move down to reorder the IP addresses in the list. When a device requests NTP
information from the Infoblox device, it tries to match the client’s IP address with IP addresses in the list,
beginning at the top of the list and continuing downward until it finds a match. If there is at least one item in the
NTP Access Control list and a client’s IP address does not match it, the Infoblox device ignores its NTP requests.
4. Click the Save icon to save your changes.
Authenticating NTP Clients
You can enable authentication between an Infoblox device functioning as an NTP server and its NTP clients. When you
enable authentication, you must specify the keys that the device and its clients must use for authentication. In a grid,
you can enter NTP authentication keys at the grid level so that all the members can use them to authenticate their
clients. You can also enter keys at the member level, if you want that member to use different keys from those set at
the grid level. After you enter the keys, you can download the key file and distribute the file to the NTP clients.
To authenticate NTP traffic between an Infoblox device and NTP clients:
1. Define one or more keys at the grid or member level, or for an independent device or HA pair.
2. Distribute the key to the NTP clients.
To add a new key for a grid or for an independent device or HA pair:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent device or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service
Properties.
76
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using NTP for Time Settings
2. Click Add (for NTP Authentication Keys), enter the following information, and then click OK.
— Number: A positive integer that identifies a key.
— Key Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication
code) of a message.
— MD5 in ASCII format (M): The key is a 1-31 character ASCII string using MD5 (Message Digest).
— DES in hex format (S): The key is a 64-bit hexadecimal number in DES (Data Encryption Standard)
format. The high order 7 bits of each octet form the 56-bit key, and the low order bit of each octet is
given a value so that the octet maintains odd parity. You must specify leading zeros so the key is
exactly 16 hexadecimal digits long and maintains odd parity.
— DES in ASCII format (A): The key is a DES key written as a 1-8 character ASCII string.
— DES in NTP format (N): The key is a 64-bit hexadecimal number in NTP format. It is the same as the S
format, but the bits in each octet have been rotated one bit right so the parity bit is in the high order bit
of the octet. You must specify leading zeros and odd parity must be maintained.
— String: The key data used to calculate the MAC. The format depends on the Key Type you select.
3. Click the Save icon to save your changes.
You can download the key file, which is usually called ntp.keys, and distribute the file to the NTP clients. To download
a key file at the grid or independent device level:
To copy an NTP authentication key for distribution to NTP clients:
1. For a grid: From the Grid perspective, click + (for grid ) -> + (for Services ) -> NTP -> Edit -> Service Properties.
or
For an independent device or HA pair: From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service
Properties.
2. Choose the key in the NTP Authentication Keys list, and then click Modify.
3. Note the key number and type, and select the contents of the String field.
4. Paste the key string in a text file and include the key number and type (M, S, A, or N) in the file.
5. Distribute this to the NTP clients using a secure transport.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
77
Managing Device Operations
Figure 4.4 Grid Members as NTP Servers
NTP Server 1
NTP Server 2
NTP Server 3
Secret Keys
The grid master uses three public NTP
servers to calibrate its clock to the
correct time. It uses symmetric key
cryptography to secure NTP messages.
Internet
The grid master serves time to the grid
members. All NTP communications
with the grid go through the encrypted
VPN tunnels.
The grid members serve time to devices on their
networks. Each member uses symmetric key
encryption to secure NTP messages. Each
member also has an access control list that
defines which devices can access the time
services. When a client that is not on the list tries
to access a device functioning as an NTP
server, the device ignores the message.
Grid Master
Access Control List
Grid Member
VPN
Tunnels
3 Network
Grid Member
X
2 Network
Configuring an Infoblox Device as an NTP Server
You can configure a grid member—including the grid master—or an independent device or HA pair to function as an
NTP server.
To configure a grid member to be an NTP server:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> + (for member ) -> NTP -> Edit -> Service Properties.
2. In the Member NTP Properties editor, select the Override Grid NTP authentication setting check box to enter NTP
authentication keys at the member level instead of using grid-level keys. The member uses these keys when
acting as an NTP server and authenticates requests from NTP clients. Clear the check box to use the grid-level
authentication keys.
3. Click Add (for NTP Authentication Keys), enter the following information, and then click OK.
— Number: A positive integer that identifies the key.
— Key Type: Specifies the key format and the algorithm used to calculate the MAC (message authentication
code) of a message.
— MD5 in ASCII format (M): The key is a 1-31 character ASCII string using MD5 (Message Digest).
— DES in hex format (S): The key is a 64-bit hexadecimal number in DES (Data Encryption Standard)
format. The high order 7 bits of each octet form the 56-bit key, and the low order bit of each octet is
given a value so that the octet maintains odd parity. You must specify leading zeros so the key is
exactly 16 hexadecimal digits long and maintains odd parity.
— DES in ASCII format (A): The key is a DES key written as a 1-8 character ASCII string.
78
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using NTP for Time Settings
— DES in NTP format (N): The key is a 64-bit hexadecimal number in NTP format. It is the same as the S
format, but the bits in each octet have been rotated one bit right so the parity bit is in the high order bit
of the octet. You must specify leading zeros and odd parity must be maintained.
— String: The key data used to calculate the MAC. The format depends on the Key Type you select.
4. Click the Save icon to save your changes.
To configure an independent device or HA pair to be an NTP server:
1. From the Device perspective, click + (for hostname ) -> NTP -> Edit -> Service Properties.
2. In the Device NTP Properties editor, enter the following:
— Enable external NTP: Select the check box and configure external NTP servers. Before a device or HA pair
can be an NTP server, it must first be an NTP client. For more information, see Infoblox Device as NTP Client
on page 73.
— Enable this member as an NTP server: Select the check box.
Note: You can also configure the Infoblox device to control access to the NTP server and authenticate NTP
clients’ requests. See Access Control on page 76 and Authenticating NTP Clients on page 76.
3. Click the Save icon to save your changes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
79
Managing Device Operations
Managing Security Operations
The procedures in this section apply to both independent and grid installations.
You can specify these security operations:
•
•
•
•
•
•
•
•
Enabling Support Access on page 80
Enabling Remote Console Access on page 80
Permanently Disabling Remote Console and Support Access on page 81
Restricting HTTP Access on page 81
Enabling HTTP Redirection on page 82
Modifying GUI Session Timeout Settings on page 82
Disabling the LCD Input Buttons on page 82
Modifying Security for a Grid Member on page 83
Enabling Support Access
Infoblox Technical Support might need access to your Infoblox device to troubleshoot problems. This function
enables an SSH (Secure Shell) daemon that only Infoblox Technical Support can access. If you have any questions,
contact Infoblox Technical Support at [email protected]. By default, this option is disabled.
To enable Infoblox Technical Support access:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security, and then select Enable Support access.
3. Click the Save icon.
Note: When configuring grid members, you can selectively override the grid-level Support access setting at the
member level.
Enabling Remote Console Access
This function makes it possible for a superuser admin to access the Infoblox CLI from a remote location using an SSH
(Secure Shell) v2 client. The management system must have an SSH v2 client to use this function. After opening a
remote console connection using an SSH client, log in using a superuser name and password. By default, this option
is disabled.
To enable remote console access:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security, and then select Enable remote console access.
3. Click the Save icon.
Note: When configuring grid members, you can selectively override the grid-level remote console access setting at
the member level.
80
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Security Operations
Permanently Disabling Remote Console and Support Access
You can permanently disable remote console (Secure Shell v2) access for device administration and for Infoblox
Technical Support to perform remote troubleshooting. Disabling this type of access might be required in a
high-security environment.
WARNING: After permanently disabling remote console and support access, you cannot re-enable them! Not
even resetting a device to its factory default settings can re-enable them.
To permanently disable remote console access and Infoblox Technical Support access:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security, and then select Permanently disable remote console and support
access.
3. Click the Save icon.
Restricting HTTP Access
You can specify the IP addresses from which administrators are allowed to access the Infoblox device. When the
Infoblox device receives a connection request, it tries to match the source IP address in the request with IP addresses
in the list. If there is at least one item in the HTTP Access Control list and the source IP address in the request does
not match it, the Infoblox device ignores the request.
Caution: If you specify an address or network other than the one from which you are currently accessing the device,
when you save your configuration, you will lose your administrative session and be unable to reconnect.
To restrict HTTP access to the Infoblox GUI to select addresses:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. To set restrictions on the IP addresses from which administrators can access the Infoblox device, select Enable
HTTP access restrictions in the Security section, click Add, enter the following, and then click OK:
— Address Type:
— Address: To allow administrative access to the GUI from a single IP address, select this option and enter
the IP address in the Address field. Note that if you specify an address other than the one from which
you are currently accessing the device, when you save your configuration, you will lose your
administrative session and be unable to reconnect.
— Network: To restrict administrative access to the GUI to a subnet, select this option and enter the
network address in the Address field and choose an appropriate netmask from the drop-down list. Note
that if you specify a subnet other than the one from which you are currently accessing the device, when
you save your configuration, you will lose your administrative session and be unable to reconnect.
3. Click the Save icon to save your changes.
The application restarts and your management session terminates.
4. From the JWS (Java Web Start) login prompt, log back in to the device.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
81
Managing Device Operations
Enabling HTTP Redirection
You can enable the Infoblox device to redirect administrative connection requests using HTTP to the secure HTTPS
protocol. When you disable redirection, the Infoblox device ignores any administrative connection requests not using
HTTPS. By default, the Infoblox device does not redirect HTTP connection requests to HTTPS.
To enable redirection:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security, and then select Auto-Redirect HTTP -> HTTPS.
3. Click the Save icon to save your changes.
The application restarts and your management session terminates.
4. From the JWS (Java Web Start) login prompt, log back in to the device.
Modifying GUI Session Timeout Settings
You can set the length of idle time before an administrative session to the Infoblox GUI times out. The default timeout
value is 600 seconds (10 minutes).
Note: If you change Session Timeout settings, you must close your browser window and log back in.
To modify session timeout settings:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security, and then enter a number between 60 and 31536000 seconds (one
minute – one year) in the Session Timeout field. The default session timeout is 600 seconds (10 minutes).
3. Click the Save icon to save your changes.
The application restarts and your management session terminates.
4. From the JWS (Java Web Start) login prompt, log back in to the device.
Disabling the LCD Input Buttons
By default, the LCD input function is enabled, which allows you to use the LCD buttons on the front panel of an
Infoblox device to change the IP address settings of the LAN port. You can disable this function if the device is in a
location where you cannot restrict access exclusively to Infoblox device administrators and you do not want anyone
to be able to make changes through the LCD.
To disable LCD input to the device:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Security, and then clear Enable LCD input.
3. Click the Save icon to save your changes.
82
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Security Operations
Modifying Security for a Grid Member
You can override a number of grid-level security settings at the member level.
Note: You can only manage session timeout settings, HTTPS redirection, HTTP access, audit log rolling, password
length, and login banner text at the grid level.
To enable support access for a member:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Member Properties.
2. In the Grid (or Device) editor, click Security, and then enter the following:
— To override grid-level settings for remote console access, select the Override grid remote console access
setting check box, and then select or clear the Remote console access enabled check box.
— To override grid-level settings for Infoblox Technical Support access, select the Override grid support access
setting check box, and then select or clear the Enable support access check box.
— To override grid-level LCD input settings, select the Override grid support LCD input setting check box, and
then select or clear the Enable LCD input check box.
3. Click the Save icon to save your changes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
83
Managing Device Operations
Ethernet Port Usage
The three ethernet ports on an Infoblox device perform different functions, which vary depending on deployment and
configuration choices. The three ethernet ports that transmit and receive traffic to the Infoblox device are as follows:
•
LAN port – This is the default port for single independent appliances, single grid members, and passive nodes
in HA pairs. All deployments use the LAN port for management services if the MGMT port is disabled. On
Infoblox-500, -1000, and -1200 appliances, this port is labeled LAN. On Infoblox-550, -1050, -1550, and -1552
appliances, it is labeled LAN1. (The LAN2 port is reserved for future use.)
•
HA port – This is the default port for the active grid master node and the active node in an independent HA pair.
•
MGMT port – If the MGMT port is enabled, the Infoblox device uses it for many types of management services
(see Table 4.2 on page 85 for specific types).
Table 4.1 displays the type of traffic per port for both grid and independent deployments. For a more detailed list of
the different types of traffic, see Table 4.2 on page 85.
Table 4.1 Device Roles and Configuration, Communication Types, and Port Usage
HA Pair
HA Status
MGMT Port
Database
Synchronization
Network
Identity
Services
Management
Services
GUI
Access
HA Grid Master
Yes
Active
Disabled
VIP on HA
VIP on HA
LAN
VIP on HA
HA Grid Master
Yes
Passive
Disabled
LAN
–
LAN
–
Single Grid Master
No
–
Disabled
LAN
LAN
LAN
LAN
HA Grid Member
Yes
Active
Disabled
LAN
VIP on HA
LAN
–
HA Grid Member
Yes
Passive
Disabled
LAN
–
LAN
–
Single Grid Member
No
–
Disabled
LAN
LAN
LAN
–
Independent HA Pair
Yes
Active
Disabled
VIP on HA
VIP on HA
LAN
VIP on HA
Independent HA Pair
Yes
Passive
Disabled
LAN
–
LAN
–
Single Independent
No
–
Disabled
–
LAN
LAN
LAN
HA Grid Master
Yes
Active
Enabled
VIP on HA
VIP on HA
MGMT
MGMT
HA Grid Master
Yes
Passive
Enabled
LAN
–
MGMT
–
Single Grid Master
No
–
Enabled
LAN
LAN or MGMT
MGMT
MGMT
HA Grid Member
Yes
Active
Enabled
LAN or MGMT
VIP on HA
MGMT
–
HA Grid Member
Yes
Passive
Enabled
LAN or MGMT
–
MGMT
–
Single Grid Member
No
–
Enabled
LAN or MGMT
LAN or MGMT
MGMT
–
Independent HA Pair
Yes
Active
Enabled
VIP on HA
VIP on HA
MGMT
MGMT
Independent HA Pair
Yes
Passive
Enabled
LAN
–
MGMT
–
Single Independent
No
–
Enabled
–
LAN or MGMT
MGMT
MGMT
Device Role
To see the service port numbers and the source and destination locations for traffic that can go to and from an
Infoblox device, see Table 4.2. This information is particularly useful for firewall administrators so that they can set
policies to allow traffic to pass through the firewall as required.
Note: The colors in both tables represent a particular type of traffic and correlate with each other.
84
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Ethernet Port Usage
Table 4.2 Sources and Destinations for Services
Service
SRC IP
DST IP
Proto
SRC
Port
DST
Port
Key
Exchange
LAN on grid
member
VIP on HA grid
master, or LAN or
single master
17 UDP
2114
2114
VIP on HA grid
master, or LAN or
single master
17 UDP
VPN
LAN on grid
member
Notes
Initial key exchange for
establishing VPN tunnels
Required for Keystone
1194 or
5002,
or 1024
->
63999
1194 or
5002,
or 1024
->
63999
Default VPN port 1194 for
grids with new DNSone 3.2
installations and 5002 for
grids upgraded to DNSone
3.2; the port number is
configurable
Required for Keystone
DHCP
Client
LAN, VIP, or
broadcast on
Infoblox device
17 UDP
68
67
Required for DHCP service
DHCP
LAN or VIP on
Infoblox device
Client
17 UDP
67
68
Required for DHCP service
DHCP
Failover
LAN or VIP on
Infoblox DHCP
failover peer
LAN or VIP on
Infoblox DHCP
failover peer
6 TCP
519
519
Required for DHCP failover
DHCP
Failover
VIP on HA grid
master or LAN on
single master
LAN or VIP on
grid member in a
DHCP failover
pair
6 TCP
1024 ->
65535
7911
Informs functioning grid
member in a DHCP failover
pair that its partner is down
Required for DHCP failover
DDNS
Updates
LAN or VIP
LAN or VIP
17 UDP
1024 ->
65535
53
Required for DHCP to send
DNS dynamic updates
DNS
Transfers
LAN, VIP, or
MGMT, or client
LAN, VIP, or
MGMT
6 TCP
53, or
1024 ->
65535
53
For DNS zone transfers, large
client queries, and for grid
members to communicate
with external name servers
Required for DNS
DNS
Queries
Client
NTP
RADIUS
Authentication
NIOS 4.1r3
LAN, VIP, or
broadcast on
Infoblox device
17 UDP
53, or
1024 ->
65535
53
NTP client
VIP or LAN
NAS (network
access server)
LAN or VIP
For DNS queries
6 TCP
1024 ->
65535
123
Required if the Infoblox
device is an NTP server
17 UDP
1024 –
65535
1812
For proxying RADIUS
Authentication-Requests.
The default destination port
number is 1812, and can be
changed to 1024 – 63997.
Required for DNS
Infoblox Administrator Guide (Rev. A)
85
Managing Device Operations
SRC
Port
DST
Port
17 UDP
1024 –
65535
1813
For proxying RADIUS
Accounting-Requests. The
default destination port
number is 1813, and can be
changed to 1024 – 63998.
RADIUS home
server
17 UDP
1814
1024 ->
63997
(auth),
or 1024
->
63998
(acct)
Required to proxy requests
from RADIUS clients to
servers. The default source
port number is 1814, and
although it is not
configurable, it is always two
greater than the port number
for RADIUS authentication.
VIP, LAN, or
MGMT, or
UNIX-based
client
LAN or UNIXbased client
1 ICMP
Type 3
–
–
Required to respond to the
UNIX-based traceroute tool
to determine if a destination
has been reached
ICMP Echo
Reply
VIP, LAN, or
MGMT, or client
VIP, LAN, or
MGMT, or client
1 ICMP
Type 0
–
–
Required for response from
ICMP echo request (ping)
ICMP Echo
Request
VIP, LAN, or
MGMT, or client
VIP, LAN, or
MGMT, or client
1 ICMP
Type 8
–
–
Required to send pings and
respond to the Windowsbased traceroute tool
ICMP TTL
Exceeded
Gateway device
(router or
firewall)
Windows client
1 ICMP
Type 11
–
–
Gateway sends an ICMP TTL
exceeded message to a
Windows client, which then
records router hops along a
data path
NTP
LAN on active
node of grid
master or LAN of
independent
device
NTP server
6 TCP
1024 ->
65535
123
Required to synchronize
Keystone, TSIG authentication, and DHCP failover
SMTP
LAN or VIP
Mail server
6 TCP
1024 ->
65535
25
Required if SMTP alerts are
enabled
SNMP
NMS (network
management
system) server
VIP, LAN, or
MGMT
17 UDP
1024 ->
65535
161
Required for SNMP
management
SNMP Traps
VIP on grid
master or HA
pair, LAN or
MGMT of
independent
device
NMS server
17 UDP
1024 ->
65535
162
Required for SNMP trap
management
Service
SRC IP
DST IP
Proto
RADIUS
Accounting
NAS (network
access server)
LAN or VIP
RADIUS
Proxy
LAN or VIP
ICMP Dst
Port
Unreachable
86
Notes
Optional for synchronizing
logs among multiple devices
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Ethernet Port Usage
Service
SRC IP
DST IP
Proto
SSHv2
Client
LAN, VIP, or
MGMT on
Infoblox device
6 TCP
SRC
Port
DST
Port
1024 ->
65535
22
Notes
Administrators can make an
SSHv2 connection to the
LAN, VIP, or MGMT port
Optional for management
Syslog
LAN or MGMT of
Infoblox device
syslog server
17 UDP
1024 ->
65535
514
Required for remote syslog
logging
Traceroute
LAN or UNIXbased device
VIP, LAN, or
MGMT, or client
17 UDP
1024 ->
65535
33000
->
65535
Infoblox device responds
with ICMP type code 3 (port
unreachable)
TFTP Data
LAN or MGMT
TFTP server
17 UDP
1024 ->
65535
69,
then
1024 ->
63999
For contacting a TFTP server
during database and
configuration backup and
restore operations
HTTP
Management
System
VIP, LAN, or
MGMT
6 TCP
1024 ->
65535
80
Required if the HTTP-redirect
option is set on the grid
properties security page
HTTPS/
SSL
Management
System
VIP, LAN, or
MGMT
6 TCP
1024 ->
65535
443
Required for administration
through the GUI
Modifying Ethernet Port Settings
By default, the Infoblox device automatically negotiates the optimal connection speed and transmission type (full or
half duplex) on the physical links between the 10/100Base-T and 10/100/1000Base-T ports on the Infoblox device
and the ethernet ports on a connecting switch. It is usually unnecessary to change the default auto-negotiation
setting; however, you can manually configure connection settings for a port if necessary.
Occasionally, for example, even though both the Infoblox device and the connecting switch support 1000-Mbps
(megabits per second) full-duplex connections, they might fail to auto-negotiate that speed and type, and instead
connect at lower speeds of either 100 or 10 Mbps using potentially mismatched full- and half-duplex transmissions.
If this occurs, first determine if there is a firmware upgrade available for the switch. If so, apply the firmware upgrade
and test the connection. If that does not resolve the issue, manually set the ports on the Infoblox device and on the
switch to make 1000-Mbps full-duplex connections.
To change ethernet port settings:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Member Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
Note: You must enable the MGMT port before modifying its port settings. See Using the MGMT Port on page 88.
2. In the Grid Member or Device editor, click LAN/HA Ports or MGMT Port, and then enter the following:
— Use Automatic [ LAN | HA | MGMT ] Port Settings: Clear check box.
— [ LAN | HA | MGMT ] Speed: Choose the connection speed that you want the port to use.
— [ LAN | HA | MGMT ] Duplex: Choose Full for concurrent bidirectional data transmission or Half for data
transmission in one direction at a time.
3. Click the Save icon to save your changes.
Note: The port settings on the connecting switch must be identical to those you set on the Infoblox device.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
87
Managing Device Operations
Using the MGMT Port
The MGMT (Management) port is a 10/100Base-T ethernet connector on the front panel of an Infoblox-500, -1000,
and -1200 appliance and a 10/100/1000Base-T ethernet connector on the front panel of an Infoblox-550, -1050,
-1550, and -1552 appliance. It allows you to isolate the following types of traffic from other types of traffic on the LAN
and HA ports:
•
•
•
Device Management on page 90
Grid Communications on page 92
DNS Services on page 95
For information about what types of traffic qualify as device management, grid communications, and DNS services,
see Table 4.2 on page 85.
Note: The MGMT port currently does not support DHCP, NTP, NAT, RADIUS proxying, or TFTP.
Some Infoblox device deployment scenarios support more than one concurrent use of the MGMT port. The following
table depicts MGMT port uses for various device configurations.
Table 4.3 Supported MGMT Port Uses for Various Device Configurations
Device
Configuration
Device
Management
Grid
Communications
Single Independent Device
Not Applicable
Independent HA Pair
Not Applicable
DNS
Services
Grid Master
Grid Master Candidate
HA Grid Member
*
Single Grid Member
*
* Although you manage all grid members through the grid master, if you enable the MGMT port on common grid
members, they can send syslog events, SNMP traps, and e-mail notifications, and receive SSH connections on that
port.
Infoblox does not support MGMT port usage for some device configurations (indicated by the symbol in Table 4.3)
because it cannot provide redundancy through the use of a VIP. A grid master that is an HA pair needs the redundancy
that a VIP interface on the HA port provides for grid communications. Similarly, DNS servers in an HA pair need that
redundancy to answer DNS queries. Because the MGMT port does not support a VIP and thus cannot provide
redundancy, grid masters (and potential grid masters) do not support grid communications on the MGMT port.
In addition, Infoblox devices in an HA pair do not support DNS services on the MGMT port for some HA pair
configurations (indicated by the symbol in Table 4.3). Specifically, the MGMT port supports DNS services when the
device is part of an HA pair, if the IP address resolved is the active address of the HA pair. The MGMT port does not
support DNS services if the IP address resolved is the passive address of the HA pair.
>Because of this unpredictable behavior, we want to issue a note stating that DNS is supported on the MGMT port for
non-HA configurations. And perhaps to qualify this by saying that users may see DNS services on the port if certain
conditions are reached (as explained in your email).
88
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using the MGMT Port
The MGMT port is not enabled by default. By default, an Infoblox device uses the LAN port (and HA port when
deployed in an HA pair). You must log in using a superuser account to enable and configure the MGMT port. You can
enable the MGMT port through the Infoblox GUI (as explained in the following sections) or through a console
connection with the following command: set interface mgmt speed auto duplex none
Note: For information about connecting ethernet cables to the MGMT port, refer to Cabling for the MGMT Port on
page 537.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
89
Managing Device Operations
Device Management
You can restrict administrative access to an Infoblox device by connecting the MGMT port to a subnet containing only
management systems. This approach ensures that only devices on that subnet can access the Infoblox GUI and
receive device management communications such as syslog events, SNMP traps, and e-mail notifications from the
device.
If you are the only administrator, you can connect your management system directly to the MGMT port. If there are
several administrators, you can define a small subnet—such as 10.1.1.0/29, which provides six host IP addresses
(10.1.1.1–10.1.1.7) plus the network address 10.1.1.0 and the broadcast address 10.1.1.8—and connect to the
Infoblox device though a dedicated switch; that is, a switch that is not connected to the rest of the network. See
Figure 4.5, which shows how an independent device separates device management traffic from network protocol
services. Note that the LAN port is on a different subnet from the MGMT port.
Figure 4.5 Device Management from One or More Management Systems
A single management system connects
directly to the MGMT port of the Infoblox
device through an ethernet cable.
The Infoblox device serves
DNS and DHCP to the public
network through the LAN port.
Public Network
1.1.1.0/24
DNS and DHCP Services
LAN
1.1.1.5
MGMT
10.1.1.1
Private Network
10.1.1.0/30
Device Management
Ethernet
Cable
Infoblox
Device-1
DNS and DHCP Clients
LAN
1.1.1.6
MGMT
10.1.1.1
Several management systems connect
to the MGMT port of the Infoblox device
through a dedicated switch.
Infoblox
Device -2
Note:
Because the two private networks are
used solely for device management and
are completely isolated from the rest of
the network—and therefore from each
other—their address space can overlap
without causing any routing issues
Ethernet
Cable
Private Network
10.1.1.0/29
Device Management
Dedicated
Switch
Management Systems
10.1.1.2 - 10.1.1.5
Similarly, you can restrict management access to a grid master to only those devices connected to the MGMT ports of
the active and passive nodes of the grid master.
To enable the MGMT port on an independent device or grid master for device management and then cable the MGMT
port directly to your management system or to a network forwarding device such as a switch or router:
1. From the Grid perspective, click + (for grid ) -> + (for Member ) -> grid_master -> Edit -> Member Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
Note: You must enable the MGMT port before modifying its port settings. See Using the MGMT Port on page 88.
90
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using the MGMT Port
2. In the Grid Member or Device editor, click MGMT Port, and then enter the following in Node 1 subsection for a
single grid master or independent device, and in the Node 1 and Node 2 subsections for an HA grid master or
independent HA pair:
— Enable management (MGMT) port: Select check box.
— Enable VPN services on the MGMT port: Clear check box.
— Restrict Support and remote console access to MGMT port: Select the check box to restrict SSH (Secure
Shell) v2 access to the MGMT port only. This restricts Infoblox Technical Support and remote console
connections—both of which use SSH v2—to just the MGMT port. For an HA pair, you can make an SSH v2
connection to the MGMT port on both the active and passive nodes.
Clear the check box to allow SSH v2 access to both the MGMT and LAN ports. For an HA pair, you can make
an SSH v2 connection to the MGMT and LAN ports on both the active and passive nodes.
— IP Address: Type the IP address for the MGMT port, which must be in a different subnet from that of the LAN
and HA ports.
— Subnet Mask: Choose an appropriate subnet mask for the number of management systems that you want
to access the device through the MGMT port.
— Gateway: Type the default gateway for the MGMT port. If you need to define any static routes for traffic
originating from the MGMT port—such as SNMP traps, syslog events, and email notifications—destined for
remote subnets beyond the immediate subnet, specify the IP address of this gateway in the route.
— Use automatic MGMT port settings: Select the check box to instruct the Infoblox device to negotiate the
optimum port connection type (full or half duplex) and speed with the connecting switch automatically. If
you clear the check box, manually configure the same settings on both the Infoblox device and the switch.
By default, the check box is selected.
3. Click the Save icon to save your settings.
4. Close the current JWS (Java Web Start) application window.
5. Cable the MGMT port to your management system or to a switch or router to which your management system can
also connect.
6. If your management system is in a subnet from which it cannot reach the MGMT port, move it to a subnet from
which it can.
The Infoblox Grid (or Device) Manager GUI is now accessible through the MGMT port on the Infoblox device from
your management system.
7. Start a new JWS session, and then log in to the IP address of the MGMT port.
8. Check the Detailed Status and Grid panels to make sure the status icons are green.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
91
Managing Device Operations
Grid Communications
You can isolate all grid communications to a dedicated subnet as follows:
•
For grid communications from the grid master, which can be an HA pair or a single device, the master uses either
the VIP interface on the HA port of its active node (HA master) or its LAN port (single master). Neither a single
nor HA grid master can use its MGMT port for grid communications. (This restriction applies equally to master
candidates.)
•
Common grid members connect to the grid master through their MGMT port.
This ensures that all database synchronization and grid maintenance operations are inaccessible from other network
elements while the common grid members provide network protocol services on their LAN ports.
Figure 4.6 shows how grid members communicate to the master over a dedicated subnet.
Figure 4.6 Grid Communications
The private network
(10.1.1.0/24) is reserved for
grid communications
between the grid master and
all grid members, and for
device management
between the management
system and the grid master.
HA Grid Master
The grid master and
master candidate
connect to the private
network using a VIP
on their HA ports.
Master Candidate
HA
HA
HA
HA
VIP
10.1.1.5
VIP
10.1.1.10
Private Network
10.1.1.0/24
for Grid Communications
and Device Management
Management
System
10.1.1.30
MGMT
10.1.1.15
Single Member
MGMT
10.1.1.20
Passive
Node
MGMT
10.1.1.21
Active Node
HA Member
HA
HA
LAN
1.1.1.6
Public Network
1.1.1.0/24
DNS and DHCP Services
The common grid
members use the public
network (1.1.1.0/24) for
DNS and DHCP services.
VIP
1.1.1.7
The common grid
members connect to the
private network through
their MGMT ports*.
They connect to the
public network through
their LAN and HA ports
(using a VIP).
DNS and DHCP Clients
* Only the active node of an HA member connects to the grid master. The
passive node communicates just with the active node. If there is an HA failover,
the newly promoted active node must first join the grid before continuing grid
communications with the grid master on behalf of the HA member.
92
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using the MGMT Port
Enabling Grid Communications over the MGMT Port for Existing Grid Members
To enable the MGMT port for grid communications on an existing single or HA grid member:
1. Log in to the grid master with a superuser account.
2. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Member Properties.
3. In the Grid Member editor, click MGMT Port, and then enter the following for Node 1. For an HA member, enter
the IP address, subnet mask, and gateway address for both Node 1 and Node 2.
— Enable management (MGMT) Port: Select the check box.
— Enable VPN services on the MGMT Port: Select the check box.
— Restrict Support and remote console access to MGMT port: Select the check box to restrict SSH (Secure
Shell) v2 access to the MGMT port only. This restricts Infoblox Technical Support and remote console
connections—both of which use SSH v2—to just the MGMT port. For an HA pair, you can make an SSH v2
connection to the MGMT port on both the active and passive nodes.
Clear the check box to allow SSH v2 access to both the MGMT and LAN ports. For an HA pair, you can make
an SSH v2 connection to the MGMT and LAN ports on both the active and passive nodes.
— IP Address: Type the IP address of the MGMT port on the grid member, which must be in a different subnet
from that of the LAN and HA ports.
— Subnet Mask: Choose the subnet mask for the MGMT port IP address.
— Gateway: Type the default gateway for the MGMT port.
— Use automatic MGMT port settings: Select the check box to instruct the Infoblox device to negotiate the
optimum port connection type (full or half duplex) and speed with the connecting switch automatically. If
you clear the check box, manually configure the same settings on both the Infoblox device and the switch.
By default, the check box is selected.
4. In the Grid Member editor, click LAN/HA Ports, and then change the IP address of the LAN port (for a single
member) and LAN and HA ports (for an HA member) if they are in the same subnet as the IP address of the MGMT
port.
5. Click the Save icon to save your settings.
The master communicates the new port settings to the member, which immediately begins using them. The
member stops using its LAN port for grid communications and begins using the MGMT port.
6. To confirm that the member still has grid connectivity, check that the status icons for that member are green on
the Detailed Status and Grid panels.
Enabling Grid Communications over the MGMT Port for New Grid Members
To enable the MGMT port for grid communications on a single device or HA pair and then join it to a grid:
Member MGMT Port Configuration on the Grid Master
1. Log in to the grid master with a superuser account.
2. From the Grid perspective, click grid -> Add Grid Member.
3. In the Grid Member editor, click LAN/HA Ports, configure the network settings for a single member or the
network and HA settings for an HA member, and clear the Master Candidate check box. Any member that is
a master candidate cannot use the MGMT port for grid communications.
4. In the Grid Member editor, click MGMT Port, and then enter the following for Node 1 (for a single device). For
an HA pair, enter the IP address, subnet mask, gateway address, and port settings for both Node 1 and
Node 2.
— Enable management (MGMT) Port: Select the check box.
— Enable VPN services on the MGMT Port: (You must add the member before you can select this check
box, which you do in step 7.)
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
93
Managing Device Operations
— Restrict Support and remote console access to MGMT port: Select the check box to restrict SSH (Secure
Shell) v2 access to the MGMT port only. This restricts Infoblox Technical Support and remote console
connections—both of which use SSH v2—to just the MGMT port. For an HA member, you can make an
SSH v2 connection to the MGMT port on both the active and passive nodes.
Clear the check box to allow SSH v2 access to both the MGMT and LAN ports. For an HA member, you can
make an SSH v2 connection to the MGMT and LAN ports on both the active and passive nodes.
— IP Address: Type the IP address of the MGMT port on the grid member. This is the address that you
previously set when configuring the device. The MGMT port address cannot be in the same subnet as
the addresses of the LAN and HA ports.
— Subnet Mask: Choose the subnet mask for the MGMT port IP address.
— Gateway: Type the default gateway for the MGMT port.
— Use automatic MGMT port settings: Select the check box to instruct the member to negotiate the
optimum port connection type (full or half duplex) and speed with the connecting switch automatically.
If you clear the check box, manually configure the same settings on both the Infoblox device and the
switch. By default, the check box is selected.
5. Click the Save icon to add the member.
6. In the Grid perspective, select the member you just created, click Edit -> Member Properties.
7. In the Grid Member editor, click MGMT Port, select Enable VPN services on the MGMT Port, and then click
the Save icon.
MGMT Port Configuration on Device or HA Pair
8. Log in as a superuser to the MGMT port of the device or active node of the HA pair that you want to join to
the grid.
9. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Member Properties.
10. In the Grid Member editor, click MGMT Port, and then change the following for Node 1 (for a single device).
For an HA pair, enter the IP address, subnet mask, and gateway address for both Node 1 and Node 2.
— Enable management (MGMT) Port: Select the check box.
— Enable VPN services on the MGMT Port: (You cannot select this because the device or HA pair is not yet
a grid member. When the device or HA pair joins the grid, it receives its new configuration from the grid
master, and in that configuration, this option is set.)
Note: For the remainder of the MGMT port settings, configure the same settings that you previously set for the
single or HA member on the grid master (see step 4 in Member MGMT Port Configuration on the Grid
Master on page 93).
11. If the IP addresses of the LAN and HA ports are in the same subnet as the IP address of the MGMT port, click
LAN/HA Ports in the Grid Member editor, and then change the IP address of the LAN port (for a single
member) and LAN and HA ports (for an HA member).
12. Click the Save icon to save your settings.
13. From the Grid perspective, click + (for grid ) -> + (for Member ) -> member -> Edit -> Join Grid.
14. Enter the following in the Join Grid dialog box:
— Virtual IP of Grid Master: Type the VIP address of the grid master for the grid to which you want to add
the single device or HA pair.
— Grid Name: Type the name of the grid.
— Grid Shared Secret: Type the shared secret of the grid.
— Re-type Grid Shared Secret: To ensure accuracy, retype the shared secret.
— Use MGMT port to join grid: Because you have already enabled the MGMT port, this option is available.
Select it to connect to the grid through the MGMT port.
94
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using the MGMT Port
For a single device, it connects to the grid master from its MGMT port. The grid master allows it to join the grid,
and sends it its configuration and—if the device is running a different software version from the rest of the grid—
the software version for the grid.
When an HA pair joins the grid through their MGMT ports, each node joins separately. The process occurs as
follows:
1. You join the active node to the grid first (step 14) and the grid master sends it the remainder of its
configuration and—if the node is running a different software version from the rest of the grid—the software
version for the grid.
2. The HA pair fails over.
3. You now log in to the other node, which is now active, and join it to the grid (repeat step 14). The master
sends it its configuration and (if necessary) the version of software running on the grid.
4. The HA pair fails over again, so that the node that was active when you started the join operation becomes
the active node again when you finish it.
After a device or HA pair is part of the grid, you continue configuring it through the grid master.
DNS Services
You can configure a single independent device or single grid member to provide DNS services through the MGMT port
in addition to the LAN port. For example, the device can provide DNS services through the MGMT port for internal
clients on a private network, and DNS services through the LAN port for external clients on a public network.
Note: You can use the MGMT port for DNS services only on single independent devices and single grid members.
Infoblox devices in HA pairs do not support DNS services on the MGMT port.
While providing DNS services on the MGMT port, you can still use that port simultaneously for device management.
Figure 4.7 shows a management system communicating with a single independent device through its MGMT port
while the device also provides DNS services on that port to a private network. Additionally, the device provides DNS
services to an external network through its LAN port.
Figure 4.7 DNS Services on the LAN and MGMT Ports, and Device Management on the MGMT Port
External DNS Client
External DNS services go
through the LAN port.
External
Network
External DNS Clients
LAN
Port
Single
Independent
Device
Device management and
internal DNS services go
through the MGMT port.
Management System
MGMT
Port
Internal
Network
Internal DNS Clients
Like a single independent device, a single grid member can also support concurrent DNS traffic on its MGMT and LAN
ports. However, because you manage all grid members through the grid master, a grid member only uses an enabled
MGMT port to send SNMP traps, syslog events, and email notifications, and to receive SSH connections.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
95
Managing Device Operations
To enable DNS services on the MGMT port on a single independent device or single grid member:
1. Log in to the single independent device or grid master using a superuser account.
2. For a single grid member: From the Grid perspective, click + (for grid ) -> + (for Members) -> member -> Edit ->
Member Properties.
or
For a single independent device: From the Device perspective, click hostname -> Edit -> Device Properties.
3. In the Grid Member or Device editor, click MGMT Port, and then enter the following:
— Enable management (MGMT) Port: Select the check box.
— IP Address: Enter the IP address of the MGMT port. The MGMT port IP address must be in a different subnet
from that of the LAN and HA ports.
— Subnet mask: Choose an appropriate subnet mask for the MGMT port.
— Gateway: Enter the IP address of the gateway for the MGMT port.
4. Click the Save icon to save your settings for the MGMT port.
5. From the DNS perspective of the Member DNS Properties editor, click DNS Members -> + (for grid ) -> member ->
DNS -> Modify -> General.
6. In the Member DNS Properties editor, click General, and then select Enable DNS Services on the MGMT Port.
7. Click the Save icon to save your settings.
8. Click the Restart Services icon if it flashes.
9. To see that the device now also serves DNS on the MGMT port:
From the DNS perspective, click DNS Members -> + (for grid ) -> member -> View -> Properties, and look in the
General section. Check that the value for Enable DNS Services on the MGMT Port is true.
or
From the DNS perspective, click DNS Members -> + (for grid ) -> member -> View -> DNS Configuration, and check
that the IP address of the MGMT port appears in the address match list in the listen-on substatement.
96
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Setting Static Routes
Setting Static Routes
When you put the Infoblox device on a segment of the network where there is a single path to and from it, a single
default route is sufficient. For example, in Figure 4.8 on page 97, the device is in the DMZ behind a firewall and
connects to the rest of the network through the DMZ interface on the firewall. For example, when hosts send DNS
queries from the Internet and the internal network to the device and when the device replies to those hosts, the
firewall takes care of all the routing.
Figure 4.8 Single Default Route
Internet
1.2.2.1
The default route points all traffic from the LAN or LAN1
port on the Infoblox device to the DMZ interface (1.2.2.1)
on the firewall.
DMZ
Default route:
Network: 0.0.0.0
Netmask: 0.0.0.0
Gateway: 1.2.2.1
LAN
Port
Firewall
Internal Network
Infoblox Device
The device responds to all queries from the
Internet and internal network by sending its
responses to the DMZ interface (1.2.2.1) on
the firewall.
The device only needs a single default route
to the firewall. The firewall then routes the
traffic where it needs to go.
When the Infoblox device is on a segment of the network where there are multiple gateways through which traffic to
and from the device can flow, a single default route is insufficient. For an example, see Figure 4.9.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
97
Managing Device Operations
Figure 4.9 Erroneously Routed DNS Replies
Internet
Firewall-1
1.2.2.1
The default route points all traffic from the
Infoblox device to the DMZ interface (1.2.2.1) on
firewall-1.
DMZ
Infoblox Device
Default route:
Network: 0.0.0.0
Netmask: 0.0.0.0
Gateway: 1.2.2.1
Switch
1.2.2.2
Firewall-2
DNS queries from the Internet reach the
device through firewall-1, and the device
sends its replies back through firewall-1.
DNS queries from the internal network reach
the device through firewall-2, but because
there is only one default route, the device
erroneously sends DNS replies to the DMZ
interface (1.2.2.1) on firewall-1.
Internal Network
10.1.1.0/24
To resolve the problem illustrated in Figure 4.9 on page 98, add a second route pointing traffic destined for
10.1.1.0/24 to use the gateway with IP address 1.2.2.2 on firewall-2. This is shown in Figure 4.10.
Figure 4.10 Properly Routed DNS Replies
Internet
1.2.2.1
The default route on the Infoblox device
points traffic destined for the Internet to the
DMZ interface (1.2.2.1) on firewall-1.
Firewall-1
DMZ
1.2.2.0/24
Infoblox Device
Switch
1.2.2.2
Firewall-2
Internal Network
Default route:
Network: 0.0.0.0
Netmask: 0.0.0.0
Gateway: 1.2.2.1
Route to:
Network: 10.1.1.0
Netmask: 255.255.255.0
Gateway: 1.2.2.2
A second route on the device points traffic
destined for 10.1.1.0/24 to the DMZ
interface (1.2.2.2) on firewall-2.
10.1.1.0/24
98
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Setting Static Routes
Whenever you want the Infoblox device to send traffic through a gateway other than the default gateway, you need to
define a separate route. Then, when the device performs a route lookup, it chooses the route that most completely
matches the destination IP address in the packet header.
When you enable the MGMT port, the gateway you reference in a static route determines which port the Infoblox
device uses when directing traffic to a specified destination.
•
If a route definition references a gateway that is in the same subnet as the IP and VIP addresses of the LAN (or
LAN1) and HA ports, the Infoblox device uses the LAN (or LAN1) or HA port when directing traffic to that gateway.
•
If a route definition references a gateway that is in the same subnet as the MGMT port, the Infoblox device uses
the MGMT port when directing traffic to that gateway.
Figure 4.11 Static Routes for the LAN and MGMT Ports
Internet
LAN Gateway
(Firewall-1)
1.2.2.1
LAN Port
1.2.2.5
DMZ
1.2.2.0/24
MGMT Port
10.1.2.1
10.1.3.1
Administrators
10.1.2.5
Infoblox
MGMT
Subnet
Device
Gateway
Subnet
10.1.3.0/24
10.1.2.0/24
Switch
Switch
LAN Gateway
(Firewall-2)
1.2.2.2
10.1.1.1
Two static routes direct traffic from the Infoblox device:
• From the LAN port (eth1, 1.2.2.5) through the gateway
at 1.2.2.2 to the 10.1.1.0/24 subnet.
Internal Network
10.1.1.0/24
• From the MGMT port (eth0, 10.1.2.5) through the
gateway at 10.1.2.1 to the 10.1.3.0/24 subnet.
Route Tables on the Infoblox Device
From LAN:
1.2.2.0/24 dev eth1 scope link
10.1.1.0/24 via 1.2.2.2 dev eth1
default via 1.2.2.1 dev eth1
Note: There is a route table for each port
as well as a comprehensive route table.
For an HA pair, the LAN port route table
is duplicated for the HA port.
From MGMT:
10.1.2.0/24 dev eth0 scope link
10.1.3.0/24 via 10.1.2.1 dev eth0
default via 10.1.2.1 dev eth0
In this illustration, the static routes are
shown in green.
From all:
10.1.1.0/24 via 1.2.2.2 dev eth1
10.1.3.0/24 via 10.1.2.1 dev eth0
1.2.2.0/24 dev eth1 proto kernel scope link src 1.2.2.5
10.1.2.0/24 dev eth0 proto kernel scope link src 10.1.2.5
default via 1.2.2.1 dev eth1
The need for routes can apply to any type of traffic that originates from the device, such as DNS replies, DHCP
messages, SNMP traps, ICMP echo replies, Infoblox GUI management, and grid communications.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
99
Managing Device Operations
To set a static route, do the following:
1. For a grid member: From the Grid perspective, click + (for grid ) -> + (for Member s) -> member -> Edit -> Member
Properties.
or
For an independent device or HA pair: From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid Member or Device editor, click Static Routes, click Add, and then enter the following in the Static Route
dialog box:
— Network Address: Type the address of the remote network to which you want to route traffic from the
Infoblox device.
— Netmask: Choose the netmask that defines the remote network.
— Gateway Address: Type the IP address of the gateway on the local subnet through which you want the
Infoblox device to direct traffic to reach the remote network.
3. Click the Save icon to save your settings.
Note: Consult your network administrator before configuring the gateway address for a static route on the device.
Specifying an invalid IP address may cause the device to fail.
Infoblox recommends you use some caution when configuring static routes. Configuring incorrect static routes may
cause serious problems, such as packets being dropped or sent to an incorrect address. A valid static route on the
device meets the following requirements:
•
The gateway address of the static route must belong to a working gateway router or gateway switch.
•
The gateway address of the static route must be part of the same subnet as the Infoblox device. The gateway
address netmask must be the same or larger than the netmask of the Infoblox device.
•
The network address to the remote network configured for the static route must not belong to the device
network. The network address must be outside of the local network of the device.
Enabling DNS Resolution
You can specify a network server to perform domain name queries and specify up to two name servers for resolving
a DNS name, plus use a search list to perform partial name resolution.
If an Infoblox device provides DHCP services only, you need to specify a DNS name server or servers that the device
can use for DNS lookups. You specify the IP address of a preferred name server and that of an alternate name server,
plus use a search list for performing partial name resolution.
To enable DNS resolution for a grid or for an independent device or HA pair:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid editor, click DNS Resolver, and then enter the following:
— Use DNS name resolver: Select the check box to enable the Infoblox device to send DNS queries to the
preferred or alternate name servers whose IP addresses you specify in the following fields.
— Preferred Name Server: Type the IP address of the name server to which you want the Infoblox device to
send queries first.
— Alternate Name Server: Type the IP address of the name server to which you want the Infoblox device to
send queries if it does not receive a response from the preferred name server.
100
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Enabling DNS Resolution
— Search Domain Group: Define a group of domain names that the Infoblox device can add to partial queries
that do not specify a domain name. For example, if you define a RADIUS authentication home server as
“as1”, and you list "corp100.com" and "hq.corp100.com" in the domain group list, then the Infoblox device
sends a query for "as1.corp100.com" and another query for "as1.hq.corp100.com" to the preferred or
alternate name server.
To add a domain name to the group, type a domain name in the Domain field, and then click Add.
To remove a domain name from the group, select it, and then click Delete.
3. Click the Save icon.
Note: You can override the grid-level settings at the member level.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
101
Managing Device Operations
Managing Licenses
Licenses come pre-installed on an Infoblox device according to the software packages you ordered at the time of
purchase. If you wish to upgrade an existing device with the Keystone license, you must contact Infoblox Technical
Support and follow the procedures in Obtaining and Adding a License.
There are three types of licenses:
•
Maintenance licenses – Examples: NIOS and Keystone maintenance licenses. The duration of maintenance
licenses are one, two, or three years. You can obtain these licenses from your Infoblox sales representative.
•
Service licenses – Examples: DNS, DHCP, Keystone. These are permanent licenses. You can obtain these
licenses from your Infoblox sales representative.
•
Temporary licenses – You can enable one of several sets of temporary service licenses through the CLI
command set temp_license . These licenses last for 60 days.
Two weeks before a maintenance license or a temporary license expires, an expiration warning appears during the
GUI login process. The warning reappears during each login until you renew the license. To do renew a license, contact
your Infoblox sales representative. If you decide not to renew an expired license and want to stop the warning from
reappearing, do the following:
1. Back up the configuration and database as described in Backing Up and Restoring a Configuration File on
page 158.
2. Log in to the Infoblox CLI, enter the show license command, and save all the license key strings.
3. Remove all the licenses—and the entire configuration and database—by entering the reset all
licenses command. (For details, see Removing Licenses on page 103.)
4. Add the unexpired licenses back to the device using either the Infoblox GUI or CLI.
5. Restore the backup file as described in Backing Up and Restoring a Configuration File on page 158.
Viewing the Installed Licenses on an Infoblox Device
If the device you are identifying is part of a grid, you must log in to the master GUI for the grid to view the licenses
installed. If the device is deployed as a single independent device, log in to the GUI for that device.
To view the licenses installed on an Infoblox device, follow these steps:
1. Log in to the Infoblox GUI using a superuser account.
2. From the Grid or Device perspective, click hostname -> View -> Properties.
3. Click the + icon beside the License section to expand it and view the licenses installed on the device.
Obtaining a 60-Day Temporary License
You can use the CLI command set temp_license to generate and install temporary 60-day licenses. This can
provide licensed features and functionality for the interim, while you wait for your permanent license to arrive.
To generate a temporary license:
1. Log in to the Infoblox device through a remote console window. For more information on how to open a remote
console window, see the User Guide for your device.
2. After the Infoblox command prompt, enter the following command:
set temp_license
The following options appear:
1. DNSone (DNS, DHCP)
2. DNSone with Keystone (DNS, DHCP, Grid)
3. Network Services for Alcatel-Lucent VitalQIP (QIP, Grid)
4. Network Services for Voice (DHCP, Grid)
5. Network Services for Authentication (RADIUS, Grid)
102
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Licenses
6. Network Services Suite (DNS, DHCP, RADIUS, Grid)
7. Add DNS Server license
8. Add DHCP Server license
9. Add RADIUS Server license
10. Add Grid license
3. Enter the number for the license you want to install.
4. Confirm the selection when prompted, and the following message appears:
Temporary license is installed.
Obtaining and Adding a License
A valid Keystone license is required for grid Infoblox device deployments. You can upgrade existing independent
devices to use a Keystone license and then add them to a grid. To upgrade your license, contact your Infoblox sales
representative.
To add a license:
1. Log in to the Infoblox GUI using a superuser account.
2. From the Grid or Device perspective, click hostname -> Edit -> Add License.
3. In the Add License dialog box, copy the hardware ID and serial number of your device and paste this information
into an e-mail to Infoblox Support.
4. When you receive the license key, use the shortcut keys Ctrl-C (for copy) and Ctrl-V (for paste) to copy the license
key from the response e-mail, and then paste it in the Enter license string field.
5. Click OK to close the Add License dialog box.
6. Close the browser window and log in to the Infoblox GUI.
7. If you are activating licenses for an HA pair, you must repeat this procedure for the second node.
Removing Licenses
You can remove licenses and reset an Infoblox device to its factory default settings. For example, if you have an
Infoblox device running the DNSone package with the Keystone upgrade, but you want to use it as an independent
device and manage it through the Device Manager GUI, you can do the following:
1. Log in to the Infoblox device CLI—locally through the Console port or remotely through an SSHv2 connection—
and use the show license command to view all the licenses installed on the device.
The output of the the show license command looks similar to the following:
Infoblox > show license
Version: 4.0r1
Hardware ID: ecafc0c469e8c75eb59cb7e4b5912a6
License Type: Keystone DVS
Expiration Date: 11/04/2006
License String: GQAAAAOS5WYrGV/JEzH6wrHYQ8L1b25y3Y+VPPY=
License Type: DNS
Expiration Date: Permanent
License String: EQAAAAKS4n90WFGNUSirwvyUT9/z
License Type: DHCP
Expiration Date: Permanent
License String: EgAAAAKU8nMlRBzcTWX63rHYFoymOQ==
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
103
Managing Device Operations
License Type: Keystone Maintenance
Expiration Date: 11/04/2006
License String: GwAAAA2Z6HAtBkPFPyfzg/yVRsLzI2x0kYyKaPb22g==
License Type: NIOS Maintenance
Expiration Date: 11/04/2006
License String: GwAAAAiV/nAGGljQEDv0h/yVRsLzI2x0kYyKb/P20Q==
2. Copy the output of the show license command, and save it to a text file on your management system.
3. Reset the Infoblox device and remove all the licenses by entering the reset all licenses command.
4. This command returns all settings to their default values and removes all licenses.
Infoblox > reset all licenses
The entire system will be erased to default settings and all licenses will be removed.
WARNING: THIS WILL ERASE ALL DATA AND LOG FILES THAT HAVE BEEN CREATED ON THIS SYSTEM.
ARE YOU SURE YOU WANT TO PROCEED? (y or n): y
The application restarts with the default settings and no licenses.
5. Log in to the CLI through the Console port, and check that all the licenses are gone by entering the
show license command.
Infoblox > show license
Version: 4.0r1
Hardware ID: ecafc0c469e8c75eb59cb7e4b5912a6
Infoblox >
6. Add back only the DNS, DHCP, and NIOS Maintenance licenses by entering the set license command and
then copying and pasting the text string for each license:
Infoblox > set license
Enter license string: EQAAAAKS4n90WFGNUSirwvyUT9/z
Install license? (y or n): y
License is installed.
Infoblox > set license
Enter license string: EgAAAAKU8nMlRBzcTWX63rHYFoymOQ= =
Install license? (y or n): y
License is installed.
Infoblox > set license
Enter license string: GwAAAAiV/nAGGljQEDv0h/yVRsLzI2x0kYyKb/P20Q==
Install license? (y or n): y
License is installed.
7. To check that the licenses are now installed, enter the show license command.
When you next log in to the GUI, the Infoblox Device Manager appears instead of the Infoblox Grid Manager.
104
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Shutting Down, Rebooting, and Resetting an Infoblox Device
Shutting Down, Rebooting, and Resetting an Infoblox Device
To reboot and shut down an Infoblox device, you can use the Infoblox Manager GUI or the Infoblox CLI. To reset a
device, you must use the Infoblox CLI.
Rebooting a Device
You can reboot a single device, a single node in an HA pair, or both nodes in an HA pair. When you reboot both nodes,
the active node reboots first, and then the passive node reboots.
To reboot a single device or one or both nodes in an HA pair using the GUI:
1. From the Grid or Device perspective, click hostname -> Edit -> Reboot.
2. For an HA pair, choose whether to boot one node (and which one) or both nodes, and then click OK.
To reboot a single device using the CLI:
1. Log in to the Infoblox CLI using a superuser account for the device that you intend to reboot.
2. Enter the following CLI command: reboot
Shutting Down a Device
Under normal circumstances, you do not need to turn off or shut down an Infoblox device. It is designed to operate
continuously. However, if you want to turn off an Infoblox device and it is inconvenient to turn off the power switch,
you can shut down the Infoblox device using the GUI. Before shutting down a remote device, make sure you can
restart it. You cannot restart the system using the GUI.
Note: If there is a disruption in power when the Infoblox device is operating, the Infoblox device automatically
reboots itself when power is restored.
To shutdown an Infoblox device using the GUI:
1. Log in to the Infoblox Manager GUI using a superuser account.
2. From the Grid or Device perspective, click hostname -> Edit -> Shutdown.
3. For an HA pair, choose whether to shut down one node (and which one) or both nodes, and then click OK.
The Infoblox device shuts down. The fans might continue to operate until the device cools down.
To shutdown an Infoblox device using the CLI:
1. Log in to the Infoblox CLI using a superuser account.
2. Enter the following CLI command: shutdown
Resetting a Device
There are three ways to reset an Infoblox device:
•
•
•
Resetting the Database on page 106
Resetting a Device to Factory Settings on page 106
Resetting the Device to Factory Settings and Removing Licenses on page 106
You can perform these functions only through the CLI.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
105
Managing Device Operations
Resetting the Database
You can reset the database if you lose the administrator account and password or if you want to clear the database
but preserve the log files to diagnose a problem. This function removes the configuration files, and the DNS and DHCP
data from the device database. During this procedure, you are given the option to preserve the network settings of
the device, which are the IP address and subnet mask, the IP address of the gateway, the host name, and the remote
access setting.
To reset the database:
1. Log in to the Infoblox CLI using a superuser account.
2. Enter the following CLI command: reset database
The device then displays a message similar to the following:
The following network settings can be restored after reset:
IP Address: 10.1.1.10
Subnet Mask: 255.255.255.0
Gateway: 10.1.1.1
Host Name: ns1.corp100.com
Remote Console Access: true
The entire database will be erased.
Do you wish to preserve basic network settings? (y or n)
3. Press the Y key to preserve the network settings or the N key to return the network settings to their default values
(192.168.1.2, 255.255.255.0, 192.168.1.1).
Resetting a Device to Factory Settings
You can reset an Infoblox device to its original factory settings. This removes the database, network settings, logs,
and configuration files. Then, it reboots with its factory settings, which are the default user name and password, and
default network settings. When you perform this procedure, the device does not give you the option to preserve your
network settings.
Note: If you have previously imported HTTPS certificates, the device regenerates the certificates and replaces them.
To reset the device to its factory settings:
1. Log in to the Infoblox CLI using a superuser account.
2. Enter the following CLI command: reset all
Resetting the Device to Factory Settings and Removing Licenses
You can also reset an Infoblox device to its original factory settings and remove all the licenses installed on the
device. This removes the database, network settings, logs, configuration files, and licenses. The device then reboots
with its factory settings, which are the default user name and password, and default network settings.
Note: If you have previously imported HTTPS certificates, the device regenerates the certificates and replaces them.
To reset the device to its factory settings and remove all its licenses:
1. Log in to the Infoblox CLI using a superuser account.
2. Enter the following CLI command: reset all licenses
106
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing the Disk Subsystem on the Infoblox-2000
Managing the Disk Subsystem on the Infoblox-2000
Among its many features, the Infoblox-2000 uses redundant disk drives in a RAID 10 array. This configuration
provides the optimum mix of performance with completely redundant data storage with recovery features in the event
of disk failures. The disk array is completely self managed, there are no maintenance or special procedures required
to service the disk subsystem.
Caution: It is important to never remove more that one disk at a time from the array. Removing two or more disks at
once can cause a failure and possibly unrecoverable condition.
About RAID 10
RAID 10 (or sometimes called RAID 1+0) is a stripe of mirrors. This means that the array combines—or stripes—
multiple disk drives, creating a single logical volume (RAID 0). Striping disk drives improves database write
performance over a single disk drive for large databases. The disks are also mirrored (RAID 1), so that each disk in
the logical volume is also fully redundant. Please seeFigure 4.12.
Figure 4.12 RAID 10 Array Configuration
RAID 0
RAID 1
Disk 1
Primary
RAID 1
Disk 1
Backup
Disk 2
Backup
Disk 2
Primary
When evaluating a fault on the Infoblox-2000, it is best to think of the disk subsystem as a single, integrated unit with
four components, rather than four independent disk drives.
Evaluating the Status of the Disk Subsystem
The disk subsystem can be visually monitored through the Infoblox GUI, the scrolling front panel LCD display and four
front panel LEDs next to the disk drives. In addition, you can also monitor the disk status by using the CLI command
show hardware_status.
The Detailed Status panel provides a detailed status report on the device and service operations. To see a detailed
status report, from the Grid perspective, select grid, and then click View -> Detailed Status. After displaying the
Detailed Status panel, you can view the status of individual grid members and services by selecting them in the Grid
panel. (For more information on the Detailed Status Panel, see Viewing Detailed Status on page 112.
The RAID icon indicates the status of the RAID array on the Infoblox-2000.
Icon
NIOS 4.1r3
Color
Meaning
Green
The RAID array is functioning properly.
Yellow
A new disk was inserted and the RAID array is rebuilding.
Infoblox Administrator Guide (Rev. A)
107
Managing Device Operations
Icon
Color
Meaning
Red
The RAID array is degraded. At least one disk is not functioning properly. The GUI lists the disks
that are online. Replace only the disks that are offline.
Appliance Front Panel
The disk drives are located on the right side of the appliance front panel. To the right of each drive there is an LED
that displays the status of each drive.
Table 4.4 Disk Drive LEDs
LED Color
Condition
Action
Green
Disk operating normally
None
Yellow
Disk read/write activity
Disk is functioning normally or is synchronizing if recently
inserted.
Dark
Disk has failed or not inserted
Verify the failure in the GUI or CLI. Remove the disk and
replace with a functional disk drive. Note that the drive
rebuilds with its twin.
In addition, the front panel LCD scrolls and displays the disk array status every 20 seconds.
Replacing a Failed Disk Drive
The Infoblox-2000 was designed to provide continuous operation in the event of a failed disk. Hot-swapping a disk
drive is a simple process that does not require issuing commands or GUI operation to replace a disk. To replace a
disk drive, follow this procedure:
1. Identify and verify the failed drive via the Grid Manager, front panel LCD or CLI.
2. If the activity light is green or blinking yellow, make sure you have identified the correct drive. There are
conditions where a drive could be in the process of failing and still be green or yellow.
Note: Do not remove a correctly functioning drive
3. Push in the latch for the drive and pull the release lever out towards you.
4. When the drive disengages, slide it out of the slot.
To install a replacement drive, follow this procedure:
1. Replacement drives are shipped as a complete unit, ready to insert into the appliance. There is no preparation
required.
2. Insert the replacement drive into the drive bay slot.
3. Gently slide the drive into place. When you feel the release lever engage, continue applying gentle pressure to
the drive while pushing the release lever towards the appliance.
4. The release lever locks into place and the LED next to the disk drive lights up. Note that if the alarm buzzer is
sounding, it automatically turns off about 20 seconds after the drive is inserted.
5. The disk drive automatically goes into rebuild mode.
108
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing the Disk Subsystem on the Infoblox-2000
Disk Array Guidelines
Infoblox has designed the disk array to be completely self managing. There are no maintenance procedures required
for a normally functioning disk array. If the disk array is mis-handled, it can result in an unrecoverable error that could
result in a failed appliance. Following are some guidelines for managing the disk array:
•
Only remove one disk at a time. Never remove two or more disks from the appliance at once. This rule includes
a powered down appliance.
•
There is no way to know the arrangement of the primary and backup disk drives in the RAID 0 array.
•
Hot-swapping a drive can occur while the appliance remains in production.
•
There is never a condition that requires the user to power down the appliance or unmount a disk drive to replace
a failed unit.
•
If you inadvertently remove the wrong disk drive, do not immediately remove the disk drive you originally
intended to remove. Verify the status of the array before removing another drive. Removing a second drive
could render the appliance inoperable.
•
If a drive has failed, there is an audio alarm buzzer. The alarm automatically stops about 20 seconds after a
functional disk has been inserted into the array.
•
Only remove failed or failing disk drives. Never remove an optimally functioning drive.
•
In the unlikely event that two disk drives fail simultaneously and the appliance is still operational, remove and
replace the failed disk drives one at a time.
•
Rebuild time can vary. The rebuild process takes approximately two hours on an idle appliance. On very busy
appliances (over 90% utilization), the disk rebuild process can take as long as 40 hours. On a grid master
serving a very large grid, the rebuild process could take take at least 24 hours.
•
If your acceptance procedures require a test of the RAID hot-swap features, any drive can be removed, but only
one disk drive at a time should be removed. Removing two disks has a 50% probability of an appliance failure.
Removing more than two disks will result in an appliance failure and require a RMA of the appliance.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
109
Managing Device Operations
110
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 5 Monitoring the Device
This chapter describes the status icons in the Infoblox GUI that indicate the state of devices, services, database
capacity, ethernet ports, HA, and grid replication. It also explains how to use the various logs and the traffic capture
tool to monitor an Infoblox device. You can set the monitoring parameters at the grid and member levels.
The topics in this chapter include:
•
•
•
Viewing Detailed Status on page 112
— Device Status on page 112
— Service Status on page 112
— DB Capacity Used on page 113
— Disk Usage on page 113
— HA, LAN, or MGMT Port on page 114
— LCD on page 114
— Memory Usage on page 114
— Replication on page 115
Using a Syslog Server on page 117
— Specifying Syslog Servers on page 117
— Configuring Syslog for a Grid Member on page 118
— Setting DNS Logging Categories on page 119
— Viewing the System Log on page 119
— Searching for Text on page 120
— Downloading the Syslog File on page 120
Monitoring Tools on page 121
— Using the Audit Log on page 121
— Using the Replication Log on page 122
— Using the Traffic Capture Tool on page 123
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
111
Monitoring the Device
Viewing Detailed Status
The Infoblox GUI changes the color of status icons to indicate the state of devices, services, database capacity,
ethernet ports, HA, and grid replication. For the Infoblox-1552 and 2000, the GUI displays status icons for the power
supplies. For the Infoblox-2000, the GUI displays icons to indicate the state of the RAID array and disk controller
backup battery.
To see a detailed status report for a grid, from the Grid perspective, select grid, and then click View -> Detailed Status.
After displaying the Detailed Status panel, you can view the status of individual grid members and services by
selecting them in the Grid panel.
The Detailed Status panel provides a detailed status report on the following device and service operations:
Device Status
The status icons indicate the operational status of a grid member and a general description about what it is currently
doing. The device status icon can be one of the following colors:
Icon
Color
Meaning
Green
The device is operating normally in a “running” state.
Yellow
The device is connecting or synchronizing with its grid master.
Red
The grid member is offline, is not licensed (that is, it does not have a DNSone license with the
Keystone upgrade that permits grid membership), is upgrading or downgrading, or is shutting
down.
Following are some device descriptions that might appear in the Description column: Running, Offline, Connecting,
Synchronizing, Authentication Failed, Shared secret did not match, Not Licensed, SW Revision Mismatch,
Downloading Release from Master, and Shutting Down.
Service Status
After you enable DHCP, DNS, HTTP (for file distribution), RADIUS, TFTP, or VitalQIP services, the Infoblox GUI indicates
its status with a green or red icon. Because the status icons for NTP have a different meaning, those meanings are
explained in a separate table.
DHCP, DNS, HTTP (File Distribution) , RADIUS, TFTP, or VitalQIP
Icon
112
Color
Meaning
Green
A service is enabled and running properly.
Red
A service is enabled but not running. (A red status icon can also appear temporarily when a
service is enabled and begins running, but the monitoring mechanism has not yet notified the
GUI engine.)
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Viewing Detailed Status
NTP
Icon
Color
Meaning
Green
NTP is enabled and running properly.
Yellow
(grid member) NTP is enabled and running properly on the grid master, but it is not running on
this member, although it is enabled on this member.
Red
(grid master) NTP is enabled on the grid master, but it is not running on the master.
The type of information that can appear in the Description column for a service corresponds to SNMP trap messages.
DB Capacity Used
Status icons for DB Capacity Used indicate the current percentage of the database in use on a selected grid member.
The maximum is 100%.
Icon
Color
Meaning
Green
Under 85% database capacity is currently in use.
Yellow
Over 85% database capacity is currently in use. When the capacity exceeds 85%, the icon
changes from green to yellow and the Infoblox device sends an SNMP trap.
Disk Usage
This indicates the percentage of the data partition on the hard disk drive currently in use.
Icon
Color
Meaning
Green
Under 85% capacity
Yellow
Between 85% and 95% capacity
Red
Over 95% capacity
FAN
The status icon indicates whether the fan(s) are functioning. The corresponding description displays the fan speed.
Icon
NIOS 4.1r3
Color
Meaning
Green
All fans are functioning properly.
Red
At least one fan is not running.
Infoblox Administrator Guide (Rev. A)
113
Monitoring the Device
HA, LAN, or MGMT Port
The status icons for the HA, LAN/LAN1, and MGMT ethernet ports indicate the state of their network connectivity.
Icon
Color
Meaning
Green
The port is properly connected to a network. Its IP address appears in the Description column.
Red
The port is not able to make a network connection.
LCD
The LCD status icon indicates its operational status.
Icon
Color
Meaning
Green
The LCD is functioning properly.
Red
The LCD process is not running.
Memory Usage
The status icon for memory usage indicates the current percentage of memory in use.
Icon
Color
Meaning
Green
Under 90% capacity
Yellow
Between 90% and 95% capacity and increased activity
Red
Over 95% capacity and increased activity
Note: You can see more details about memory usage through the CLI command: show memory
Power Supply
The Infoblox-1552 and Infoblox-2000 have redundant power supplies. The power supply icon indicates the
operational status of the power supplies.
Icon
114
Color
Meaning
Green
The power supplies are functioning properly.
Red
One power supply is not running. To find out which power supply failed, check the LEDs of the
power supplies.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Viewing Detailed Status
RAID
This icon indicates the status of the RAID array on the Infoblox-2000.
Icon
Color
Meaning
Green
The RAID array is functioning properly.
Yellow
A new disk was inserted and the RAID array is rebuilding.
Red
The RAID array is degraded. At least one disk is not functioning properly. The GUI lists the disks
that are online. Replace only the disks that are offline.
RAID Battery
This icon indicates the status of the disk controller backup battery on the Infoblox-2000.
Icon
Color
Meaning
Green
The battery is charged. The description indicates the estimated number of hours of charge
remaining on the battery
Red
The battery is not charged.
Temperatures
This icon is always green. The description reports the CPU and system temperatures.
Replication
The current state of replication between a grid member and master or between the passive and active nodes in an HA
pair.
Grid Member <–> Master
Icon
NIOS 4.1r3
Color
Meaning
Green
Grid communications are operating normally and ongoing database updates are occurring.
Yellow
The member is synchronizing itself with the master, and either complete or partial database
replication is occurring. All master candidates receive the complete database. All regular
members (that is, members not configured as master candidates) receive the section of the
database that applies to themselves.
Red
The member and master are not replicating the database between themselves.
Infoblox Administrator Guide (Rev. A)
115
Monitoring the Device
HA Pair Passive Node <–> Active Node
Icon
116
Color
Meaning
Green
HA communications are operating normally and database replication is occurring.
Yellow
The passive node is synchronizing itself with the active node, and database replication is
occurring.
Red
The passive and active nodes are not replicating the database between themselves.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using a Syslog Server
Using a Syslog Server
Syslog is a widely used mechanism for logging system events. Infoblox devices generate syslog messages which you
can view through the system log viewer and download to a directory on your management station. In addition, you
can configure an Infoblox device to send the messages to one or more external syslog servers for later analysis.
Syslog messages provide information about device operations and processes. You can also include audit log
messages and specific BIND messages among the messages the device sends to the syslog server.
You can set syslog parameters at the grid and member levels. At the member level, you can override grid-level syslog
settings and enable syslog proxy.
The topics in this section include:
•
•
•
•
•
•
Specifying Syslog Servers on page 117
Configuring Syslog for a Grid Member on page 118
Setting DNS Logging Categories on page 119
Viewing the System Log on page 119
Searching for Text on page 120
Downloading the Syslog File on page 120
Specifying Syslog Servers
To configure an Infoblox device to send messages to a syslog server:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid or Device editor, click Monitoring, and then enter the following:
— Enable external syslog server: Select this check box to enable the Infoblox device to send messages to a
specified syslog server.
— Syslog Server Group: To define one or more syslog servers, click Add, enter the following, and then click OK:
— Server Address: Type the IP address of a syslog server.
— Connection Type: Specify whether the device uses TCP or UDP to connect to the external syslog server.
— Port: Specify the destination port number.
— Out Interface: Specify the interface through which the device sends syslog messages to the syslog
server.
— Severity Filter: Choose a filter from the drop-down list. When you choose a severity level, grid members
send messages for that severity level plus all messages for all severity levels above it. The lowest
severity level is debug (at the top of the drop-down list), and the highest severity level is emerg (at the
bottom of the list). Accordingly, if you choose “debug”, grid members send all syslog messages to the
server. If you choose “err”, grid members send messages with the severity levels err, crit, alert, and
emerg. If you choose “emerg”, they send only “emerg” messages.
— Message Source: Specify which syslog messages the device sends to the external syslog server:
•
Internal: The device sends syslog messages that it generates.
•
External: The device sends syslog messages that it receives from other devices, such as syslog
servers and routers.
•
Any: The device sends both internal and external syslog messages.
— Copy audit log messages to syslog: Select the check box for the Infoblox device to include audit log
messages among the messages it sends to the syslog server. This function can be helpful for monitoring
administrative activity on multiple devices from a central location.
— Audit Log Facility: Choose the facility where you want the syslog server to sort the audit log messages.
3. Click the Save icon to save your settings.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
117
Monitoring the Device
Configuring Syslog for a Grid Member
You can override grid-level syslog settings and enable syslog proxy for individual members. When you enable syslog
proxy, the member receives syslog messages from specified devices, such as syslog servers and routers, and then
forwards these messages to an external syslog server. You can also enable devices to use TCP for sending syslog
messages. TCP is more reliable than using UDP; this reliability is important for security, accounting, and auditing
messages sent through syslog.
To configure syslog parameters for a member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Edit -> Member Properties.
2. In the Grid Member editor, click Monitoring, and enter the following:
— Override grid syslog settings: Select the check box to override grid-level syslog settings and apply
member-level settings.
— Enable external syslog server: Select this check box to enable the Infoblox device to send messages to a
specified syslog server.
— Syslog Server Group: To define one or more syslog servers, click Add, enter the following, and then click OK:
— Server Address: Type the IP address of a syslog server.
— Connection Type: Specify whether the device uses TCP or UDP to connect to the external syslog server.
— Port: Specify the destination port number.
— Out Interface: Specify the interface through which the device sends syslog messages to the syslog
server.
— Severity Filter: Choose a filter from the drop-down list. When you choose a severity level, the Infoblox
device sends messages for that severity level plus all messages for all severity levels above it. The
lowest severity level is debug (at the top of the drop-down list), and the highest severity level is emerg
(at the bottom of the list). Accordingly, if you choose “debug”, the single device or active node in an HA
pair sends all syslog messages to the server. If you choose “err”, it sends messages with the severity
levels err, crit, alert, and emerg. If you choose “emerg”, it sends only “emerg” messages.
— Message Source: Specify which syslog messages the device sends to the external syslog server:
•
•
Internal: The device sends syslog messages that it generates.
•
External: The device sends syslog messages that it receives from other devices.
•
Any: The device sends both internal and external syslog messages.
Enable syslog proxy: Select this check box to enable the device to receive syslog messages from other devices,
such as syslog servers and routers, and then forward these messages to an external syslog server.
— Enable listening on TCP: Select this check box if the device uses TCP to receive messages from other
devices.
— Port: Enter the number of the port through which the device receives syslog messages from other
devices.
— Enable listening on UDP: Select this check box if the device uses UDP to to receive messages from other
devices.
— Port: Enter the number of the port through which the device receives syslog messages from other
devices.
— Proxy Client Access Control: Click Add, enter the following in the Access Control Item dialog box, and then
click OK:
— IP Address option: Select IP Address if you are adding the IP address of a device or select Network if
you are adding the network address of a group of devices.
•
Address: Enter the IP address of the device or network.
•
Subnet Mask: If you entered a network IP address, you must also enter its subnet mask.
3. Click the Save icon to save your settings.
118
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using a Syslog Server
Setting DNS Logging Categories
You can specify which of 14 BIND logging message categories you want syslog to capture, and furthermore, you can
filter these messages by severity. For information about severity types, refer to Using a Syslog Server on page 117.
To specify logging categories:
1. From the Grid perspective, click + (for grid ) -> + (for Services) -> DNS -> Service Properties.
or
From the Device perspective, click + (for hostname ) -> DNS -> Service Properties.
2. In the Grid DNS Properties editor, click Logging, and then enter the following:
— Logging Facility: Select a facility from the drop-down list. This is the location on the syslog server to which
you want to sort the DNS logging messages.
— Select one of more of these log categories:
— Enable General: Records the BIND messages that are not specifically classified.
— Enable Config: Records the configuration file parsing messages.
— Enable DNSSEC: Records the DNSSEC-signed responses.
— Enable Network: Records the network operation messages.
— Enable Queries: Records the query response messages.
— Enable Security: Records the approved and denied requests.
— Enable Transfer-in: Records zone transfer messages from the remote name servers to the device.
— Enable Transfer-out: Records zone transfer messages from the Infoblox device to remote name servers.
— Enable Update: Records the dynamic update instances.
— Enable Resolver: Records the DNS resolution instances, including recursive queries from resolvers.
— Enable Notify: Records the asynchronous zone change notification messages.
— Enable Lame Servers: Records bad delegation instances.
— Enable Database: Records BIND’s internal database processes.
— Enable Client: Records client requests.
3. Click the Save icon to save your settings.
4. Click the Restart Services icon if it flashes.
Viewing the System Log
In addition to saving syslog messages to a remote syslog server, an Infoblox device also stores the system messages
locally. To view syslog messages on an Infoblox device:
1. From the Grid perspective, click + (for grid ) -> + (for Members) -> member -> File -> System Log -> ip_addr .
or
From the Device perspective, click hostname -> File -> System Log -> ip_addr .
Note: You can also right-click a grid member or independent device or HA pair, and then select System Log ->
ip_addr in the short-cut menu.
The device displays the syslog messages for the specified member.
2. To refresh the contents in the System Log File viewer, click View -> Refresh (or press the F5 key).
3. To delete the contents in the System Log File viewer, click View -> Clear. Note that only a superuser can clear the
syslog file.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
119
Monitoring the Device
Searching for Text
Instead of paging through the syslog messages to locate messages, you can limit the display to syslog messages with
certain text strings. To search for specified text strings:
1. From the Grid perspective, click + (for grid ) -> + (for Members) -> member -> File -> System Log -> ip_addr .
or
From the Device perspective, click hostname -> File -> System Log -> ip_addr .
Note: You can also right-click a grid member or independent device or HA pair, and then select System Log ->
ip_addr in the short-cut menu.
The device displays the syslog messages for the specified member.
2. Click the Search icon in the upper right corner of the System Log File viewer.
3. Enter the text string and then click Search.
The device displays the results of your search in a Search Results panel.
Downloading the Syslog File
You can download the syslog file to a specified directory, if you want to print and analyze it.
To download a syslog file:
1. From the Grid perspective, click + (for grid ) -> + (for Members) -> member -> File -> System Log -> ip_addr .
or
From the Device perspective, click hostname -> File -> System Log -> ip_addr .
Note: You can also right-click a grid member or independent device or HA pair, and then select System Log ->
ip_addr in the short-cut menu.
The device displays the syslog messages for the specified member.
2. Click the Download File icon in the upper right corner of the System Log File viewer, navigate to a directory where
you want to save it, optionally change the file name (the default names are node_1_sysLog.tar.gz and
node_2_sysLog.tar.gz ), and then click OK.
120
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Monitoring Tools
Monitoring Tools
You can view the database replication status in a grid or HA pair, monitor administrator activity, and capture traffic
for diagnostic purposes. This section includes the following topics:
•
•
•
Using the Audit Log on page 121
Using the Replication Log on page 122
Using the Traffic Capture Tool on page 123
Using the Audit Log
The audit log contains a record of all Infoblox administrative activity. It provides detailed information on changes such
as:
•
Date and time stamp of the change
•
Administrator name
•
Changed object name
•
New value of the object. If you change multiple properties of an object, the audit log lists all changes in multiple
log entries.
You can also search the audit log to find what the new value of an object.
The audit log file can store up to 100 MB of data, after which the system purges it.
Viewing the Audit Log
To view an audit log:
1. From the Grid perspective, select grid -> File -> Audit Log.
or
From the Device perspective, select hostname -> File -> Audit Log .
2. To refresh the Audit Log File viewer, select View -> Refresh (or press the F5 key).
3. To delete the contents of the Audit Log File viewer, select View -> Clear.
Note: You can search and download the audit log as you can the system log. For information, see Searching for Text
on page 120 and Downloading the Syslog File on page 120.
Audit Log Format
The format of the audit log is similar to the syslog:
[time stamp] [user name]: message
If you change multiple properties of an object in one operation, each property change appears in one line of the log
message. For example, if you changed the zone member and comment of the test.com zone, the audit log appears as
follows:
[time stamp] [user name]: Modified zone test.com. Changed member to "new.member"
[time stamp] [user name]: Modified zone test.com. Changed comment to "new comment"
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
121
Monitoring the Device
Specifying the Audit Log Type
There are two types of audit logs—brief or detailed (default). The brief version contains only the date and time when
the change occurred, administrator name, and the changed object name. The detailed version contains all of this
information and also shows the new values of all properties. The detailed version is the default type. It is
automatically selected. You can specify the audit log type in the Grid Properties Editor as follows:
1. Select Grid -> Edit -> Grid Properties.
2. Click the Grid Properties section to expand it.
3. Under Audit Log Format, select:
Detailed: This is the default format. It is automatically selected. It provides detailed information on all
administrative changes such as the date and time stamp of the change, administrator name, changed object
name, and the new values of all properties.
Brief: Provides information on administrative changes such as the date and time stamp of the change,
administrator name, and the changed object name. It does not show the new value of the object. For example,
[Feb 16 09:47:57] [John Doe]: modified zone test.com.
Audit Log Examples
The system logs the following:
•
All successful write operations such as add, modify, or remove objects.
•
All successful system management operations such as restart service and reboot unit.
For example, when you add or remove an object, the system logs:
[Feb 14 18:34:34] [John Doe]: added zone test.com.
[Feb 14 20:44:10] [John Doe]: removed zone test.com.
For example, if you change the ddns_updater_list for the zone test.com to a new list as follows:
[ name = "update 2" , address="1.1.1.20"]
[ name = "update 4" , address="1.1.1.2"]
[ name = "update 3" , address="1.1.1.3"]
The audit log is:
[Feb 16 09:47:57] [John Doe]: changed zone test.com's ddns_updater_list to [[ name =
"update 2" , address="1.1.1.20"], [ name = "update 4" , address="1.1.1.2"], [ name =
"update 3" , address="1.1.1.3"]].
[Feb 16 09:47:57] [John Doe]: restarted DNS service.
Using the Replication Log
The Replication Status panel reports the status of the database replication between grid members and master. The
Replication Status panel reports the status of the database replication between grid members and master, and
between the two nodes in an independent HA pair. You can use this information to check the health of grid and HA
pair activity.
To view the replication log:
1. From the Grid perspective, click grid -> View -> Replication Status.
or
From the Device perspective, click hostname -> View -> Replication Status .
2. To refresh the contents in the Replication Log viewer, click View -> Refresh (or press the F5 key).
122
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Monitoring Tools
Using the Traffic Capture Tool
You can capture the traffic on one or all of the ports on an Infoblox device, and then view it using a third-party network
protocol analyzer application, such as the Ethereal – Network Protocol Analyzer™.
The Infoblox device saves all the traffic it captures into a .cap file and compresses it into a .tar.gz file. Your
management system must have a utility that can extract the .tar file from the .gzip file, and an application that can
read the .cap (capture) file format. This section explains the process of first capturing traffic, and then downloading
it to your management system. After that, you can extract the traffic capture file and view it with a third-party traffic
analyzer application.
Note: The Infoblox device always saves a traffic capture file as tcpdumpLog.tar.gz. If you want to download multiple
traffic capture files to the same location, rename each downloaded file before downloading the next.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
123
Monitoring the Device
1. From the Grid perspective, click -> + (for grid) -> + (for Members) -> member -> Tools -> Capture Traffic.
or
From the Device perspective, click hostname -> Tools -> Capture Traffic.
2. In the Traffic Capture dialog box, enter the following:
— HA port: Select to capture all traffic that the HA port receives and transmits.
— LAN port: Select to capture all traffic that the LAN port receives and transmits.
— MGMT port: Select to capture all traffic that the MGMT port receives and transmits.
— All ports (promiscuous mode not supported): Select to capture traffic addressed to all ports. Note that the
Infoblox device only captures traffic that is addressed to it.
— Seconds to run: Specify the number of seconds that you want the traffic capture tool to run.
3. Click Start.
A message appears warning that the use of the traffic capture tool causes a decrease in network service
processing and prompts you to confirm your use of the tool.
4. Click Yes.
5. When you want to view the captured traffic, click Download.
6. Another message appears stating that clicking Download causes the traffic capture operation (if it is still ongoing)
to stop and asks if you want to proceed.
7. Click OK.
8. Navigate to where you want to save the file, rename it if you want, and then click OK or Save.
9. Use terminal window commands (Linux) or a software application (such as StuffIt™ or WinZip™) to extract the
contents of the .tar.gz file.
10. When you see the traffic.cap file in the directory where you extracted the .tar.gz file, open it with the third-party
network protocol analyzer application.
124
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 6 Monitoring with SNMP
This chapter describes how you can use SNMP (Simple Network Management Protocol) to monitor Infoblox devices
in your network. It contains the following sections:
•
•
•
•
Understanding SNMP on page 126
SNMP MIB Hierarchy on page 127
— MIB Objects on page 128
Infoblox MIBs on page 129
— Loading the Infoblox MIBs on page 129
— ibTrapOne MIB on page 130
— ibPlatformOne MIB on page 138
— ibDHCPOne MIB on page 143
— ibDNSOne MIB on page 146
Configuring SNMP on page 148
— Accepting SNMP Queries on page 148
— Setting System Information on page 148
— Adding SNMP Trap Receivers on page 149
— Configuring SNMP for a Grid Member on page 149
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
125
Monitoring with SNMP
Understanding SNMP
SNMP (Simple Network Management Protocol) is a protocol that administrators use to manage network devices and
monitor their processes. An SNMP-managed device, such as an Infoblox device, has an SNMP agent that collects data
and stores them as objects in MIBs (Management Information Bases). The SNMP agent can also send traps (or
notifications) to alert you when certain events occur within the device or on the network. You can view data in the
SNMP MIBs and receive SNMP traps on a management system running an SNMP management application, such as
HP OpenView, IBM Tivoli NetView, or any of the freely available or commercial SNMP management applications on
the Internet.
Figure 6.1 SNMP Overview
Traps
Queries
SNMP Management System
Infoblox Device
MIB
MIB
MIB
Agent
MIB
MIB
You can configure an Infoblox device as an SNMP-managed device. Infoblox devices support SNMP versions 1 and 2,
and adhere to the following RFCs:
•
•
•
•
•
•
•
126
RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) Management
Frameworks
RFC 3412, Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
RFC 3413, Simple Network Management Protocol (SNMP) Applications
RFC 3416, Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
RFC 3418, Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
RFC 1155, Structure and identification of Management information for TCP/IP-based internets
RFC 1213, Management Information Base for Network Management of TCP/IP-based internets:MIB-II
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
SNMP MIB Hierarchy
SNMP MIB Hierarchy
Infoblox supports the standard MIBs defined in RFC-1213, Management Information Base for Network Management
of TCP/IP-based internets: MIB-II, in addition to implementing its own enterprise MIBs. The Infoblox MIBs are part of
a universal hierarchical structure, usually referred to as the MIB tree. The MIB tree has an unlabeled root with three
subtrees. Figure 6.2 illustrates the branch of the MIB tree that leads to the Infoblox enterprise MIBs. Each object in
the MIB tree has a label that consists of a textual description and an OID (object identifier); an OID is a unique
dotted-decimal number that identifies the location of the object in the MIB tree. (Note that all OIDs begin with a dot
(.) to indicate the root of the MIB tree.)
As shown in Figure 6.2, Infoblox is a branch of the Enterprise subtree. IANA (Internet Assigned Numbers Authority)
administers the Enterprise subtree, which is designated specifically for vendors who define their own MIBs. The
IANA-assigned enterprise number of Infoblox is 7799; therefore, the OIDs of all Infoblox MIB objects begin with the
prefix .1.3.6.1.4.1.7779.
The Infoblox SNMP subtree branches down through two levels, ibProduct and ibOne, to the Infoblox MIBs: ibTrapOne,
ibPlatformOne, ibDNSone, and ibDHCPOne. The ibTrapOne MIB defines the traps that Infoblox devices send, and the
ibPlatformOne, ibDNSone, and ibDHCPOne MIBs provide information about the device. For detailed information
about these MIBS, see Infoblox MIBs on page 129.
Figure 6.2 MIB Hierarchy
(.0)
International Telegraph and
Telephone Consultative Committee
(CCITT)
(.1)
International Organization
for Standardization (ISO)
(.0)
CCITT and ISO
(.1.3)
ORG
(.1.3.6)
U.S. Department of Defense (DOD)
(.1.3.6.1)
Internet
(.1.3.6.1.4)
Private
(.1.3.6.1.4.1)
Enterprise
(.1.3.6.1.4.1.7779)
Infoblox
(.1.3.6.1.4.1.7779.3)
Infoblox SNMP Tree
(.1.3.6.1.4.1.7779.3.1)
ibProduct
(.1.3.6.1.4.1.7779.3.1.1)
ibOne
(.1.3.6.1.4.1.7779.3.1.1.1) (.1.3.6.1.4.1.7779.3.1.12) (.1.3.6.1.4.1.7779.3.1.1.3) (.1.3.6.1.4.1.7779.3.1.1.4)
ibTrapOne
ibPlatformOne
ibDNSOne
ibDHCPOne
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
127
Monitoring with SNMP
MIB Objects
The Infoblox MIB objects were implemented according to the guidelines in RFCs 1155 and 2578. They specify two
types of macros for defining MIB objects: OBJECT-TYPE and NOTIFICATION-TYPE. These macros contain clauses that
describe the characteristics of an object, such as its syntax and its status. OBJECT-TYPE macros describe MIB objects,
and NOTIFICATION-TYPE macros describe objects used in SNMP traps.
Each object in the ibPlatformOne, ibDNSone, and ibDHCPOne MIBs contain the following clauses from the
OBJECT-TYPE macro:
•
OBJECT-TYPE: Provides the administratively-assigned name of the object.
•
SYNTAX: Identifies the data structure of the object, such as integers, counters, and octet strings.
•
MAX-ACCESS: Identifies the type of access that a management station has to the object. All Infoblox MIB objects
provide read-only access.
•
STATUS: Identifies the status of the object. Values are current, obsolete, and deprecated.
•
DESCRIPTION: Provides a textual description of the object.
•
INDEX or AUGMENTS: An object that represents a conceptual row must have either an INDEX or AUGMENTS
clause that defines a key for selecting a row in a table.
•
OID: The dotted decimal object identifier that defines the location of the object in the universal MIB tree.
The ibTrapOne MIB defines the SNMP traps that an Infoblox device can send. Each object in the ibTrapOne MIB
contains the following clauses from the NOTIFICATION-TYPE macro:
•
NOTIFICATION-TYPE: Provides the administratively-assigned name of the object.
•
OBJECTS: Provides an ordered list of MIB objects that are in the trap.
•
STATUS: Identifies the status of the object. Values are current, obsolete, and deprecated.
•
DESCRIPTION: Provides the notification information.
128
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Infoblox MIBs
You can configure an Infoblox device as an SNMP-managed device so an SNMP management station can send queries
to the device and retrieve information from its MIBs. Perform the following tasks to access the Infoblox MIBs:
1. Configure an Infoblox device to accept queries, as described in Accepting SNMP Queries on page 148.
2. Load the MIB files onto the management system. To obtain the latest Infoblox MIB files, access the Downloads
page of the Infoblox Support website at http://www.infoblox.com/support/.
3. Use a MIB browser or SNMP management application to query the objects in each MIB.
The Infoblox device allows read-only access to the MIBs. This is equivalent to the Get and Get Next operations in
SNMP.
Loading the Infoblox MIBs
If you are using an SNMP manager toolkit with strict dependency checking, you must load the Infoblox MIBs in the
order they are listed:
1. IB-SMI-MIB.txt
2. IB-TRAP-MIB.txt
3. IB-PLATFORMONE-MIB.txt
4. IB-DNSONE-MIB.txt
5. IB-DHCPONE-MIB.txt
In addition, if the SNMP manager toolkit requires a different MIB file naming convention, you can rename the MIB files
accordingly.
NET-SNMP MIBs
Infoblox devices support NET-SNMP (formerly UCD-SNMP), a collection of applications used to implement the SNMP
protocol. When you download the Infoblox MIBs from the Infoblox Support site, you can download some of the
NET-SNMP MIBs and load them onto your SNMP management system. The NET-SNMP MIBs provide the top-level
infrastructure for the SNMP MIB tree. They define, among other things, the objects in the SNMP traps that the agent
sends when the SNMP engine starts and stops. For additional information on NET-SNMP and the MIB files distributed
with NET-SNMP, refer to http://net-snmp.sourceforge.net/.
RADIUS MIBs
The Infoblox device supports the RADIUS-ACC-SERVER-MIB and RADIUS-AUTH-SERVER-MIB. You can download these
MIBs along with the Infoblox enterprise MIBs. When you install the RADIUS server license on the device and configure
RADIUS services, the appliance responds to queries for data from the RADIUS MIBs, if configured to do so. For
information on these MIBs, refer to RFC 2619, RADIUS Authentication Server MIB and RFC 2621, RADIUS Accounting
Server MIB.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
129
Monitoring with SNMP
ibTrapOne MIB
The ibTrapOne MIB defines the different types of traps that an Infoblox device can send. Figure 6.3 illustrates the
ibTrapOne MIB structure. It provides both the OID and textual description of each object. (Note that the OIDs shown
in the illustration do not include the prefix .1.3.6.1.4.1.7779.)
The ibTrapOne MIB comprises two subtrees, ibTrapbOneModule and ibNotificationVarBind. ibTraponeModule
contains the different types of traps that the device can send. Each trap then branches into its own subtree, as
described in the sections that follow. ibNotificationVarBind contains the objects that are reported in the traps. You
cannot send queries for the objects in this MIB module. These are only used in Infoblox traps.
Figure 6.3 ibTrapOne MIB Structure
(3.1.1.1) ibTrapOne MIB
(3.1.1.1.1)
ibTrapOneModule
(3.1.1.1.1.1)
ibEquipmentFailure Trap
(3.1.1.1.1.2)
ibProcessingFailure Trap
(3.1.1.1.1.3)
ibThresholdCrossing Trap
(3.1.1.1.1.4)
ibStateChangeEvent Trap
(3.1.1.1.1.5)
ibProcStartStop Trap
(3.1.1.1.2)
ibNotificationVarBind
(3.1.1.1.2.1)
ibNodeName
(3.1.1.1.2.2)
ibTrapSeverity
(3.1.1.1.2.3)
ibObjectName
(3.1.1.1.2.4)
ibProbableCause
(3.1.1.1.2.5)
ibSubsystem
(3.1.1.1.2.6)
ibThresholdValue
(3.1.1.1.2.7)
ibThresholdHigh
(3.1.1.1.2.8)
ibThresholdLow
(3.1.1.1.2.9)
ibPreviousState
(3.1.1.1.2.10)
ibCurrntState
(3.1.1.1.2.11)
ibTrapDesc
130
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Table 6.1 describe the objects in the ibTrapbOneModule subtree.
Table 6.1 ibTrapOneModule
Object
Description
ibEquipment Failure Trap
The Infoblox device does not send this type of trap.
ibProcessingFailure Trap
The Infoblox device generates this type of trap when a
failure occurs in one of the software processes. For
additional information, see Processing Failure Trap on
page 132.
ibThresholdCrossing Trap
An Infoblox device generates this trap when either the
system memory or hard disk usage exceeds 90%, and
when DHCP address usage crosses a watermark threshold.
For additional information, see Threshold Crossing Event
Trap on page 135.
ibStateChangeEvent
An Infoblox device generates this type of trap when certain
events occur, such as an HA failover or a link to a port goes
up or down. For additional information, see State Change
Trap on page 136.
ibProcStartStopTrap
An Infoblox device generates this type of trap when an
administrator changes the HTTP settings causing the HTTP
process starts and stops. For detailed information about
this trap, see Process Start/Stop Trap on page 137.
Table 6.2 describes the objects in the ibNotificationVarBind tree. The device reports on these objects when it sends
traps.
Table 6.2 ibNotificationVarBind
Object
Description
ibNodeName
The IP address of the device on which the event that triggered the trap
occurred. This may or may not be the same as the device that sent the trap. This
object is used in all the traps.
ibTrapSeverity
Indicates the severity of the trap. This object is used in the Processing Failure
trap.
ibObjectName
The name of the object for which the trap was generated. This object is used in
the Threshold Crossing Event trap and the State Change Event trap.
ibProbableCause
Describes the probable cause of the problem. This object is used in the
Processing Failure trap.
ibSubsystemName
Identifies the subsystem for which the trap was generated. This object is used
in the Processing Failure trap and the Process Start/Stop trap.
ibCurThresholdValue
The current value of the threshold counter. This objects is used in the
Threshold Crossing Event trap
ibThresholdHigh
The configured high watermark value. This objects is used in the Threshold
Crossing Event trap
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
131
Monitoring with SNMP
Object
Description
ibThresholdLow
The configured low watermark value. This object is used in the Threshold
Crossing Event trap
ibPreviousState
The previous status of the device. This object is used in the State Change Event
trap.
ibCurrentState
The current status of the device. This object is used in the State Change Event
trap.
ibTrapDesc
Description of the trap. This object is used in all the traps.
Processing Failure Trap
The Infoblox device generates this type of trap when a failure occurs in one of the software processes. The device
includes certain objects from ibNotificationVarBind when it sends this type of trap. The following table lists the
objects and their corresponding values.
Table 6.3 Processing Failure Trap Objects
Object
Description
ibNodeName
The name or IP address of the device on which the the event that triggered the
trap occurred.
ibTrapSeverity
Severity level of the trap. Values are:
1
Undetermined
2
Informational
3
Minor problem that does not require user intervention.
4
Major problem that requires user intervention. The device sends
processing failure traps with this severity level when there is a failure
in the following processes: NTPD, SNMPD, SSHD, serial console, and
LCD daemon.
5
Critical problem that impacts service. The device sends processing
failure traps with this severity level when there is a failure in the
following processes: ControlD, ClusterD, named, dhcpd, freeradiusd,
httpd, tftpd, radiusd, radius, winbindd, VitalQIP remote server, and
netbiosd.
ibProbableCause
Identifies the cause of the problem. See Table 6.4 for detailed information.
ibSubsystemName
Identifies the subsystem for which the trap was generated, such as NTP or
SNMP. See Table 6.4 for detailed information.
ibTrapDesc
Describes the software failure that occurred. See Table 6.4 for detailed
information.
132
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Table 6.4 lists the values associated with the ibProbableCause, ibSubsystemName and ibTrapDesc objects. These
values provide information about the software failure that triggered the trap.
Table 6.4 ibProbableCause, ibSubsystemName and ibTrapDesc Values
Valu
e
ibProbableCause
ibSubsystemName
ibTrapDesc
0
ibClear
Uses the original
ibObjectName and
ibSubsystemName
when the trap is
cleared.
SNMP trap is cleared.
1
ibUnknown
N/A
An unknown failure has occurred.
2
ibPrimaryDiskFailure
N/A
A primary disk failure has occurred.
3
ibFanFailure
N/A
A fan failure has occurred.
4
ibPowerSupplyFailure
N/A
A power supply failure has occurred.
5
ibDBFailure
Db_jnld
A database daemon monitoring failure has
occurred.
6
ibApacheSoftwareFailure
httpd
An Apache software failure has occurred.
7
ibSerialConsoleFailure
serial_console
An Infoblox device serial console failure
has occurred.
11
ibControldSoftwareFailure
controld
A controld failure has occurred.
12
ibUpgradeFailure
N/A
A system upgrade failure has occurred.
13
ibSNMPDFailure
Snmpd
SNMP failure has occurred.
15
ibSSHDSoftwareFailure
Sshd
An SSH daemon failure has occurred.
16
ibNTPDSoftwareFailure
Ntpd
An NTP daemon failure has occurred.
17
ibClusterdSoftwareFailure
Clusterd
A CLUSTER daemon failure has occurred.
18
ibLCDSoftwareFailure
Lcd
An LCD daemon failure has occurred.
19
ibDHCPdSoftwareFailure
Dhcpd
A DHCP daemon monitoring failure has
occurred.
20
ibNamedSoftwareFailure
Named
A named daemon monitoring failure has
occurred.
21
ibSlapdSoftwareFailure
Slapd
A SLAP daemon failure has occurred.
22
ibSlurpdSoftwareFailure
Slurpd
A SLURP daemon failure has occurred.
23
ibRadiusdSoftwareFailure
Radiusd
A RADIUS daemon monitoring failure has
occurred.
24
ibNTLMSoftwareFailure
NTLM
An NTLM monitoring failure has occurred.
25
ibNetBIOSDaemonFailure
Netbiosd
A NetBIOS daemon monitoring failure has
occurred.
26
ibWindowBindDaemonFailure
Winbindd
An NT domain service monitoring failure
has occurred.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
133
Monitoring with SNMP
Valu
e
ibProbableCause
ibSubsystemName
ibTrapDesc
27
ibTFTPDSoftwareFailure
Tftpd
A TFTPD Daemon failure has occurred.
28
ibQIPRemoteServerSoftwareFailure
QIP
A VitalQIP software failure has occurred.
29
ibBackupSoftwareFailure
N/A
A backup failure has occurred.
30
ibBackupDatabaseSoftwareFailure
N/A
A database backup failed.
31
ibBackupModuleSoftwareFailure
N/A
A module backup failed.
32
ibBackupSizeSoftwareFailure
N/A
File size exceeded the quote. Backup
failed.
33
ibBackupLockSoftwareFailure
N/A
Another backup is in progress.
34
ibHTTPFileDistSoftwareFailure
HTTPd
A failure occurred during software
distribution.
35
ibOSPFSoftwareFailure
OSPF
An OSPF routing daemon failure has
occurred.
36
ibAuthDHCPNamedSoftwareFailure
N/A
An authenticated DHCP failure occurred.
3001
ibRAIDIsOptimal
N/A
The RAID array is functioning properly.
3002
ibRAIDIsDegraded
N/A
The RAID array is degraded. At lease one
disk is not functioning properly.
3003
ibRAIDIsRebuilding
N/A
A new disk was inserted and the RAID array
is rebuilding.
3004
ibRAIDStatusUnknown
N/A
The device is unable to retrieve the RAID
array state.
3005
ibRAIDBatteryIsOK
N/A
The battery is charged.
3006
ibRAIDBatteryFailed
N/A
A battery failure has occurred.
134
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Threshold Crossing Event Trap
The Infoblox device generates this trap when any of the following events occur:
•
System memory or hard disk usage exceeds 90%
•
There is a problem when the grid master replicates its database to its grid members
•
DHCP address usage crosses a watermark threshold (For more information about tracking IP address usage, see
Chapter 16, Managing IP Data – IPAM, on page 419.)
Table 6.5 describes the objects from ibNotificationVarBind that the device includes when it sends a threshold
crossing event trap.
Table 6.5 Threshold Crossing Event Trap Objects
Object
Description
ibNodeName
Identifies the device on which the event occurred.
ibObjectName
Identifies the object that generated the trap. See Table 6.6 for detailed
information.
ibCurThresholdValue
The current value of a threshold counter.
ibThresholdHigh
The value for the high threshold. This only applies when the device sends a
trap to indicate that the DHCP address usage is above the configured high
threshold value for a DHCP address range. For additional information, see
Setting Watermark Properties on page 426.
ibThresholdLow
The value for the low threshold. This only applies when the device sends a trap
to indicate that the DHCP address usage went below the configured low
threshold value for a DHCP address range. For additional information, see
Setting Watermark Properties on page 426.
IbTrapDesc
Description of the event that triggered the trap. See Table 6.6 for detailed
information.
Table 6.6 lists the values associated with the ibObjectName and ibTrapDesc objects. These values provide
information about the event that triggered the trap.
Table 6.6 ibObjectName and ibTrapDesc Values
Event
ibObjectName
ibTrapDesc
Disk full
Disk usage
Primary drive is full.
The device is out of memory
Memory
System ran out of memory.
CPU usage is high
Not used
CPU utility over 90%
System memory usage goes
above 90%
Memory
System memory usage over 90%
Disk usage goes above 85%
Disk usage
System primary hard disk usage over 85%
Replication problem
Cluster Send
Queue or Cluster
Receive Queue
Grid queue replication problem
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
135
Monitoring with SNMP
Event
ibObjectName
IP address usage for a DHCP
range goes above the
specified high watermark
IP address usage for a DHCP
range drops below the
specified low watermark for a
second time
ibTrapDesc
DHCP threshold crossed.
Threshold
DHCP threshold crossed
State Change Trap
An Infoblox device generates this type of trap when there is a change in its status, such as:
•
The link to one of the configured ports goes down, and then goes back up again
•
A failover occurs in an HA (high availability) pair configuration
•
A member connects to the grid master
•
A device in a grid physically goes offline
Table 6.7 describes the objects from ibNotificationVarBind that the device includes when it sends a state change
trap.
Table 6.7 State Change Trap Objects
Object
Description
ibNodeName
Identifies the device on which the event occurred.
ibObjectName
Identifies the object that generated the trap.
ibPreviousState
Indicates the status of the device before the event that triggered the trap. Valid
values are:
1
ha-active
2
ha-passive
3
ha-initial
4
grid-connected
5
grid-disconnected
6
enet-link-up
7
enet-link-down
8
replication-online
9
replication-offline
10 replication-snapshotting
11 service-up
12 service-down
13 ha-replication-online
14 ha-replication-offline
See Table 6.8 for detailed information.
ibCurrentState
Indicates the current status of the device. See Table 6.8 for detailed
information.
IbTrapDesc
Description of the event that generated the trap.
136
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Table 6.8 lists the values associated with the ibPreviousState and ibCurrentState objects. These values provide
information about the event that triggered the trap.
Table 6.8 ibPreviousState and ibCurrentState Values
Event
ibObjectName
ibTrapDesc
A node in an HA pair becomes active
when it first goes online
High Availability
The node has become ACTIVE.
A node in an HA pair becomes passive
when it first goes online
High Availability
The node has become PASSIVE.
The status of a node in an HA pair
changed from active to passive
High Availability
The node has become ACTIVE.
The status of a node in an HA pair
changed from passive to active
High Availability
The node has become PASSIVE.
A device connects to a grid master.
Grid
The node is connected to the grid master.
A member disconnects from the grid
master
Grid
The node is not connected to the grid
master.
Process start
Not used
The process started normally.
Process stop
Not used
The process stopped normally.
Database replication to grid member
was aborted (is offline)
Cluster
Replication queue became offline.
LAN port down
Enet link status
LAN port link is down, please check the
connection.
HA port down
Enet link status
HA port link is down, please check the
connection.
MGT port down
Enet link status
MGMT port link is down, please check the
connection.
Database shutdown
Cluster
Shutting down services due to database
snapshot.
The passive node in an independent
HA pair is downloading the database
from the active node
HA Replication
HA replication online
Database replication to the passive
node in an independent HA pair was
aborted
HA Replication
HA replication offline
Process Start/Stop Trap
An Infoblox device generates this type of trap when any of the following events occur:
•
When you enable HTTP redirection
•
When you change the HTTP access settings
•
When you change the HTTP session time out settings
•
When a failover occurs in an HA (high availability) pair configuration
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
137
Monitoring with SNMP
The device includes the following objects when it sends a process start/stop trap:
Table 6.9 Process Start/Stop Trap Objects
Object
Description
ibNodeName
The IP address of the device on which the event occurred.
ibSubsystemName
Identifies the subsystem for which the trap was generated. Values are httpd
and ha.
IbTrapDesc
Description of the event that generated the trap. Values are:
•
The process started normally.
•
The process stopped normally.
ibPlatformOne MIB
The ibPlatformOne MIB provides information about the CPU temperature of the device, the replication status, and the
average latency of DNS requests. Figure 6.4 illustrates the structure of the PlatformOne MIB. (Note that the OIDs in
the illustration do not include the prefix .1.3.6.1.4.1.7779.) The ibPlatformOne MIB branches out into three subtrees:
•
ibCPUTemperature tracks the CPU temperature of the device
•
ibClusterReplicationStatusTable provides information in tabular format about the replication status of the
device. See ibClusterReplicationStatusTable on page 139 for more information.
•
ibNetworkMonitor provides information about the average latency of authoritative and nonauthoritative replies
to DNS queries for different time intervals. See ibNetwork Monitor on page 139 for more information.
Figure 6.4 PlatformOneMIB Structure
(3.1.1.2) ibPlatformOne MIB
(3.1.1.2.1) ibPlatformOneModule
(3.1.1.2.1.1)
ibCPUTemperature
(3.1.1.2.1.2)
ibClusterReplicationStatusTable
(3.1.1.2.1.2.1)
ibClusterReplicationStatusEntry
(3.1.1.2.1.3)
ibNetworkMonitor
(3.1.1.2.1.3.1)
ibNetworkMonitorDNS
(3.1.1.2.1.2.1.1)
ibNodeIPAddress
(3.1.1.2.1.3.1.1)
ibNetworkMonitorDNSActive
(3.1.1.2.1.2.1.2)
ibNodeReplicationStatus
(3.1.1.2.1.3.1.2)
ibNetworkMonitorDNSNonAA
(3.1.1.2.1.2.1.3)
ibNodeQueueFromMaster
(3.1.1.2.1.3.1.3)
ibNetworkMonitorDNSAA
(3.1.1.2.1.2.1.4)
ibNodeLastRepTimeFromMaster
(3.1.1.2.1.2.1.5)
ibNodeQueuToMaster
(3.1.1.2.1.2.1.6)
ibNodeLastRepTimeToMaster
138
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
ibClusterReplicationStatusTable
This table provides information about the grid replication status.
Table 6.10 ibClusterReplicationStatusTable Objects
Object
Description
ibClusterReplicationStatusEntry
A conceptual row that provides information about the grid replication status.
ibNodeIPAddress
IP address of a grid member
ibNodeReplicationStatus
Replication status of the grid member
ibNodeQueueFromMaster
“Sent” queue size from master
ibNodeLastRepTimeFromMaster
Last sent time from master
ibNodeQueueToMaster
“Receive” queue size from master
ibNodeLastRepTimeToMaster
Last receive time from master
ibNetwork Monitor
As shown in Figure 6.4, the ibNetwork Monitor has one subtree, ibNetworkMonitorDNS, that branches out into the
following:
•
ibNetworkMonitorDNSActive reports on whether DNS latency monitoring is enabled. This is the only object in
this branch. When you send a query for this object, the device responds with either “active” or “nonactive”.
•
ibNetworkMonitorDNSNonAA provides information about the average latency of nonauthoritative replies to DNS
queries for 1-, 5-, 15-, and 60-minute intervals.
•
ibNetworkMonitorDNSAA provides information about the average latency of authoritative replies to DNS queries
for 1-, 5-, 15-, and 60-minute intervals.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
139
Monitoring with SNMP
Figure 6.5 ibNetworkMonitorDNSNonAA and ibNetworkMonitorDNSAA Subtrees
(3.1.1.2.1.3.1.2)
ibNetworkMonitorDNSNonAA
(3.1.1.2.1.3.1.2.1)
ibNetworkMonitorDNSNonAAT1
(3.1.1.2.1.3.1.3.1)
ibNetworkMonitorDNSAAT1
(3.1.1.2.1.3.1.2.1.1)
ibNetworkMonitorDNSNonAAT1AvgLatency
(3.1.1.2.1.3.1.3.1.1)
ibNetworkMonitorDNSAAT1AvgLatency
(3.1.1.2.1.3.1.2.1.2)
ibNetworkMonitorDNSNonAAT1Count
(3.1.1.2.1.3.1.3.1.2)
ibNetworkMonitorDNSAAT1Count
(3.1.1.2.1.3.1.2.2)
ibNetworkMonitorDNSNonAAT5
(3.1.1.2.1.3.1.3.2)
ibNetworkMonitorDNSNonAAT5
(3.1.1.2.1.3.1.2.2.1)
ibNetworkMonitorDNSNonAAT5AvgLatency
(3.1.1.2.1.3.1.3.2.1)
ibNetworkMonitorDNSAAT5AvgLatency
(3.1.1.2.1.3.1.2.2.2)
ibNetworkMonitorDNSNonAAT5Count
(3.1.1.2.1.3.1.3.2.2)
ibNetworkMonitorDNSAAT5Count
(3.1.1.2.1.3.1.2.3)
ibNetworkMonitorDNSNonAAT15
(3.1.1.2.1.3.1.3.3)
ibNetworkMonitorDNSAAT15
(3.1.1.2.1.3.1.2.3.1)
ibNetworkMonitorDNSNonAAT15AvgLatency
(3.1.1.2.1.3.1.3.3.1)
ibNetworkMonitorDNSAAT15AvgLatency
(3.1.1.2.1.3.1.2.3.2)
ibNetworkMonitorDNSNonAAT15Count
(3.1.1.2.1.3.1.3.3.2)
ibNetworkMonitorDNSAAT15Count
(3.1.1.2.1.3.1.2.4)
ibNetworkMonitorDNSNonAAT60
(3.1.1.2.1.3.1.3.4)
ibNetworkMonitorDNSAAT60
(3.1.1.2.1.3.1.2.4.1)
ibNetworkMonitorDNSNonAAT60AvgLatency
(3.1.1.2.1.3.1.3.4.1)
ibNetworkMonitorDNSAAT60AvgLatency
(3.1.1.2.1.3.1.2.4.2)
ibNetworkMonitorDNSNonAAT60Count
(3.1.1.2.1.3.1.3.4.2)
ibNetworkMonitorDNSAAT60Count
(3.1.1.2.1.3.1.2.5)
ibNetworkMonitorDNSNonAAT1440
140
(3.1.1.2.1.3.1.3)
ibNetworkMonitorDNSAA
(3.1.1.2.1.3.1.3.5)
ibNetworkMonitorDNSAAT1440
(3.1.1.2.1.3.1.2.5.1)
ibNetworkMonitorDNSNonAAT1440AvgLatency
(3.1.1.2.1.3.1.3.5.1)
ibNetworkMonitorDNSAAT1440AvgLatency
(3.1.1.2.1.3.1.2.5.2)
ibNetworkMonitorDNSNonAAT1440Count
(3.1.1.2.1.3.1.3.5.2)
ibNetworkMonitorDNSAAT1440Count
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Table 6.11 describes the objects in ibNetworkMonitorDNSNonAA. You can send queries to retrieve values for these
objects.
Table 6.11 ibNetworkMonitorDNSNonAA Objects
Object
Description
ibNetworkMonitorDNSNonAAT1
File that contains the objects for monitoring the average latency
of nonauthoritative replies to queries during the last minute.
ibNetworkMonitorDNSNonAAT1AvgLatency
Indicates the average latency in microseconds of
nonauthoritative replies to queries during the last minute.
ibNetworkMonitorDNSNonAAT1Count
Indicates the number of queries used to calculate the average
latency of nonauthoritative replies during the last minute.
ibNetworkMonitorDNSNonAAT5
File that contains the objects for monitoring the average latency
of nonauthoritative replies to queries during the last five
minutes.
ibNetworkMonitorDNSNonAAT5AvgLatency
Indicates the average latency in microseconds of
nonauthoritative replies to queries during the last five minutes.
ibNetworkMonitorDNSNonAAT5Count
Indicates the number of queries used to calculate the average
latency of nonauthoritative replies during the last five minutes.
ibNetworkMonitorDNSNonAAT15
File that contains the objects for monitoring the average latency
of nonauthoritative replies to queries during the last 15 minutes.
ibNetworkMonitorDNSNonAAT15AvgLatency
Indicates the average latency in microseconds of
nonauthoritative replies to queries during the last 15 minutes.
ibNetworkMonitorDNSNonAAT15Count
Indicates the number of queries used to calculate the average
latency of nonauthoritative replies during the last 15 minutes.
ibNetworkMonitorDNSNonAAT60
File that contains the objects for monitoring the average latency
of nonauthoritative replies to queries during the last 60 minutes.
ibNetworkMonitorDNSNonAAT60AvgLatency
Indicates the average latency in microseconds of
nonauthoritative replies to queries during the last 60 minutes.
ibNetworkMonitorDNSNonAAT60Count
Indicates the number of queries used to calculate the average
latency of nonauthoritative replies during the last 60 minutes.
ibNetworkMonitorDNSNonAAT1440
File that contains the objects for monitoring the average latency
of nonauthoritative replies to queries during the last 1440
minutes.
ibNetworkMonitorDNSNonAAT1440AvgLatency
Indicates the average latency in microseconds of
nonauthoritative replies to queries during the last 1440 minutes.
ibNetworkMonitorDNSNonAAT1440Count
Indicates the number of queries used to calculate the average
latency of nonauthoritative replies during the last 1440 minutes.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
141
Monitoring with SNMP
Table 6.12 describes the objects in ibNetworkMonitorDNSAA. You can send queries to retrieve values for these
objects.
Table 6.12 ibNetworkMonitorDNSAA Objects
Object
Description
ibNetworkMonitorDNSAAT1
File that contains the objects for monitoring the average latency
of authoritative replies to queries during the last minute.
ibNetworkMonitorDNSAAT1AvgLatency
Indicates the average latency in microseconds of authoritative
replies to queries during the last minute.
ibNetworkMonitorDNSAAT1Count
Indicates the number of queries used to calculate the average
latency of authoritative replies during the last minute.
ibNetworkMonitorDNSAAT5
File that contains the objects for monitoring the average latency
of authoritative replies to queries during the last five minutes.
ibNetworkMonitorDNSAAT5AvgLatency
Indicates the average latency in microseconds of authoritative
replies to queries during the last five minutes.
ibNetworkMonitorDNSAAT5Count
Indicates the number of queries used to calculate the average
latency of authoritative replies during the last five minutes.
ibNetworkMonitorDNSAAT15
File that contains the objects for monitoring the average latency
of authoritative replies to queries during the last 15 minutes.
ibNetworkMonitorDNSAAT15AvgLatency
Indicates the average latency in microseconds of authoritative
replies to queries during the last 15 minutes.
ibNetworkMonitorDNSAAT15Count
Indicates the number of queries used to calculate the average
latency of authoritative replies during the last 15 minutes.
ibNetworkMonitorDNSAAT60
File that contains the objects for monitoring the average latency
of authoritative replies to queries during the last 60 minutes.
ibNetworkMonitorDNSAAT60AvgLatency
Indicates the average latency in microseconds of authoritative
replies to queries during the last 60 minutes.
ibNetworkMonitorDNSAAT60Count
Indicates the number of queries used to calculate the average
latency of authoritative replies during the last 60 minutes.
ibNetworkMonitorDNSAAT1440
File that contains the objects for monitoring the average latency
of authoritative replies to queries during the last 1440 minutes.
ibNetworkMonitorDNSAAT1440AvgLatency
Indicates the average latency in microseconds of authoritative
replies to queries during the last 1440 minutes.
ibNetworkMonitorDNSAAT1440Count
Indicates the number of queries used to calculate the average
latency of authoritative replies during the last 1440 minutes.
142
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
ibDHCPOne MIB
The ibDHCPOne MIB provides information about address usage within a subnet, DHCP lease statistics, and DHCP
packet counts. Figure 6.6 illustrates the structure of the ibDHCPOne MIB. (Note that the OIDs shown in the illustration
do not include the prefix .1.3.6.1.4.1.7779.) It has three subtrees: ibDHCPSubnetTable, ibDHCPLeaseTable, and
ibDHCP Statistics.
Figure 6.6 DHCPone MIB
(3.1.1.4) ibDHCPOne MIB
(3.1.1.4.1) ibDHCPModule
(3.1.1.4.1.1)
ibDHCPSubnetTable
(3.1.1.4.1.1.1)
ibDHCPSubnetEntry
(3.1.1.4.1.1.1.1)
ibDHCPSubnetNetworkAddress
(3.1.1.4.1.1.1.2)
ibDHCPSubnetNetworkMask
(3.1.1.4.1.1.1.3)
ibDHCPSubnetPercentUsed
NIOS 4.1r3
(3.1.1.4.1.2)
ibDHCPLeaseTable
(3.1.1.4.1.3)
ibDHCPStatistics
(3.1.1.4.1.2.1)
ibDHCPLeaseEntry
(3.1.1.4.1.3.1)
ibDhcpTotalNoOfDiscov
ers
(3.1.1.4.1.2.1.1)
ibDHCPLeaseAddress
(3.1.1.4.1.3.2)
ibDhcpTotalNoOfRequests
(3.1.1.4.1.2.1.2)
ibDHCPLeaseMACAddress
(3.1.1.4.1.3.3)
ibDhcpTotalNoOfReleases
(3.1.1.4.1.2.1.3)
ibDHCPLeaseStart
(3.1.1.4.1.3.4)
ibDhcpTotalNoOfOffers
(3.1.1.4.1.2.1.4)
ibDHCPLeaseEnd
(3.1.1.4.1.3.5)
ibDhcpTotalNoOfAcks
(3.1.1.4.1.2.1.5)
ibDHCPLeaseBindState
(3.1.1.4.1.3.6)
ibDhcpTotalNoOfNacks
(3.1.1.4.1.2.1.6)
ibDHCPLeaseNextBindState
(3.1.1.4.1.3.7)
ibDhcpTotalNoOfDeclines
(3.1.1.4.1.2.1.7)
ibDHCPLeaseClientHostName
(3.1.1.4.1.3.8)
ibDhcpTotalNoOfInforms
(3.1.1.4.1.2.1.8)
ibDHCPLeaseUID
(3.1.1.4.1.3.9)
ibDhcpTotalNoOthers
Infoblox Administrator Guide (Rev. A)
143
Monitoring with SNMP
The ibDHCPSubnetTable provides statistical data about the DHCP operations of the device. It contains the following
objects:
Table 6.13 ibDHCPSubnetTable
Object
Description
ibDHCPSubnet Entry
File that contains the objects for monitoring DHCP operations on the device.
ibDHCPSubnetNetworkAddress
The subnetworks, in IP address format, that have IP addresses for lease. A
subnetwork may have many address ranges for lease.
ibDHCPSubnetNetworkMask
The subnet mask in dotted decimal format.
ibDHCPSubnetPercentUsed
The percentage of dynamic DHCP addresses leased out at this time for each
subnet. Fixed addresses are always counted as leased for this calculation, if
the fixed addresses are within a leased address range.
Following is an example of the table as viewed through a MIB browser:
Figure 6.7 MIB Browser View 1
The ibDHCPLeaseTable provides statistics about the DHCP leases. It contains the following objects:
Table 6.14 ibDHCPLeaseTable
Object
Description
ibDHCPLeaseEntry
File that contains the objects that provide information about DHCP leases.
ibDHCPLeaseAddress
The IP address issued by DHCP.
ibDHCPLeaseMACAddress
The MAC Address of the DHCP client.
ibDHCPLeaseStart
The start time of the DHCP lease.
ibDHCPLeaseEnd
The end time of the DHCP lease.
ibDHCPLeaseBindState
The IP address binding state of the DHCP lease. The binding state is used by
the DHCP failover protocol and indicates, among other things, whether an IP
address is in use, has been released, or is available for allocation.
ibDHCPLeaseNextBindState
Next Binding state of DHCP lease.
144
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Object
Description
ibDHCPLeaseClientHostName
Client provided host name during DHCP registration.
ibDHCPLeaseUID
Client provided UID during DHCP registration. (The UID is a number that
uniquely identifies the client machine.)
ibDHCP Statistics maintains counters for different types of packets. The counters always start with zero when you
enable DHCP. Therefore the numbers reflect the total number of packets received since DHCP was enabled on the
Infoblox device. The ibDHCPStatistics module contains the following objects:
Table 6.15 ibDHCPStatistics
Object
Description
ibDhcpTotalNoOfDiscovers
The number of DHCPDISCOVER messages that the device received. Clients
broadcast DHCPDISCOVER messages when they need an IP address and
network configuration information.
ibDhcpTotalNoOfRequests
The number of DHCPREQUEST messages that the device received. A client
sends a DHCPREQUEST message requesting configuration information, after it
receives the DHCPOFFER message.
ibDhcpTotalNoOfReleases
The number of DHCPRELEASE messages that the device received from its
clients. A client sends a DHCP release when it terminates its lease on an IP
address.
ibDhcpTotalNoOfOffers
The number of DHCPOFFER messages that the device has sent to clients. The
device sends a DHCPOFFER message to a client. It contains an IP address and
configuration information.
ibDhcpTotalNoOfAcks
The number of DHCPACK messages that the device sent to clients. It sends a
DHCPACK message to a client to confirm that the IP address offered is still
available.
ibDhcpTotalNoOfNacks
The number of DHCPNACK messages that the device sent to clients. It sends a
DHCPNACK message to withdraw its offer of an IP address.
ibDhcpTotalNoOfDeclines
The number of DHCPDECLINE messages that the device received. A client sends
a DHCPDECLINE message if it determines that an offered IP address is already
in use.
ibDhcpTotalNoOfInforms
The number of DHCPINFORM messages that the device received. A client sends
a DHCPINFORM message when it has an IP address but needs information
about the network.
ibDhcpTotalNoOfOthers
The total number of DHCP messages other than those used in negotiation, such
as DHCPFORCERENEW, DHCPKNOWN, and DHCPLEASEQUERY.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
145
Monitoring with SNMP
ibDNSOne MIB
The ibDNSOne MIB provides statistical information about the DNS processes and about the views and zones in the
database. Figure 6.7 illustrates the structure of the ibDNSOne MIB. (Note that the OIDs shown in the illustration do
not include the prefix 1.3.6.1.4.1.7779.) The ibDNSOne MIB contains two subtrees, ibZoneStatisticsTable and the
ibZonePlusViewStatisticsTable.
Figure 6.8 ibDNSOne MIB
(3.1.1.3) ibDNSOne MIB
(3.1.1.3.1) ibDnsModule
(3.1.1.3.1.1)
ibZoneStatisticTable
(3.1.1.3.1.2)
ibZonePlusViewStatisticsTable
(3.1.1.3.1.1.1)
ibZoneStatisticsEntry
(3.1.1.3.1.2.1)
ibZonePlusViewStatisticsEntry
(3.1.1.3.1.1.1.1)
ibBindZoneName
(3.1.1.3.1.2.1.1)
ibZonePlusViewName
(3.1.1.3.1.1.1.2)
ibBindZoneSuccess
(3.1.1.3.1.2.1.2)
ibZonePlusViewSuccess
(3.1.1.3.1.1.1.3)
ibBindZoneReferral
(3.1.1.3.1.2.1.3)
ibZonePlusViewReferral
(3.1.1.3.1.1.1.4)
ibBindZoneNxRRset
(3.1.1.3.1.2.1.4)
ibZonePlusViewNxRRset
(3.1.1.3.1.1.1.5)
ibBindZoneNxDomain
(3.1.1.3.1.2.1.5)
ibZonePlusViewNxDomain
(3.1.1.3.1.1.1.6)
ibBindZoneRecursion
(3.1.1.3.1.2.1.6)
ibZonePlusViewRecursion
(3.1.1.3.1.1.1.7)
ibBindZoneFailure
(3.1.1.4.1.2.1.7)
ibZonePlusViewFailure
(3.1.1.4.1.2.1.8)
ibBindViewName
The ibZoneStatisticsTable provides statistical data about the DNS operations on the device. The following lists the
OIDs and the objects in the table:
Table 6.16 ibZoneStatisticsTable
Object
Description
ibBindZoneName
DNS Zone name.
ibBindZoneSuccess
The number of successful responses since the DNS process started.
ibBindZoneReferral
The number of DNS referrals since the DNS process started.
ibBindZoneNxRRset
The number of DNS queries received for non-existent records.
ibBindZoneNxDomain
The number of DNS queries received for non-existent domains.
146
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Infoblox MIBs
Object
Description
ibBindZoneRecursion
The number of queries received using recursion since the DNS process started.
ibBindZoneFailure
The number of failed queries since the DNS process started.
The ibZonePlusViewStatisticsTable provides statistical data about Infoblox views and their zones. The following table
lists the objects and their OIDS:
Table 6.17 ibZonePlusViewStatisticsTable
Object
Description
ibZonePlusViewName
The zone name. The first one in the default view is the global summary
statistics. Index name for global statistics is “summary.”
ibZonePlusViewSuccess
Number of successful responses since the DNS process started.
ibZonePlusViewReferral
Number of DNS referrals
ibZonePlusViewNxRRset
Number of DNS queries received for non-existent records.
ibZonePlusViewNxDomain
Number of DNS queries received for non-existent domains.
ibZonePlusViewRecursion
Number of DNS recursive queries received
ibZonePlusViewFailure
Number of failed queries
ibBindViewName
View name. This is blank for default view
Following is an example of the table as viewed through a MIB browser:
Figure 6.9 MIB Browser View 2
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
147
Monitoring with SNMP
Configuring SNMP
Perform the following tasks to configure SNMP on the Infoblox device:
•
Enable the Infoblox device to accept queries and define the community string that management systems must
specify when they send queries to the device.
•
Specify the management systems to which the device sends traps.
For a grid, you can perform these tasks at the grid level and at the member level. You can define SNMP settings for an
entire grid, and when necessary, define different SNMP settings for a member. SNMP settings for a member override
SNMP settings for a grid.
You can also set up SNMP on an independent device or HA pair.
Accepting SNMP Queries
You can allow specific management systems to send queries to an Infoblox device. When you do, you must specify a
community string. The device accepts queries only from management systems that provide the correct community
string.
To configure a grid or an independent Infoblox device or HA pair to accept SNMP queries:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Edit -> Member Properties.
or
From the Device perspective, click Device -> host_name -> Edit -> Device Properties.
2. In the Grid or Device editor, click Monitoring, and then enter the following:
— Enable queries: Select this check box for grid members or an independent device or HA pair to accept
queries from SNMP management systems.
— Community String: Enter a text string that the management system must send together with its queries
to the grid or the independent device or HA pair. A community string is similar to a password in that the
device accepts queries only from management systems that send the correct community string. Note
that this community string must match exactly what you enter in the management system.
3. Click the Save icon to save your settings.
Setting System Information
You can enter values for the following managed objects in MIB-II, the standard MIB defined in RFC 1213:
•
sysContact
•
sysLocation
•
sysName
•
sysDescr
After you enter these values on the device, administrators can send queries for these values from management
systems that are allowed to send queries to the device.
To enter system information:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Edit -> Member Properties.
or
From the Device perspective, click Device -> host_name -> Edit -> Device Properties.
2. In the Grid or Device editor, click Monitoring, and then enter the following:
— Set objects: Select check box.
— sysContact: Enter the name of the contact person for the device.
— sysLocation: Enter the physical location of the device.
148
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring SNMP
— sysName: Enter the fully qualified domain name of the device.
— sysDescr: Enter useful information about the device, such as the software version it is running.
3. Click the Save icon to save your settings.
Adding SNMP Trap Receivers
You can enable an Infoblox device to send traps to specific management systems or trap receivers. It sends traps
whenever certain events occur, as described in ibTrapOne MIB on page 130.
To configure an SNMP trap receiver for a grid or an independent device or HA pair:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Edit -> Member Properties.
or
From the Device perspective, click Device -> host_name -> Edit -> Device Properties.
2. In the Grid or Device editor, click Monitoring, and then enter the following:
— Enable traps: Select the check box to enable grid members or an independent device or HA pair to send
traps to specified SNMP management systems.
— Community String: Enter a text string that the Infoblox device sends to the management system
together with its traps. Note that this community string must match exactly what you enter in the
management system.
— Trap Receiver Group: Type an address of an SNMP management system to which you want the SNMP
agent on grid members and independent devices to send traps in the IP Address field, and then click
Add. (You can enter more than one trap receiver.)
To remove an IP address from the list, select the address, and then click Delete.
3. Click the Save icon to save your settings.
Configuring SNMP for a Grid Member
You can override grid-level SNMP settings for individual members. To modify the SNMP settings for a grid member:
1. From the Grid perspective, click + (for grid) -> + (for Members) -> member -> Edit -> Member Properties.
2. In the Grid Member editor, click Monitoring, and enter the following:
— Override grid SNMP settings: Select the check box to override grid-level SNMP settings and apply
member-level settings.
— Enable queries: Select the check box for the member to accept queries from SNMP management
systems. Clear the check box to disable the member from accepting SNMP queries.
•
Community String: Type a community string—which is very much like a password—that SNMP
management systems must send when querying the member.
— Enable traps: Select the check box to enable the grid member to send traps to specified SNMP
management systems. Clear the check box to disable the member from sending SNMP traps.
•
Community String: Type a community string—which is very much like a password—that the grid
member must include when sending traps to the specified SNMP management systems.
•
Trap Receiver Group: Type the IP address of an SNMP management system to which you want the
grid member to send traps in the IP Address field, and then click Add. To remove an IP address from
the list, select the address, and then click Delete.
— Set objects: Select this check box.
•
sysContact: Enter the name of the contact person for the device.
•
sysLocation: Enter the physical location of the device.
•
sysName: Enter the fully qualified domain name of the device.
•
sysDescr: Enter useful information about the device, such as the software version it is running.
3. Click the Save icon to save your settings.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
149
Monitoring with SNMP
150
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 7 Changing Software and
Merging Files
You can perform software upgrades and downgrades for your Infoblox device. You can also merge data files from
previous versions of the DNSone module to an Infoblox device running DNSone 3.2 or later. This chapter explains how
to perform these procedures:
•
•
•
•
•
•
Upgrading Software on page 152
— Acquiring Software Upgrade Files on page 152
— Distributing Software Upgrade Files on page 152
— Running the Software Upgrade on page 153
Downgrading Software on page 155
Reverting to the Previously Running Software Version on page 156
Merging Data on page 156
Backing Up and Restoring a Configuration File on page 158
— Back Up and Restore Overview on page 158
— Automatically Backing Up a Data File on page 159
— Downloading a Backup File on page 160
— Restoring a Configuration File on page 161
— Loading a Configuration File on a Different Device on page 162
Downloading Files on page 163
— Downloading PERL Scripts on page 163
— Downloading a Support Bundle on page 163
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
151
Changing Software and Merging Files
Upgrading Software
Infoblox sends e-mail notifications of new software upgrades when they are released. To get the latest upgrades, your
local network must be capable of downloading a file from the Internet.
The NIOS software upgrade process involves three steps:
•
Downloading the software upgrade files to a local system (Acquiring Software Upgrade Files on this page)
•
Distributing (Staging) the software upgrade files—which involves unpacking the software files and loading the
new software (Distributing Software Upgrade Files on page 152)
•
Running the software upgrade—which involves rebooting the devices and then running the new software
(Running the Software Upgrade on page 153)
Note: You cannot upgrade from DNSone 3.1 to NIOS 4.0 or later directly. You must first upgrade from DNSone 3.1 to
3.2. Then you can upgrade from DNSone 3.2 to NIOS 4.0. For information about upgrading from DNSone 3.1
to 3.2, see the Infoblox Administrator Guide for DNSone 3.2.
Acquiring Software Upgrade Files
Infoblox frequently releases updated NIOS software. Contact Infoblox Support to learn what file name to use when
downloading the new upgrade file, or watch your e-mail for periodic notifications that a new software upgrade is
available. After you have the new upgrade file stored on your local network, proceed to the next section.
Distributing Software Upgrade Files
Software distribution varies depending on how devices are deployed:
•
The grid master distributes the software to each member in the grid, including itself. For HA members, the grid
master first distributes software to the active node, which in turn distributes it to the passive node.
•
The active node of an independent HA pair distributes the software to the passive node and to itself.
•
A single independent device distributes the software to itself.
The time this process takes depends on the number of devices to which the software is distributed; the more devices,
the longer it takes.
Before upgrading, Infoblox recommends that all members in the grid or both nodes in an independent HA pair must
be connected to the network and operating normally. If one or more members are offline when you upgrade the grid,
you can upgrade these individual members later. For information on this process, see Upgrading Offline Grid
Members on page 154.
Caution: Do not attempt to promote a member to grid master during the upgrade procedure.
To distribute the latest software:
1. From the Grid or Device perspective, click Grid (or Device) -> Distribute -> Upload NIOS Software.
2. Navigate to the .bin file that you want to upload, select it, and then click Open or OK.
Note: When you perform a distribution, the Infoblox device loads the new software code into a partitioned
memory space, which overwrites any previously saved version of code already there.
The following series of events occurs:
— The active node of the grid master uploads the file to a backup partition and unpacks the contents, which
overwrites any existing backup software that might have been there.
— The active node of the grid master sends a command to all single members, the active nodes of all HA
members, and the passive node of the grid master to copy their database and software to a backup
software partition.
152
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Upgrading Software
— The active node of the grid master performs rsync on the backup partition of all single members and the
active nodes of all HA members, sending only the changed files. The active node of the grid master
distributes files to a maximum of four devices at a time.
— After the active node of an HA member receives the software, it then distributes it to the passive node.
3. To view the file distribution status for the grid, look at the Upgrade Status panel.
From the Grid or Device perspective, click View -> Upgrade Status.
The process takes a few minutes and is complete when the Upgrade Status panel displays file distribution as
complete and all files unpacked. The new software is now staged on all member devices and is ready for use.
Running the Software Upgrade
After you successfully distribute (stage) the software upgrade to one or more devices, you can then run it. Essentially,
each device is going to switch between the two software partitions on its system, activating the staged software and
saving the previously active software and database as backup.
Note: Before you upgrade the software, Infoblox recommends backing up the current configuration and database.
To run the software upgrade:
1. From the Grid or Device perspective, click Grid (or Device) -> Upgrade.
The upgrade process begins immediately. If you are upgrading an independent device, the management
session soon disconnects.
Due to the nature of the upgrade sequence, HA pairs fail over during the upgrade. Therefore, be aware that the
active and passive nodes reverse roles. The order in which grid members upgrade, including when HA pairs fail
over, is shown in Figure 7.2 (for an HA grid master) and Figure 7.2 on page 154 (for a single grid master).
Figure 7.1 Upgrade Sequence for an HA Grid Master and Grid Members
Grid
3
Active
1 The passive node (Node 2) of
Failover
the grid master upgrades.
Passive
2 The passive node ( Node 2) of
HA Grid
Master
HA Grid
Member
5
1
Node 1
Node 2
Active
Passive
4
2
Node 1
Node 2
the HA member and the single
grid member upgrade.
3 The grid master fails over from
Node 1 to Node 2.
At this point, the grid master is
using upgraded code. This
causes the HA grid member to
fail over (because the code on
Node 1 does not match that on
the grid master, but the code on
Node 2 does). Likewise, the
single grid member no longer
has code that matches that of
the current grid master.
4 Node 1 (now passive) of the HA
member upgrades.
Single
Grid
Member
NIOS 4.1r3
2
5
Node 1 (now passive) of the
grid master upgrades.
Infoblox Administrator Guide (Rev. A)
153
Changing Software and Merging Files
Figure 7.2 Upgrade Sequence for a Single Grid Master and Grid Members
Grid
Single Grid
Master
1
Failover
Active
HA Grid
Member
3
1
Single grid master upgrades.
2
Node 2 (passive) of the HA
member and the single
member upgrade.
3
The HA member fails over
from Node 1 to Node 2.
4
Node 1 (now passive) of the
HA member upgrades.
Passive
4
2
Node 1
Node 2
2
Single Grid
Member
The GUI session terminates when the HA grid master or independent HA pair fails over from Node 1 to Node 2,
or when the single grid master or single independent device reboots and goes offline.
2. Log back in and check the status of each upgraded device in the Detailed Status panels. (From the Grid
perspective, click + (for grid ) -> + (for Members) -> member -> View -> Detailed Status. From the Device perspective,
click hostname -> View -> Detailed Status.)
Upgrading Offline Grid Members
In cases when it is not possible to have all grid member devices online for an upgrade, you can first upgrade all the
online devices using the procedure explained in Upgrading Software on page 152 and then upgrade the individual
offline devices separately, as explained below. This situation might arise when there is a large grid spanning multiple
time zones and there are fluctuating network and downtime issues at the various locations so that it becomes
inconvenient or impossible to coordinate an upgrade when all devices are concurrently online.
During the upgrade process, the grid master attempts to distribute software to the entire grid, making up to three
attempts for each device. (For an HA member, the master makes up to three attempts to distribute software to each
node that constitutes that HA member.) If the master cannot reach a device, it displays an upgrade warning at the end
of the distribution effort identifying each device (by IP address) to which it was unable to distribute the software
upgrade. You can then upgrade each of these devices separately, as explained below:
To upgrade an offline device:
1. Log in to the console port of the single member or to the console port on each node of the HA member that was
offline at the time that you upgraded the grid. (For information on using the console port, see Using the Serial
Console on page 533.) Optionally, use SSH (Secure Shell) to make a remote console connection.
2. Reset each offline device to its factory settings by entering the reset database command.
This command clears its configuration except for basic network settings—LAN interface IP address, subnet, and
default gateway IP address.
154
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Downgrading Software
3. With DNSone 3.2r1 or later, you can allow the grid to synchronize the software on a device automatically when it
rejoins the grid (if you have already enabled this option for the grid). Optionally, you can upgrade the software—
of any software release—on each device manually. Do either of the following:
Automatic Upgrade
a.
Enable the automatic software adjustment feature for the grid as explained in Automatic Software Version
Coordination on page 206.
b. Join the device to the grid as explained in Adding Grid Members on page 220.
When the device attempts to join the grid, the grid master checks the version of software on the joining
device and—if it does not match the version running on the grid—upgrades (or downgrades) it.
or
Manual Upgrade
a.
To distribute and run the software upgrade manually on the offline device, follow the steps in Upgrading
Software on page 152.
b. Join the device to the grid as explained in Adding Grid Members on page 220.
When the device attempts to join the grid, the grid master checks the version of software on the joining
device and—because it matches the version running on the grid—allows the device to join.
Downgrading Software
Infoblox-500, -1000, and -1200 devices support software downgrades from DNSone 3.2r1 or later to any previous
DNSone release beginning with 3.1r1. Infoblox-550, -1050, -1550, and -1552 appliances support software
downgrades from DNSone 3.2r9-2 or later to any previous DNSone release beginning with 3.2r9-1. The downgrade
procedure is for single independent devices only. Infoblox does not support software downgrades for grid members,
but you can revert to the last grid upgrade file (see the next section) on a grid master.
Caution: Although the downgrade process preserves license information and basic network settings, it does not
preserve data. After you complete the downgrade procedure, all data in the database is lost.
To downgrade software on a single independent device running NIOS 4.0 or later:
1. For a device running DNSone with Keystone: From the Grid perspective, click Grid -> Downgrade.
or
For a device running DNSone: From the Device perspective, click Device -> Downgrade.
2. Read the warning carefully, and then click OK to confirm your decision to downgrade.
3. Navigate to the downgrade image file, and then click OK.
4. Clear the Java cache on your system.
5. Close the browser, open another browser instance, and then log back in.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
155
Changing Software and Merging Files
Reverting to the Previously Running Software Version
You can revert to the previous version of software that was running on your Infoblox device. The Infoblox device stores
the previous version in its backup software partition. You can see if there is a software version to which you can revert
and what that version is in the Alternate Revision column in the Upgrade Status viewer. From the Grid or Device
perspective, click View -> Upgrade Status.
Be aware that when you revert to this software, any configurations made to the currently running software are lost.
So that you can later determine what configuration changes are missing, you can back up the current data before you
revert.
To revert to a version of software running previously on a grid or on an independent device or HA pair:
1. From the Grid or Device perspective, click Grid or Device -> Revert.
2. Read the warning carefully, and then click OK to confirm your decision to revert.
3. Close the Java application and restart it.
Clearing the Java cache is unnecessary because JWS automatically updates its cache with the application for the
currently running version of software.
4. Log back in to the grid master, independent device, or independent HA pair.
Merging Data
You can merge the data from the backup file of an Infoblox device running DNSone 2.5.3 or later with another Infoblox
device or—more commonly—with a grid running DNSone 3.1 or later. For example, when joining an independently
deployed Infoblox device or HA pair with a grid, you might want to retain the existing DNS or DNS data for that device
after it becomes part of the grid. To accomplish that, follow these three steps:
1. Create a backup file of the independent device or HA pair on your local management system.
2. Merge the backup file with the data and configuration on the grid.
3. Join the device or HA pair with the grid.
These three steps are presented in more detail below:
Creating a Backup File
On the device or HA pair whose data you want to merge with a grid database:
1. Create a backup file by opening the Grid perspective and then clicking Grid -> Backup -> to Local File.
2. Save the backup file as filename.tar.gz on your local management system.
Adding a New Grid Member and Merging the Backup File
On the grid master:
1. From the Grid perspective, click grid -> Edit -> Add Grid Member.
2. In the Add Grid Member dialog box, enter the host name and network settings for the device or HA pair that you
want to add to the grid, and then click the Save icon.
3. Merge the backup file from the single device or HA pair with that of the grid by clicking Grid -> Merge Database.
The Merge Database dialog box appears.
Note: In the Merge Database dialog box, you can click the Backup button to back up the current database for the
grid. Infoblox strongly recommends that you create a backup file before proceeding.
156
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Merging Data
4. In the Merge Database dialog box, enter the following:
— New data overwrites current data: Select the check box if you want the DNS, DHCP, and global and member
properties from the device or HA pair to overwrite matching data on the grid. Exceptions to this are user
profiles (with matching user names but mismatching passwords) and grid-level settings for DHCP failover.
In these cases, the new data does not overwrite existing data. Clear the check box to merge only that data
that does not conflict with existing data.
— Merge in DNS data: Select the check box to merge the DNS information, such as DNS properties and all the
zone information.
— Merge in DHCP data: Select the check box to merge the DHCP information.
— Merge in grid and member properties: Select the check box to merge global and member properties, and
system administration information.
— Detailed Logging: Select the check box to log errors and all transactions during the merge. Clear this option
to log errors only. (To view the system log: From the Grid perspective, click grid_master -> File -> System Log
-> active_node.)
5. Click OK.
6. Type the location of the backup file or navigate to the file and select it, and then click OK.
After the merge process completes, the Infoblox application restarts and the JWS (Java Web Start) application
terminates.
7. Wait a few minutes, and then log back in to the grid master from the JWS login prompt.
Joining the Grid
On the device or HA pair you want to join to a grid:
1. From the Grid perspective, click + (for grid ) -> + (for Members) -> member -> Edit -> Join Grid.
2. Enter the following in the Join Grid dialog box:
— Virtual IP of Grid Master: Type the VIP address of the grid master for the grid to which you want to add the
single device or HA pair.
— Grid Name: Type the name of the grid.
— Grid Shared Secret: Type the shared secret of the grid.
— Re-type Grid Shared Secret: To ensure accuracy, retype the shared secret.
— Use MGMT port to join grid: If you have already enabled the MGMT port (see Grid Communications on page
92), this option becomes available. Select it to connect to the grid through the MGMT port.
3. Click OK to close the dialog box and initiate the join grid operation.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
157
Changing Software and Merging Files
Backing Up and Restoring a Configuration File
You can back up your system files locally on the device, or to a TFTP (Trivial File Transfer Protocol) or FTP (File Transfer
Protocol) server. The backup file is a .tar.gz file that contains the configuration settings, data set, and TFTP files. (For
information about the TFTP feature, see Chapter 18, File Distribution Services, on page 457. You can also save an
existing backup file, or create and save a new one to your local management system, TFTP server, or FTP server.
These sections describe how to use the backup and restore functions:
•
•
•
•
•
Back Up and Restore Overview on page 158
Automatically Backing Up a Data File on page 159
Downloading a Backup File on page 160
Restoring a Configuration File on page 161
Loading a Configuration File on a Different Device on page 162
Note: Infoblox highly recommends you always back up the current configuration file before upgrading, restoring, or
reverting the software on the device.
Back Up and Restore Overview
The Infoblox device allows you to back up and restore the system files. You can configure the device to automatically
back up the files on a weekly, daily, or hourly basis. You can also restore an existing configuration file on the device
from which it originated, or restore a configuration file from a different device (referred to as a forced restore).
Infoblox recommends that you back up the system files during off-hours to minimize any effect on network services.
By default, the automatic backup function is turned off. You must log in with a superuser account to back up and
restore files.
There are three primary ways to back up and restore a configuration file:
•
Back up to and restore from a local directory or the management system used to operate the device.
•
Back up to and restore from a TFTP server.
•
Back up to and restore from a remote server using FTP. This option requires that you have a valid user name and
password for the FTP server prior to attempting to back up or restore.
When you back up the system files locally, the device uses the following format to name the file:
year_month_day_time. For example, 2005_11_30_23_00 translates to September 30th, 2005 at 11:00 PM.
The device saves up to 20 configuration files, regardless of how often files are saved (weekly, hourly, or daily. The size
of the configuration file should be factored because the storage limit on a device is 5 Gb (gigabytes). If your
configuration file is 500 Mb (megabytes), then the device stores 10 configuration files. When uploading configuration
files on a TFTP or FTP server, you must consider the file size on that server as well.
158
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Backing Up and Restoring a Configuration File
Automatically Backing Up a Data File
Infoblox recommends that you back up your configuration files regularly, and the easiest way to accomplish this task
is to configure the device to back up the configuration file automatically. You can choose when and how often files
are backed up: weekly, daily, or hourly. When you automatically back up a configuration file on the device, the file is
named with the format: year_month_day_time. The default time for an automatic backup is 3:00 AM. Configuration
files should be backed up during the slowest period of network activity.
To automatically back up a database file on an independent device or grid master:
1. From the Grid perspective, click grid -> Edit -> Grid Properties.
or
From the Device perspective, click hostname -> Edit -> Device Properties.
2. In the Grid (or Device) editor, click Scheduled Backups.
3. In the Scheduled Backups section, enter the following information:
— Backup: Choose the destination of the backup file from the left drop-down list (LOCAL, TFTP, FTP) and how
often to back up the file from the right drop-down list (Weekly, Daily, Hourly). By default, a grid master
generates a backup file and saves it locally in its own storage daily at 3:00 AM.
Be aware that backing up the grid and saving it locally on an hourly basis increases the turnover of files
stored on the grid master. Backing it up hourly to a TFTP or FTP server increases the overall amount of traffic
on your network.
— Weekday: (Weekly Only) Choose a day from the Weekday drop-down list, an hour from the Hours drop-down
list, and a minute from the Minutes drop-down list. The grid master then creates a backup file at that time
and day every week.
— Hours [0-23]: (Weekly and Daily) Type the hour when you want the grid master to create a backup file.
— Minutes [0-59]: (Weekly, Daily, Hourly) Type the minute when you want the grid master to create a backup
file.
— User Name: (FTP Only) Type the user name for your FTP account.
— Password: (FTP Only) Type the password for your FTP account.
— Retype Password: (FTP Only) Type the password for your FTP account again to confirm its accuracy.
— Backup Host: (FTP and TFTP) Type the IP address of the FTP or TFTP server where you want the grid master to
send the backup file.
— Directory Path: (FTP Only) Type a directory path—for example: /archive/backups (for Windows) or
/bin/backups (for Linux). The folder or directory you type must already exist on the specified server.
— Disable schedule backups: Select this check box if you want to disable automatic backups from occurring,
but want to save the settings for future use.
4. Click the Save icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
159
Changing Software and Merging Files
Downloading a Backup File
You can save an existing backup file, or create and save a new one to your local management system, TFTP server, or
FTP server.
To backup a grid or an independent device or HA pair to your management system:
1. For a grid: From the Grid perspective, click Grid -> Backup -> to Local File.
or
For an independent device or HA pair: From the Device perspective, click Device -> Backup -> to Local File.
2. To back up the current configuration and data set, choose None, and then click OK.
To download a previously made backup file (automatically created through the scheduled backup feature),
choose the backup file name, and then click OK.
3. Navigate to the directory on your local management system where you want to save the backup file, rename the
file if you like (by default, it is named databse.tar.gz), and then click Save or OK.
To backup a grid or an independent device or HA pair to a TFTP server:
From the Grid perspective, click Grid -> Backup -> to TFTP Server.
or
From the Device perspective, click Device -> Backup -> to TFTP Server.
1. Enter the following in the TFTP Backup dialog box:
— Existing backup files: To back up the current configuration and data set, choose None. To download a
previously made backup file (made using the scheduled backup feature), choose the backup file name.
— File name on TFTP server: Type a name for the backup file. If you are downloading a previously made backup
file and want to use that name, you can leave this field empty. An Infoblox device names backup files by
concatenating the grid name or hostname with the date and time it creates the file, using this format:
•
For a grid: grid_yyyy_mm_dd_hh_mm.tar.gz
•
For an independent device or HA pair: hostname_yyyy_mm_dd_hh_mm.tar.gz
— IP address of TFTP Server: Type the IP address of the TFTP server.
2. To download the specified backup file to the specified TFTP server, click OK.
To backup a grid or an independent device or HA pair to an FTP server:
1. From the Grid perspective, click Grid -> Backup -> to FTP Server.
or
From the Device perspective, click Device -> Backup -> to FTP Server.
2. Enter the following in the FTP Backup dialog box:
— Existing backup files: To back up the current configuration and data set, choose None. To download a
previously made backup file (made using the scheduled backup feature), choose the backup file name.
— File name on FTP server: Type a name for the backup file. If you are downloading a previously made backup
file and want to use that name, you can leave this field empty. An Infoblox device names backup files by
concatenating the grid name or hostname with the date and time it creates the file, using this format:
•
For a grid: grid_yyyy_mm_dd_hh_mm.tar.gz
•
For an independent device or HA pair: hostname_yyyy_mm_dd_hh_mm.tar.gz
— IP address of FTP server: Type the IP address of the FTP server.
— Username on FTP server: Type the user name for your FTP account.
— Password on FTP server: Type the password for your FTP account.
— Re-type Password on FTP server: Type the account password again to ensure accuracy.
3. To download the specified backup file to the specified FTP server, click OK.
160
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Backing Up and Restoring a Configuration File
Restoring a Configuration File
You can restore a configuration file from a device running software modules v.3.1r4 or later, or v3.2, to a device
running software modules v3.2.x. The procedure presented below allows you to restore a configuration file from the
same device it was originally backed up. To load a configuration file backed up from a different device, see Loading
a Configuration File on a Different Device on page 162.
To restore a configuration file to the same independent device or grid master:
1. From the Grid perspective, click Grid -> Restore Grid -> From Local File or From TFTP Server or From FTP Server or
From Grid.
or
From the Device perspective, click Device -> Restore Device -> From Local File or From TFTP Server or From FTP
Server or From Grid.
2. Do one of the following:
— From Local File: Navigate to the location of the configuration file, select the file, and then click OK.
or
— From TFTP Server: In the Restore Grid From TFTP dialog box, enter the following, and then click OK:
•
TFTP Server IP Address: Type the IP address of the TFTP server in whose root directory the backup
file is stored.
•
File Name: Type the name of the backup file. (Because the file must be in .tar.gz format, the file
type is included as a read-only extension of the file name.)
or
— From FTP Server: In the Restore Grid From FTP dialog box, enter the following, and then click OK:
•
FTP Server IP address: Type the IP address of the FTP server in whose root directory the backup file
is stored.
•
File Name: Type the name of the backup file. Do not include .tar.gz at the end of the file name.
•
User Name: Type the name of the FTP server account.
•
Password: Type the password of the FTP server account.
•
Retype Password: To ensure accuracy, type the account password again.
•
File Path: Type the directory path to where the backup file is stored.
or
— From grid: Select a configuration file from the drop-down list, and then click OK.
3. When the Confirm Grid Restore message appears, click OK to load the configuration file.
After the file loads, the device reboots.
4. Close your current browser window or JWS (Java Web Start) application, wait a few minutes, and then reconnect
to the Infoblox device.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
161
Changing Software and Merging Files
Loading a Configuration File on a Different Device
You can restore a configuration file saved from one device onto a different device. To restore a configuration file to the
same device or grid master, use the Restore function explained in Restoring a Configuration File on page 161.
To load a configuration file from one device onto a different device:
1. From the Grid perspective, click Grid -> Force Restore Grid -> From Local File or From TFTP Server or From FTP Server
or From Grid.
or
From the Device perspective, click Device -> Force Restore Device -> From Local File or From TFTP Server or From
FTP Server or From Grid.
2. Do one of the following:
— From Local File: Navigate to the location of the configuration file, select the file, and then click OK.
or
— From TFTP Server: In the Restore Grid From TFTP dialog box, enter the following, and then click OK:
•
TFTP Server IP Address: Type the IP address of the TFTP server in whose root directory the backup
file is stored.
•
File Name: Type the name of the backup file. (Because the file must be in .tar.gz format, the file
type is included as a read-only extension of the file name.)
or
— From FTP Server: In the Restore Grid From FTP dialog box, enter the following, and then click OK:
•
FTP Server IP address: Type the IP address of the FTP server in whose root directory the backup file
is stored.
•
File Name: Type the name of the backup file. Do not include .tar.gz at the end of the file name.
•
User Name: Type the name of the FTP server account.
•
Password: Type the password of the FTP server account.
•
Retype Password: To ensure accuracy, type the account password again.
•
File Path: Type the directory path to where the backup file is stored.
or
— From grid: Select a backup file from the drop-down list, and then click OK.
3. When the Confirm Grid Restore confirmation message appears, click OK to load the backup file.
After the file loads, the device reboots.
4. Close your current browser window or JWS (Java Web Start) application, wait a few minutes, and then reconnect
to the Infoblox device.
162
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Downloading Files
Downloading Files
The Infoblox device allows you to download files in the following ways:
•
•
Downloading PERL Scripts on page 163
Downloading a Support Bundle on page 163
Downloading PERL Scripts
Infoblox devices support an application programming interface (API) that provides a convenient way to simplify
otherwise lengthy, recurring, and repetitive tasks, such as the following:
•
Customizing the operation of the Infoblox device
•
Performing periodic updates and scheduled backups
•
Importing IPAM data
•
Performing bulk data imports
•
Using scripts to perform a single operation such as adding a host
•
Connecting with existing DNS management tools
Perl is a scripting language that supports both procedural and object-oriented programming. You can use prewritten
Perl scripts (see the Infoblox Scripting Pack, available at http://support.infoblox.com) or design your own custom
scripts to run operations through the Infoblox DMAPI (Device and Management API). A script is a program that you
send to the Infoblox device through the Infoblox DMAPI to perform one or more operations. The Infoblox DMAPI is a
Perl language binding to the Infoblox device and delivered as a set of packages using the Perl object-oriented style.
The Introduction to the Infoblox DMAPI Guide explains the software you need to use the Infoblox DMAPI, where to get
it, and how to install it. To view instructions in the GUI on how to access the Infoblox API, click Tools -> Access Infoblox
API.
Downloading a Support Bundle
When you need assistance troubleshooting an Infoblox device, you can log in to the device as a superuser, download
the support bundle of the device and send it to Infoblox Support for analysis. A support bundle is a tar.gz file that
contains configuration files and the device system files. You can download a support bundle for an independent
device and for each member in a grid. When you download a support bundle for an HA pair, it includes the files of
both nodes in the HA pair.
By default, the device includes the following files in the support bundle: core files, log files, VitalQIP files (if a VitalQIP
license is installed on the device). Because core files can be quite large and take a significant amount of time to
download, Infoblox recommends that you include core files in the support bundle only when requested by Infoblox
Support.
To download a support bundle:
1. From the Grid perspective, click + (for grid ) -> + (for Members ) -> grid_member -> Tools -> Download Support
Bundle.
or
From the Device perspective, click hostname -> Tools -> Download Support Bundle.
2. In the Download Support Bundle dialog box, select which files you would like to include in the support bundle,
and then click OK:
— Core Files: Infoblox recommends that you include these files only when requested by Infoblox Support.
— Log Files: Infoblox recommends that you always include these files in the support bundle.
— QIP: If a VitalQIP license is installed on the device, include the VitalQIP files in the support bundle.
3. In the Save as... dialog box, navigate to where you want to save the file and change the file name. Do not change
the .tar.gz file extension in the file name.
4. Send this file to Support in an e-mail message.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
163
Changing Software and Merging Files
164
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Part 2 Device Deployment
This section provides information about deploying and managing independent devices and grids. It includes the
following chapters:
•
Chapter 8, "Deploying Independent Devices", on page 167
•
Chapter 9, "Deploying a Grid", on page 201
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
165
166
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 8 Deploying Independent Devices
This chapter explains how to deploy single independent devices and independent HA pairs. Independent devices run
NIOS without the Keystone upgrade and are deployed independently from a grid. The user guide or quick start guide
that ships with your product explains how to connect ethernet cables and power cords before configuring an Infoblox
device as a single independent device and an independent HA pair. Refer to these guides when necessary as you read
this chapter. (There is also cabling information for Infoblox-500, -1000, and -1200 appliances in Connecting the
Ethernet Cables on page 535.)
The topics in this chapter include:
•
•
•
•
•
•
•
•
Independent Deployment Overview on page 168
Deploying a Single Independent Device on page 169
— Method 1 – Using the LCD on page 170
— Method 2 – Using the CLI on page 170
— Method 3 – Using the Infoblox NIOS Startup Wizard on page 172
— Method 4 – Using the GUI on page 173
Configuration Example: Deploying an Infoblox Device for External DNS on page 174
Deploying an Independent HA Pair on page 181
— Method 1 – Using the Infoblox NIOS Startup Wizard on page 183
— Method 2 – Using the GUI on page 185
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP on page 187
Verifying the Deployment on page 198
— Single Independent Device on page 198
— Independent HA Pair on page 199
Forcing an HA Failover on page 199
Infoblox Tools for Migrating Data on page 200
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
167
Deploying Independent Devices
Independent Deployment Overview
You can deploy Infoblox devices collectively in a grid or independently (in what is sometimes referred to as a
“stand-alone” deployment). Although grids offer many advantages for large organizations, an independent
deployment might be sufficient for smaller sites. For example, if your ISP hosts one name server to respond to
external DNS queries, it might be enough to deploy a single independent Infoblox device as the other name server,
as shown in Figure 8.1.
Figure 8.1 Single Independent Device as an External DNS Server
The ISP hosts a secondary
DNS server for the
corp100.com domain.
Internet
ISP
Site
The primary and secondary name servers
provide DNS protocol redundancy. If one
of them cannot respond to a query for the
corp100.com domain, the other can.
An Infoblox device is the primary DNS server
for the corp100.com domain. It answers
queries from the Internet for public-facing
servers in the DMZ network.
DMZ
Firewall
domain name =
corp100.com
Switch
Internal
Network
LAN or
LAN1 Port
Servers for Public Access
Using primary and secondary name servers provides DNS protocol redundancy and configuring two DHCP servers as
DHCP failover peers provides DHCP protocol redundancy. However, you can only have hardware redundancy if you
deploy devices in an HA (high availability) pair. Should the active node in an HA pair fail, the passive node becomes
active and begins serving data, as shown in Figure 8.2.
Figure 8.2 Independent HA Pair
This is the same situation as that in Figure 8.1,
but the primary DNS server is an independent
HA pair to provide hardware redundancy.
Internet
ISP
Site
Secondary
DNS Server
LAN (LAN1)
and HA Ports
Primary DNS Server
(Independent HA Pair)
DMZ
Firewall
Active Node
Switch
Internal
Network
Passive Node
LAN (LAN1)
and HA Ports
If the active node fails,
the passive node
becomes active and
continues serving DNS.
Servers for Public Access
The following sections describe the procedures for deploying independent devices singly and in HA pairs.
168
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deploying a Single Independent Device
Deploying a Single Independent Device
To deploy a single independent Infoblox device, you cable its LAN or LAN1 port to the network and change its default
IP settings so that it can connect to its surrounding IP address space. The default LAN settings are as follows:
•
IP address: 192.168.1.2
•
Netmask: 255.255.255.0
•
Gateway: 192.168.1.1
Note: On Infoblox-500, -1000, and -1200 appliances, the LAN port is labeled LAN. On Infoblox-550, -1050, -1550,
and -1552 appliances, use the port labeled LAN1. (The LAN2 port on these devices is reserved for future use.)
Infoblox provides the following methods for performing a basic configuration to deploy a single independent device:
•
Method 1 – Using the LCD
— Requirements: Physical access to a powered up Infoblox device
— Advantage: You do not need any other equipment.
•
Method 2 – Using the CLI
— Requirements: A serial connection from your management system to the console port on the Infoblox
device (You can also enable remote console access so that you can use the CLI over a network connection.
For information, see Enabling Remote Console Access on page 80.)
— Advantage: You do not have to change the IP address of the management system to connect to the Infoblox
device.
•
Method 3 – Using the Infoblox NIOS Startup Wizard
— Requirements: An HTTPS connection from your management system to the LAN or LAN1 port on the Infoblox
device
— Advantage: The wizard provides step-by-step guidance for changing not only IP settings for the LAN or LAN1
port, but also changing the device host name and admin password, setting the system clock, and—if using
NTP (Network Time Protocol)—enabling the Infoblox device to be an NTP server.
•
Method 4 – Using the GUI
— Requirements: An HTTPS connection from your management system to the LAN or LAN1 port on the Infoblox
device
— Advantage: If you have logged in previously and disabled the startup wizard, you can still use the GUI to
configure the LAN network settings.
These methods are explained in the following subsections.
After you set the network settings, you can then migrate data and settings from legacy DNS and DHCP servers to the
Infoblox devices. Several tools and methods are available for migrating data and configuration settings. For a list of
the available options, see Infoblox Tools for Migrating Data on page 200.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
169
Deploying Independent Devices
Method 1 – Using the LCD
Infoblox devices have an LCD and navigation buttons on the front panel that allow you to view system status and
license information as well as configure network settings for the LAN or LAN1 port.
Figure 8.3 Infoblox LCD and Navigation Buttons
The LCD panel is on the
front of an Infoblox device.
Infoblox
LCD
Navigation Buttons
You can deploy a single independent Infoblox device by setting its LAN or LAN1 port IP address, netmask, and
gateway through the LCD. This is the simplest method because you do not need anything other than physical access
to the device to complete the initial configuration.
1. Connect the power cable from the Infoblox device to a power source and turn on the power.
At startup, the Infoblox logo appears in the LCD on the front panel of the device. Then the LCD scrolls repeatedly
through a series of display screens.
2. To change the network settings for the LAN or LAN1 port, press one of the navigation buttons.
The LCD immediately goes into input mode, in which you can enter the IP address, netmask, and gateway for the
LAN or LAN1 port.
3. Use the navigation buttons to enter an IP address, netmask, and gateway address for the LAN or LAN1 port.
4. Cable the LAN or LAN1 port of the Infoblox device to a network as described in Independent Device Cabling Using
the LAN or Serial Port on page 535.
Method 2 – Using the CLI
The Infoblox CLI allows you to make an initial network configuration through the set network command. To access
the CLI, make a direct serial connection from your management system.
Note: You can also access the CLI from a remote location using an SSHv2 client. By default, remote console access—
that is, SSHv2 (Secure Shell version 2) access—is disabled. You must first enable remote console access
through the GUI or CLI, and then you can make an SSHv2 connection to the device.
1. Connect a console cable from the console port on your workstation to the male DB-9 console port on the Infoblox
device.
The DB-9 pin assignments follow the EIA232 standard. You can use the RJ-45 rollover cable and two female
RJ-45-to-female DB-9 adapters that ship with the device, or a female DB-9-to-female DB-9 null modem cable.
170
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deploying a Single Independent Device
Figure 8.4 Console Connection
Male DB-9
Console Port
Male DB-9
Console Port
Management
System
Infoblox
Device
RJ-45 Rollover Cable with
Two RJ-45-to-Female DB-9 Adapters
(Ships with Every Device)
or
Female DB-9-to-Female DB-9 Null Modem Cable
To Power
Source
2. Using a serial terminal emulation program such as Hilgraeve Hyperterminal® (provided with Windows®
operating systems), launch a session. The connection settings are:
— Bits per second: 9600
— Data bits: 8
— Parity: None
— Stop bits: 1
— Flow control: Xon/Xoff
3. Log in using the default user name and password admin and infoblox . User names and passwords are
case-sensitive.
4. To change the network settings from the default, enter the set network command. Then enter information as
prompted to change the IP address, netmask, and gateway for the LAN or LAN1 port.
Note: In the following commands, the variable ip_addr1 is the IP address of the LAN or LAN1 port and ip_addr2 is the
IP address of the gateway for the subnet on which you set the ip_addr1 address.
Infoblox > set network
NOTICE: All HA configuration is performed from the GUI. This interface is used only
to configure a standalone node or to join a grid.
Enter IP address: ip_addr1
Enter netmask: [Default: 255.255.255.0]: netmask
Enter gateway address [Default: n.n.n.1]: ip_addr2
Become grid member? (y or n): n
After you confirm your network settings, the Infoblox application automatically restarts.
5. Cable the LAN or LAN1 port to a network as described in Independent Device Cabling Using the LAN or Serial Port
on page 535.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
171
Deploying Independent Devices
Method 3 – Using the Infoblox NIOS Startup Wizard
When you first make an HTTPS connection to an Infoblox device, the Infoblox NIOS Startup Wizard appears. To ease
the initial configuration process, the wizard guides you through various deployment options and basic network
settings, and presents opportunities for changing the password of the superuser admin and for setting the system
clock.
To make an HTTPS connection to the device, you must be able to reach its IP address from your management system.
Note: If you have already set the IP address of the LAN or LAN1 port through the LCD or CLI so that you can reach it
over the network—and you have already cabled the device to the network—you can skip the first step.
1. If you have not changed the default IP address (192.168.1.2/24) of the LAN or LAN1 port through the LCD or CLI—
and the subnet to which you connect the device does not happen to be 192.168.1.0/24—put your management
system in the 192.168.1.0/24 subnet and connect an ethernet cable between your management system and the
Infoblox device.
2. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port. (To reach the
default IP address, enter: https://192.168.1.2)
Several certificate warnings appear during the login process. This is normal because the preloaded certificate is
self-signed (and, therefore, is not in the trusted certificate stores in your browser, Java application, and Java
Web Start application) and has the hostname www.infoblox.com, which does not match the destination IP
address you entered in step 1. To stop the warning messages from occurring each time you log in to the GUI, you
can generate a new self-signed certificate or import a third-party certificate with a common name that matches
the FQDN (fully qualified domain name) of the device. This is a very simple process. For information about
certificates, see Managing Certificates on page 41.
3. Click LAUNCH DEVICE MANAGER.
4. Log in to the Infoblox device. The default login name and password are admin and infoblox. For detailed
information about logging in to the GUI, see Accessing the Infoblox GUI on page 34.
The Infoblox NIOS Startup Wizard appears. The first screen provides basic information about the wizard, and the
second screen displays license agreement information.
5. Beginning on the third screen, enter the following, where
— ip_addr1 and netmask are the IP address and netmask of the LAN or LAN1 port
— ip_addr2 is the IP address of the gateway for the subnet on which the LAN or LAN1 port is set
— hostname is a valid domain name for the device
— string is a single alphanumeric string (no spaces) for a password that is at least four characters long
— ip_addr3 is the IP address of an NTP server:
Wizard Screen
Enter or Select
Deployment Type
Independent Device or HA Pair
Independent Device Deployment Type
Independent Device
Network Settings
IP Address: ip_addr1
Netmask: netmask
Gateway: ip_addr2
Host Name: hostname
172
Admin Account Password
Change Admin Password: (select), string
Time Settings
Enable NTP: (select)
NTP Server List: ip_addr3 (click Add)
Time zone: (choose the time zone for the location of the device)
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deploying a Single Independent Device
Note: The startup wizard provides options such as not changing the default password and manually entering the time
and date. However, changing the password and using an NTP server provide increased security and accuracy
(respectively), and so these choices are presented above.
The last screen of the startup wizard states that the changed settings require the application to restart. When
you click Finish, it restarts.
6. Open a new web browser instance and make an HTTPS connection to the new IP address of the LAN or LAN1 port.
7. Log back in using the default user name (admin ) and your new password. When you log in the second time, you
access the Infoblox GUI application. For system requirements to use the GUI, see Management System
Requirements on page 34.
Method 4 – Using the GUI
To deploy a single independent device through the GUI, make an HTTPS connection to the device and then bypass
the startup wizard. (The following procedure assumes that the device has the DNSone package installed.)
1. If you have not changed the default IP address (192.168.1.2/24) of the LAN or LAN1 port through the LCD or CLI—
and the subnet to which you connect the device does not happen to be 192.168.1.0/24—put your management
system in the 192.168.1.0/24 subnet and connect an ethernet cable between your management system and the
Infoblox device.
Note: The ethernet ports on the Infoblox-550, -1050, -1550, and -1552 appliances are autosensing, so you can
use either a straight-through or cross-over ethernet cable for this connection. For the Infoblox-500, -1000,
and -1200 appliances, use a cross-over ethernet cable to connect the device to your management system
and a straight-through ethernet cable to connect the device to a switch.
2. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port. (To reach the
default IP address, enter: https://192.168.1.2 . For detailed information on logging in to the GUI, see Accessing
the Infoblox GUI on page 34.)
3. Click LAUNCH DEVICE MANAGER.
4. Log in using the default user name (admin ) and password (infoblox ).
The Infoblox NIOS Startup Wizard appears.
5. To bypass the wizard, click Cancel or the Close button (⌧).
6. From the Device perspective, click infoblox.localdomain -> Edit -> Device Properties.
7. In the Device editor, click Device Properties, and then enter the following network settings:
— Host Name: Type the FQDN (fully qualified domain name) of the device.
— (V)IP Address: Type the IP address of the LAN or LAN1 port.
— Subnet Mask: Choose the netmask for the subnet to which the LAN or LAN1 port connects.
— Gateway: Type the IP address of the default gateway of the subnet to which the LAN or LAN1 port connects.
— Comment: Type a comment that provides some useful information about the device, such as its location.
8. Click Save, and then close the management window.
9. Initiate a new management session, and log in to the device using its new IP address.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
173
Deploying Independent Devices
Configuration Example: Deploying an Infoblox Device for External DNS
In this example, you configure the Infoblox device as the external primary DNS server for corp100.com. Its FQDN
(fully-qualified domain name) is ns1.corp100.com. The interface IP address of the LAN1 port is 10.1.5.2/24. Because
this is a private IP address, you must also configure the firewall to perform NAT (network address translation),
mapping the public IP address 1.1.1.2 to 10.1.5.2. Using its public IP address, ns1 can communicate with devices on
the public network.
The FQDN and IP address of the external secondary DNS server are ns2.corp100.com and 2.2.2.2. The ISP hosts this
server.
The primary and secondary servers answer queries for the following public-facing servers in the DMZ:
•
www.corp100.com
•
mail.corp100.com
•
ftp.corp100.com
When you create the corp100.com zone on the Infoblox device, you import zone data from the legacy DNS server at
10.1.5.3.
Figure 8.5 Example 1 Network Diagram
NTP Server
3.3.3.3
The device is in the Pacific
time zone (UMT-8:00)
Internet
ISP
1.1.1.2 –> 10.1.5.2
1.1.1.5 –> 10.1.5.5
1.1.1.6 –> 10.1.5.6
External Secondary DNS Server
ns2: 2.2.2.2
ethernet1
1.1.1.1/24
Firewall
NAT on Firewall
www
10.1.5.5
ethernet2
10.1.5.1/24
To Internal
Network
1.1.1.7 –> 10.1.5.7
ftp
10.1.5.7
DMZ Network
Infoblox Device
External Primary
DNS Server
ns1: 10.1.5.2
10.1.5.0/24
Switch
Legacy Primary DNS Server
ns1: 10.1.5.3
(Replaced by the Infoblox device)
mail
10.1.5.6
The Infoblox device is the external primary DNS server for the corp100.com domain. It answers queries from
the Internet for the three public-facing servers in the DMZ network:
174
•
www.corp100.com
•
mail.corp100.com
•
ftp.corp100.com
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Deploying an Infoblox Device for External DNS
Cable the Device to the Network and Turn On Power
Connect an ethernet cable from the LAN1 port of the Infoblox device to a switch in the DMZ network and turn on the
power. For information about installing and cabling the device, refer to the user guide or installation guide that ships
with the product.
Specify Initial Network Settings
Before you can configure the Infoblox device through the GUI, you must be able to make a network connection to it.
The default network settings of the LAN1 port are 192.168.1.2/24 with a gateway at 192.168.1.1 (the HA and MGMT
ports do not have default network settings). To change these settings to suit your network, use either the LCD or the
console port.
In this example, you change the IP address/netmask of the LAN1 port to 10.1.5.2/24, and the gateway to 10.1.5.1.
LCD
The Infoblox device has an LCD and navigation buttons on its front panel.
At startup, the Infoblox logo appears in the LCD on the front panel of the device. Then the LCD scrolls repeatedly
through a series of display screens.
1. To change the network settings from the default, press one of the navigation buttons.
The LCD immediately goes into input mode, in which you can enter the IP address, netmask, and gateway for the
LAN1 port.
2. Use the navigation buttons to enter the following information:
— IP Address: 10.1.5.2
— Netmask: 255.255.255.0
— Gateway: 10.1.5.1
Console Port
The Infoblox device has a male DB-9 console port on the front panel. You can log in to the device through this port
and specify initial network settings using the Infoblox CLI.
1. Connect a console cable from the console port of the management system to the console port of the Infoblox
device.
2. Access the Infoblox CLI. For more information about the Infoblox CLI, refer to the Infoblox CLI Guide.
3. To change the network settings from the default, enter the set network command. Then enter information as
prompted to change the IP address, netmask, and gateway for the LAN1 port.
Infoblox > set network
NOTICE: All HA configuration is performed from the GUI. This interface is used only to
configure a standalone node or to join a grid.
Enter IP address: 10.1.5.2
Enter netmask: [Default: 255.255.255.0]:
Enter gateway address [Default: 10.1.5.1]:
Become grid member? (y or n): n
After you confirm your network settings, the device automatically restarts.
Specify Device Settings
When you make the initial HTTPS connection to the Infoblox device, you see the Appliance Startup Wizard, which
guides you through the basic deployment of the device on your network. Use the wizard to enter the following
information:
•
Deployment: single independent device
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
175
Deploying Independent Devices
•
Host name: ns1.corp100.com
•
Password: SnD34n534
•
NTP (Network Time Protocol) server: 3.3.3.3; time zone: (UMT – 8:00 Pacific Time (US and Canada), Tijuana
1. Open a browser window and enter https://10.1.5.2.
2. Accept the certificate when prompted.
Several certificate warnings appear during the login process. This is normal because the preloaded certificate is
self-signed (and, therefore, is not in the trusted certificate stores in your browser, Java application, and Java
Web Start application) and has the hostname www.infoblox.com, which does not match the destination IP
address you entered in step 1. To stop the warning messages from occurring each time you log in to the GUI, you
can generate a new self-signed certificate or import a third-party certificate with a common name that matches
the FQDN (fully-qualified domain name) of the device. This is a very simple process. For information about
certificates, see Managing Certificates on page 41.
3. Click LAUNCH DEVICE MANAGER.
4. If the browser prompts you for an application to use, see Accessing the Infoblox GUI on page 34.
5. Log in using the default user name and password admin and infoblox.
Note: User names and passwords are case-sensitive.
6. The Infoblox Appliance Startup Wizard opens with a splash screen that provides basic information about the
wizard, and then displays license agreement information. Beginning on the third screen, enter the following:
Wizard Screen
Enter or Select
Deployment type
Standalone
Node type
Standalone appliance
Node information
Host name: ns1.corp100.com
Default password
Change admin’s password: (select), SnD34n534
Time settings
Enable NTP: (select)
NTP Server: 3.3.3.3 (click Add)
Time zone: (UMT – 8:00 Pacific Time (US and Canada),
Tijuana
The last screen of the wizard states that the changed settings require the application to restart. When you click
Finish, the Infoblox GUI application restarts.
7. Log back in to the device. When you log in the second time, you access the Infoblox GUI application. For system
requirements to use the GUI, see Management System Requirements on page 34.
Define a NAT Address
Because the firewall translates the public IP address 1.1.1.2 to the interface IP address 10.1.5.2, all DNS queries
originating outside the firewall use 1.1.1.2 (not 10.1.5.2) to reach the Infoblox device. Accordingly, you must
configure the device to indicate to other external DNS servers that its address is 1.1.1.2.
1. From the Device perspective, click ns1.corp100.com -> Edit -> Device Properties.
2. In the Device editor, click NAT and enter the following:
— Enable NAT compatibility: Select check box.
— Group: None
— NAT (V)IP Address: 1.1.1.2
176
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Deploying an Infoblox Device for External DNS
3. Click the Save icon.
The glue record is an A record for a name server. The device automatically generates the A record for ns1.corp100.com
using either the interface address or NAT address (if configured). To verify that the A record uses the NAT address
(1.1.1.2) instead of the interface address (10.1.5.2):
1. Click DNS to open the DNS perspective, and then click DNS Members -> + (for Infoblox) -> ns1.corp100.com -> Edit
-> Member DNS Properties.
2. In the Member DNS Properties editor, click General.
3. In the table labelled Member address for glue record inside view, select the default view and click Modify.
4. In the Select Member Address dialog box, select NAT IP address.
5. Click the Save and Restart Services icons.
Enable Zone Transfers on the Legacy Name Server
To allow the device to import zone data from the legacy server at 10.1.5.3, you must configure the legacy server to
allow zone transfers to the device at 10.1.5.2.
Legacy BIND Server
1. Open the named.conf file using a text editor and change the allow-transfer statement as shown below:
For All Zones — To set the allow-transfer statement as a global statement in the named.conf file for all zones:
options {
zone-statistics yes;
directory "/var/named/named_conf";
version "";
recursion yes;
listen-on { 127.0.0.1; 10.1.5.3; };
…
allow-transfer { 10.1.5.2; };
transfer-format many-answers;
};
For a Single Zone — To set the allow-transfer statement in the named.conf file for the corp100.com zone:
zone "corp100.com" in {
type master;
allow-transfer { 10.1.5.2; };
notify yes;
};
2. After editing the named.conf file, restart DNS service for the change to take effect.
Legacy Windows 2000/2003 Server
1. Click Start -> All Programs -> Administrative Tools -> DNS.
2. Click + (for ns1) -> + (for Forward Lookup Zones) -> corp100.com.
3. Right-click corp100.com, and then select Properties -> Zone Transfers.
4. On the Zone Transfers page in the corp100.com Properties dialog box, enter the following:
5. Allow zone transfers: Select check box.
6. Only to the following servers: Select.
7. IP address: Enter 10.1.5.2, and then click Add.
8. To save the configuration change and close the corp100.com Properties dialog box, click OK.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
177
Deploying Independent Devices
Import Zone Data
You can import zone data from a legacy server or manually enter it. When you import both forward- and
reverse-mapping zone data, the Infoblox device automatically creates Infoblox host records if corresponding A and
PTR records are present. You can then modify the host records to add MAC addresses. However, if you only import
forward-mapping zone data, the Infoblox device cannot create host records from just the A records. In that case,
because you cannot later convert A records to host records, it is more efficient to create the corp100.com zone, and
define host records manually.
Infoblox host records are data models that represent IP devices within the Infoblox semantic database. The Infoblox
device uses a host object to define A, PTR, and CNAME resource records in a single object as well as a DHCP fixed
address if you include a MAC address in the host object definition. The host object prevents costly errors because
you only maintain a single object for multiple DNS records and a DHCP fixed address. Therefore, it is advantageous
to use host records instead of separate A, PTR, and CNAME records.
Note: If you only have forward-mapping zones on your legacy servers and you want to add reverse-mapping zones
and automatically convert A records to host records in the imported forward-mapping zones and create reverse
host records in corresponding reverse-mapping zones, create the reverse-mapping zones on the Infoblox
device and then import the forward-mapping zones data. The Infoblox device automatically converts the
imported A records to host records in the forward-mapping zones and creates reverse host records in the
reverse-mapping zones.
You also have the option of using the Data Import Wizard for loading DNS and DHCP configurations and data. For large
data sets, this option is an efficient approach. To download the Data Import Wizard, visit www.infoblox.com/support,
log in with your support account, and then click the Data Import Wizard hyperlink in the DNSone section.
In this example, when you create the corp100.com forward-mapping zone, you import zone data for the existing
corp100.com zone from the legacy server at 10.1.5.3. When you create the 1.1.1.0/24 reverse-mapping zone, you
also import the reverse-mapping zone records from the legacy server. After the device has both the forward- and
reverse-mapping zone data, it converts the A and PTR records to Infoblox host records.
1. Open a browser window, and log in to the device at https://10.1.5.2, using the user name admin and the
password SnD34n534.
2. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> Forward Mapping
Zones -> Edit -> Add Forward Mapping Zone -> Authoritative.
3. In the Authoritative Zone Properties section of the Add Forward Authoritative Zone editor, enter the following:
— Name: corp100.com
— Comment: External DNS zone
4. In the Primary Server Assignment section, click Select Member to open the Select Grid Member dialog box.
5. Select ns1.corp100.com, and then click OK to close the dialog box.
6. In the Secondary Server Assignment section, click Add in the External Secondaries table to open the Zone
External Secondary Server Item dialog box.
7. Enter the following information, and then click OK to close the dialog box:
— Name: ns2.corp100.com
— IP Address: 2.2.2.2
— Stealth: Clear check box.
8. Click the Save and Restart Services icons.
9. Edit the zone that you just created as follows: in the Infoblox Views panel of the DNS perspective, click + (for
Forward Mapping Zones) -> corp100.com -> Edit -> Authoritative Zone Properties.
Note: To import zone data, you must first create a zone, save it, and then edit it.
178
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Deploying an Infoblox Device for External DNS
10. In the Forward Authoritative Zone editor, click Settings and enter the following:
— E-mail address: [email protected]
— Import zone from: Select check box, and enter 10.1.5.3 in the adjacent text field.
11. Click the Save icon.
12. After successfully importing the zone data, click corp100.com in the Infoblox Views panel.
You can see all the imported forward-mapping zone data in the Records panel. Because you have not yet
imported the reverse-mapping zone data, most of the records appear as A records.
13. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> Reverse Mapping
Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
14. In the Authoritative Zone Properties section of the Add Reverse Authoritative Zone editor, enter the following:
— Network Address: 1.1.1.0
— Subnet Mask: /24 (255.255.255.0)
— Comment: External DNS zone
15. In the Primary Server Assignment section, click Select Member to open the Select Grid Member dialog box.
16. Select ns1.corp100.com, and then click OK to close the dialog box.
17. In the Secondary Server Assignment section, click Add in the External Secondaries table to open the Zone
External Secondary Server dialog box.
18. Enter the following information, and then click OK to close the dialog box:
— Name: ns2.corp100.com
— IP Address: 2.2.2.2
— Stealth: Clear check box.
19. Click the Save icon.
20. In the Infoblox Views panel of the DNS perspective, click + (for Reverse Mapping Zones) -> 1.1.1.in-addr.arpa ->
Edit -> Authoritative Zone Properties.
21. In the Authoritative Reverse Zone editor, click Settings and enter the following:
— E-mail address: [email protected]
— Import zone from: Select check box, and enter 10.1.5.3 in the adjacent text field.
22. Click the Save and Restart Services icons.
23. Click 1.1.1.in-addr.arpa -> View -> Records.
You can see all the imported reverse-mapping zone data in the Records panel.
24. Click corp100.com in the Forward Mapping Zones list.
Because you have now imported both the forward- and reverse-mapping zone data, most of the records appear
as host records.
25. Finally, you must remove the ns1 host record for the legacy server (value 1.1.1.3). To remove it, select ns1 (the
host record for 1.1.1.3), and then click Edit -> Remove.
Designate the New Primary on the Secondary Name Server (at the ISP Site)
In this example, the external secondary name server is maintained by an ISP, so you must contact your ISP
administrator to change the IP address of the primary (or master) name server. (If you have administrative access to
the secondary name server, you can make this change yourself.)
Because a firewall performing NAT exists between the secondary and primary name servers, specify the NAT address
1.1.1.2 for the primary name server instead of 10.1.5.2.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
179
Deploying Independent Devices
Secondary BIND Server
1. Open the named.conf file using a text editor and set ns1 (with NAT address 1.1.1.2) as the primary (or master)
from which ns2 receives zone transfers in the named.conf file for the corp100.com zone:
zone "corp100.com" in {
type slave;
masters { 1.1.1.2; };
notify yes;
file “/var/named/db.corp100.com”;
};
2. After editing the named.conf file, restart DNS service for the change to take effect.
Secondary Windows 2000/2003 Server
1. Click Start -> All Programs -> Administrative Tools -> DNS.
2. Click + (for ns2) -> + (for Forward Lookup Zones) -> corp100.com.
3. Right-click corp100.com, and then select Properties -> General.
4. On the General page in the corp100.com Properties dialog box, enter the following:
— Zone file name: corp100.com.dns
— IP address: Enter 1.1.1.2, and then click Add.
— In the IP Address field, select 1.1.1.3 (the NAT IP address of the legacy DNS server), and then click Remove.
5. To save the configuration change and close the corp100.com Properties dialog box, click OK.
Configure NAT and Policies on the Firewall
Change the NAT and policy settings on the firewall to allow bidirectional DNS traffic to and from ns1.corp100.com and
NTP traffic from ns1.corp100.com to the NTP server at 3.3.3.3.
For example, enter the following commands on a Juniper firewall running ScreenOS 4.x or later:
set
set
set
set
set
set
address dmz ns1 10.1.5.2/32
address untrust ntp_server 3.3.3.3/32
interface ethernet1 mip 1.1.1.2 host 10.1.5.2
policy from dmz to untrust ns1 any dns permit
policy from untrust to dmz any mip(1.1.1.2) dns permit
policy from dmz to untrust ns1 ntp_server ntp permit
At this point, the new DNS server can take over DNS service from the legacy server. You can remove the legacy server
and unset any firewall policies permitting traffic to and from 10.1.5.3.
180
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deploying an Independent HA Pair
Deploying an Independent HA Pair
An independent HA (high availability) pair provides hardware redundancy for the source of your network identity
services. The two nodes that form an HA pair—identified as Node 1 and Node 2—are in an active/passive
configuration. The active node receives, processes, and responds to all service requests. The passive node constantly
keeps its database synchronized with that of the active node, so it can take over service if a failover occurs. (A failover
is basically the reversal of the active/passive roles of each node; that is, when a failover occurs, the previously active
node becomes passive and the previously passive node becomes active.) Events can trigger a failover or you can
deliberately force it to happen (see Forcing an HA Failover on page 199).
So that the two physical nodes can appear as a single entity on the network, they share a single VIP (virtual IP)
address and virtual MAC address. The VIP and virtual MAC addresses link to the HA port on each node. Whichever
node is currently active is the one whose HA port owns the VIP and virtual MAC addresses. If a failover occurs, these
addresses shift from the HA port of the previous active node to the HA port of the new active node (see Figure 8.6).
Figure 8.6 VIP Address and Virtual MAC Address and HA Failover
Infoblox HA Pair
bloxSYNC
Node 1
Active
Encrypted VPN Tunnel
HA Port
HA Port
The clients always make service requests
to—and receive replies from—the VIP
and virtual MAC address.
Node 2
Passive
VIP
and
Virtual MAC
Address
The HA ports on each node of an HA pair
share the VIP (virtual IP) address and
virtual MAC address. Because Node 1 is
currently active, it owns these addresses.
Network Clients
After an HA Failover …
Node 1
Passive
Node 2
Active
HA Port
HA Port
The clients still make service requests
to—and receive replies from—the
same VIP and virtual MAC address.
VIP
and
Virtual MAC
Address
After an HA failover occurs, Node 2
becomes the active node. Because Node 2
is now active, it now owns the VIP address
and virtual MAC address.
Network Clients
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
181
Deploying Independent Devices
The two nodes in an HA pair include a VRID (virtual router ID) in all VRRP advertisements and use it to recognize VRRP
advertisements intended just for themselves. Only another device on the same subnet configured to use the same
VRID responds to the announcements. The VRID must be a unique number between 1 and 255 for the subnet on
which the HA pair is located. (There is no default VRID number.) For more information, see RFC 3768, Virtual Router
Redundancy Protocol (VRRP), and also VRRP Advertisements on page 212.
Figure 8.7 VRRP Advertisements with a Unique VRID
After you finish configuring Node 1 of the HA pair to use
VRID 10—a number that is unique for this subnet—it starts
listening for VRRP advertisements with that VRID. When it
does not receive any for three seconds, it becomes the
active node in the HA pair and begins multicasting VRRP
advertisements with a VRID 10 from its HA port.
Any device on that subnet that is not
configured to listen for VRRP advertisements
with VRID 10 drops the packet.
VRRP
Advertisements
Node 1
(Active)
Switch
MATCH!
Subnet
Node 2
(Passive)
After you finish configuring Node 2
to join the HA pair, it initiates a
connection with Node 1. The two
devices establish a VPN tunnel
between themselves, using the HA
connection name and shared
secret to authenticate each other.
Node 2 downloads the database
from Node 1 and learns its VRID.
Node 2 then begins listening for
VRRP advertisements on its HA
port. When it receives an
advertisement from Node 1, Node
2 recognizes it and becomes the
passive node.
To deploy an independent HA pair, you cable the HA and LAN (or LAN1) ports to the network and configure the IP
settings for these ports and the VIP address within the same subnet.
Note: On Infoblox-500, -1000, and -1200 appliances, the LAN port is labeled LAN . On Infoblox-550, -1050, -1550,
and -1552 appliances, use the port labeled LAN1 . (The LAN2 port is reserved for future use.)
The default LAN settings are as follows:
•
IP address: 192.168.1.2
•
Netmask: 255.255.255.0
•
Gateway: 192.168.1.1.
Infoblox provides two methods for configuring an HA pair:
•
Method 1 – Using the Infoblox NIOS Startup Wizard
— Requirements: HTTPS connections from your management system to the ethernet ports on the two devices
— Advantage: The startup wizard provides step-by-step guidance for configuring the network settings of the
VIP address and HA and LAN (or LAN1) ports on both nodes, for setting the host name, admin password,
and system clock, and—if using NTP (Network Time Protocol)—for enabling the HA pair as an NTP server.
•
Method 2 – Using the GUI
— Requirements: HTTPS connections from your management system to the ethernet ports on the two devices
— Advantage: If you have logged in previously and disabled the startup wizard, you can still use the GUI to
configure an independent HA pair.
These methods are explained in the following subsections.
182
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deploying an Independent HA Pair
Method 1 – Using the Infoblox NIOS Startup Wizard
When you first make an HTTPS connection to the Infoblox device, the Infoblox NIOS Startup Wizard appears. To ease
the initial configuration process, the wizard guides you through various deployment options, basic network settings,
and opportunities for changing the password of the superuser admin and for setting the system clock.
Configuring the Connecting Switch
To ensure that VRRP (Virtual Router Redundancy Protocol) works properly, configure the following settings on the
network switch to which you cable the two nodes:
•
Portfast: enable
•
Trunking: disable
•
Port list: disable
•
Port channeling: disable
Note: By default, an Infoblox device automatically negotiates the optimal connection speed and transmission type
(full or half duplex) on the physical links between its LAN (or LAN1), HA, and MGMT ports and the ethernet
ports on the connecting switch. If the two devices fail to auto-negotiate the optimal settings, see Modifying
Ethernet Port Settings on page 87 for steps you can take to resolve the problem.
Putting Both Nodes on the Network
1. Use one of the methods described in Deploying a Single Independent Device on page 169 to configure the
network settings of the LAN or LAN1 port of each node so that they are on the same subnet and you can reach
them across the network.
2. Cable the LAN (or LAN1) port and the HA port on each node to the network switch.
Note: The ethernet ports on the Infoblox-550, -1050, -1550, and -1552 appliances are autosensing, so you can
use either a straight-through or cross-over ethernet cable for these connections. For the Infoblox-500,
-1000, and -1200 appliances, use straight-through ethernet cables to connect a device to a switch.
3. Cable your management system to the network switch.
Configuring Node 1
1. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port of Node 1.
Several certificate warnings appear during the login process. This is normal because the preloaded certificate is
self-signed (and, therefore, is not in the trusted certificate stores in your browser, Java application, and Java
Web Start application) and has the hostname www.infoblox.com, which does not match the destination IP
address you entered in step 1. To stop the warning messages from occurring each time you log in to the GUI, you
can generate a new self-signed certificate or import a third-party certificate with a common name that matches
the FQDN (fully qualified domain name) of the device. This is a very simple process. For information about
certificates, see Managing Certificates on page 41.
2. Click LAUNCH DEVICE MANAGER.
3. Log in to Node 1. For detailed information about logging in to the GUI, see Accessing the Infoblox GUI on page 34.
The Infoblox NIOS Startup Wizard appears. The first screen provides basic information about the wizard, and the
second screen displays license agreement information.
4. Beginning on the third screen, enter the following, where
— string1 is a text string that the two nodes use to authenticate each other when establishing a VPN tunnel for
ensuing bloxSYNC traffic. (The default grid name is Infoblox.)
— string2 is a text string that both nodes use as a shared secret to authenticate each other when establishing
a VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
— vip_addr and netmask are the VIP (virtual IP) address and its netmask.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
183
Deploying Independent Devices
— ip_addr1 is the IP address of the gateway for the subnet on which the LAN or LAN1 port is set.
— hostname is a valid domain name for the device.
— ip_addr2-5 are the IP addresses of the LAN and HA ports for Nodes 1 and 2.
— number is the VRID (virtual router ID). This must be a unique VRID number—from 1 to 255—for this subnet.
— string3 is a single alphanumeric string (no spaces) for a password that is at least four characters long.
— ip_addr6 is the IP address of an NTP (Network Time Protocol) server.
Wizard Screen
Enter or Select
Deployment Type
Independent Device or HA Pair
Independent Device Deployment Type
HA Node 1
HA Pair Settings
HA Pair Name: string1
Shared Secret: string2
Node 1 Network Settings
VIP Address: vip_addr
Netmask: netmask
Gateway: ip_addr1
Host Name: hostname
Node 1: LAN/LAN1 Address: ip_addr2
HA Address: ip_addr3
Node 2: LAN/LAN1 Address: ip_addr4
HA Address: ip_addr5
Virtual Router ID: number
Admin Account Password
Change Admin Password: (select), string3
Time Settings
Enable NTP: (select)
NTP Server List: ip_addr6 (click Add)
Time zone: (choose the time zone for the location of the device)
Note: The startup wizard provides options such as not changing the default password and manually entering the
time and date. However, changing the password and using an NTP server improve security and accuracy
(respectively), and so these choices are presented above.
The last screen of the startup wizard states that the changed settings require the device to restart. When you
click Finish, the device restarts.
184
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Deploying an Independent HA Pair
Configuring Node 2
1. Open a new browser instance and make an HTTPS connection to the IP address of the LAN or LAN1 port of Node 2.
2. The Infoblox NIOS Startup Wizard opens with a splash screen that provides basic information about the wizard,
and then displays license agreement information. Beginning on the third wizard screen, enter the following to set
up Node 2 (the variables are explained in the previous section for Node 1):
Wizard Screen
Enter or Select
Deployment Type
Independent Device or HA Pair
Independent Device Deployment Type
HA Node 2
Node 2 Network Settings
IP Address: ip_addr4
Netmask: netmask
Gateway: ip_addr1
HA Pair Properties
Virtual IP Address: vip_addr
HA Pair Name: string1
Shared Secret: string2
The setup of the HA pair is complete. When you next make an HTTPS connection to the HA pair, use the VIP address.
Method 2 – Using the GUI
To deploy an independent HA pair through the GUI, you need to make an HTTPS connection to each device and then
bypass the startup wizard. (The following procedure assumes that the device has the DNSone package installed.)
Configuring the Connecting Switch
To ensure that VRRP (Virtual Router Redundancy Protocol) works properly, configure the following settings on the
network switch to which you cable the two nodes:
•
Portfast: enable
•
Trunking: disable
•
Port list: disable
•
Port channeling: disable
Note: By default, an Infoblox device automatically negotiates the optimal connection speed and transmission type
(full or half duplex) on the physical links between its LAN (or LAN1), HA, and MGMT ports and the ethernet
ports on the connecting switch. If the two devices fail to auto-negotiate the optimal settings, see Modifying
Ethernet Port Settings on page 87 for steps you can take to resolve the problem.
Putting Both Nodes on the Network
1. Use one of the methods described in Deploying a Single Independent Device on page 169 to configure the
network settings of the LAN or LAN1 port of each node so that they are on the same subnet and you can reach
them across the network.
2. Cable the LAN (or LAN1) port and the HA port on each node to a switch on the network.
Note: The ethernet ports on an Infoblox device are autosensing, so you can use either a straight-through or
cross-over ethernet cable for these connections. For the Infoblox-500, -1000, and -1200 appliances, use
straight-through ethernet cables to connect a device to a switch.
3. Connect your management system to the network.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
185
Deploying Independent Devices
Configuring Node 1
1. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port of Node 1.
2. Click LAUNCH DEVICE MANAGER.
3. Log in to Node 1. For detailed information about logging in to the GUI, see Accessing the Infoblox GUI on page 34.
The Infoblox NIOS Startup Wizard appears.
4. To bypass the wizard and access the Device Manager GUI, click Cancel or the Close button (⌧).
5. From the Device perspective, click hostname -> Edit -> Device Properties.
Note: (For the DNSone with Keystone package) From the Grid perspective, click + (for Infoblox) -> + (for Members)
-> hostname -> Edit -> Member Properties.
6. In the Device editor, click Device Properties, and then enter the following network settings:
— Host Name: Type the FQDN (fully qualified domain name) for the HA pair.
— (V)IP Address: Type the VIP (virtual IP) address for the HA pair.
— Subnet Mask: Choose the netmask for the subnet to which the VIP address connects.
— Gateway: Type the IP address of the default gateway of the subnet to which the VIP address connects.
— Comment: Type a comment that provides some useful information about the HA pair, such as its location.
— High-availability Pair: (select)
— Virtual Router ID: Enter a unique VRID number—from 1 to 255—for the local subnet.
Note: The VIP address and the IP addresses for all the following ports must be in the same subnet.
— Node #1:
•
LAN Address: Enter an IP address for the LAN (or LAN1) port of Node 1.
•
HA Address: Enter an IP address for the HA port of Node 1.
— Node #2:
•
LAN Address: Enter an IP address for the LAN (or LAN1) port of Node 2.
•
HA Address: Enter an IP address for the HA port of Node 2.
7. In the Device editor, click High Availability Connection, and then enter the following settings:
— Name: Type a name for the HA pair. (The default name is Infoblox.)
— Shared Secret: Type the shared secret that both nodes use to authenticate each other when establishing a
VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
— Retype Shared Secret: Retype the shared secret you entered in the Shared Secret field.
— VPN Port Number: Leave as the default number (1194), or enter a different number for the two nodes to use
when building a VPN tunnel between themselves.
8. Click Save.
The management window closes.
186
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
Configuring Node 2
1. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port of Node 2.
2. Click LAUNCH DEVICE MANAGER.
3. Log in to Node 2.
The Infoblox NIOS Startup Wizard appears.
4. To bypass the wizard, click Cancel or the Close button (⌧).
5. From the Device perspective, click hostname -> Edit -> Join HA Pair.
Note: (For the DNSone with Keystone package) From the Grid perspective, click + (for Infoblox) -> + (for Members)
-> hostname -> Edit -> Join Grid.
6. In the Join HA Pair dialog box, enter the following network settings:
— Virtual IP of HA Pair: Type the VIP (virtual IP) address for the HA pair.
— HA Connection Name: Type the same text string that you typed in the Name field in the High Availability
Connection section of the Device editor on Node 1. (The default HA connection name is Infoblox.)
— Shared Secret: Type the shared secret that both nodes use to authenticate each other when establishing a
VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
— Retype Shared Secret: Retype the shared secret you entered in the Shared Secret field.
— VPN Port Number: Leave as the default number (1194), or enter a different number for the two nodes to use
when building a VPN tunnel between themselves.
7. Click Save.
The management window closes.
Configuration Example: Configuring an HA Pair for Internal DNS
and DHCP
In this example, you set up an HA pair of Infoblox devices to provide internal DNS and DHCP services. The HA pair
answers internal queries for all hosts in its domain (corp100.com). It forwards internal queries for external sites to
ns1.corp100.com at 10.1.5.2 and ns2.corp100.com at 2.2.2.2. It also uses DHCP to provide dynamic and fixed
addresses.
The HA pair consists of two devices (nodes). The IP addresses of the VIP (virtual IP) address of the HA pair and the HA
and LAN1 ports on each node, are as follows:
HA Pair IP Addresses
VIP 10.1.4.10 (the address that the active node of the HA pair uses)
Node 1
Node 2
•
LAN1 10.1.4.6
•
LAN1 10.1.4.8
•
HA 10.1.4.7
•
HA 10.1.4.9
The virtual router ID number for the HA pair is 150. (The ID number must be unique for this network segment.)
When you create the corp100.com zone on the HA pair, you import DNS data from the legacy server at 10.1.4.11.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
187
Deploying Independent Devices
Figure 8.8 Example 2 Network Diagram
ftp
10.1.5.7
77:77:77:77
Internet
ISP
NOTE: The first six
hexadecimal characters of
all MAC addresses in the
example are 00:00:00:00.
Only the last six
hexadecimal characters are
shown here.
ethernet1
1.1.1.1/24
Firewall
Relay Agent on
e2 interface)
External Secondary
DNS Server
ns2: 2.2.2.2
DMZ Network
10.1.5.0/24
ethernet2
10.1.5.1/24
ethernet3
10.1.6.2/24
www
10.1.5.5
55:55:55:55
External Primary
DNS Server
ns1: 10.1.5.2
mail
10.1.5.6
66:66:66:66
MGT Network
10.1.1.0/24
ethernet0
10.1.6.1/24
10.1.1.10 10.1.1.50
Address
Range
printer1
10.1.1.2
aa:aa:aa
ethernet1
10.1.1.1/24
ethernet2
10.1.2.1/24
Dev Network
HA Pair Internal Primary
DNS Server
DHCP, IPAM
ns3 VIP: 10.1.4.10
ethernet4
10.1.4.1/24
Server Network
10.1.4.0/24
10.1.2.0/24
10.1.2.10 10.1.2.50
Legacy Primary DNS Server
ns3: 10.1.4.11
(Replaced by the HA Pair)
storage1
proxymail
10.1.4.2
10.1.4.f
dd:dd:dd:dd ff:ff:ff:ff
storage2
proxyweb
10.1.4.3
10.1.4.5
ee:ee:ee:ee 11:11:11:11
An HA pair of Infoblox devices provides internal DNS services. It answers internal queries for all hosts in its
domain. It forwards internal queries for external sites to ns1 and ns2. It also serves DHCP, providing both
dynamic and fixed addresses. For information on configuring the Infoblox device external primary DNS server,
see Configuration Example: Deploying an Infoblox Device for External DNS on page 174.
Address
Range
printer2
10.1.2.2
bb:bb:bb
Cable Devices to the Network and Turn On Power
Connect ethernet cables from the LAN1 and HA ports on both Infoblox devices to a switch in the Server network and
turn on the power for both devices. For information about installing and cabling the device, refer to the user guide or
installation guide that ships with the product.
188
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
Specify Initial Network Settings
Before you can configure the devices through the GUI, you must be able to make a network connection to them. The
default network settings of the LAN1 port are 192.168.1.2/24 with a gateway at 192.168.1.1 (the HA and MGMT ports
do not have default network settings). To change these settings, you can use the LCD or make a console connection
to each device.
Node 1
Using the LCD or console port on one of the devices, enter the following information:
— IP Address: 10.1.4.6 (for the LAN1 port)
— Netmask: 255.255.255.0
— Gateway: 10.1.4.1
Node 2
Using the LCD or console port on the other device, enter the following information:
— IP Address: 10.1.4.8 (for the LAN1 port)
— Netmask: 255.255.255.0
— Gateway: 10.1.4.1
After you confirm your network settings, the Infoblox GUI application automatically restarts.
Specify Device Settings
When you make the initial HTTPS connection to an Infoblox device, you see the Infoblox Appliance Startup Wizard,
which guides you through the basic deployment of the device on your network. To set up an HA pair, you must connect
to and configure each device individually.
Node 1
1. Open a browser window and connect to https://10.1.4.6.
Note: For details about making an HTTPS connection to an Infoblox device, see Specify Device Settings on page
175.
2. Log in using the default user name and password admin and infoblox.
Note: User names and passwords are case-sensitive.
3. The Infoblox Appliance Startup Wizard opens with a splash screen that provides basic information about the
wizard, and then displays license agreement information. Beginning on the third wizard screen, enter or select
the following to set up node 1 of the HA pair:
Wizard Screen
Enter
Deployment type
Stand alone
Node type
First HA node
Grid information
Grid Name: Infoblox
Shared Secret: 37eeT1d
(Note: The nodes use the shared secret to form an
encrypted VPN tunnel between themselves. They
synchronize the shared database through this tunnel.)
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
189
Deploying Independent Devices
Wizard Screen
Enter
Node information
Virtual IP: 10.1.4.10
Subnet Mask: 255.255.255.0
Gateway: 10.1.4.1
Host Name: ns3.corp100.com
Node 1:
LAN1 Address: 10.1.4.6
HA Address: 10.1.4.7
Node 2:
LAN1 Address: 10.1.4.8
HA Address: 10.1.4.9
Virtual Router ID: 150
Default password
New admin password: SnD34n534
Time settings
Enable NTP: Select check box.
IP address: 3.3.3.3
Time zone: (UMT – 8:00 Pacific Time (US and Canada),
Tijuana
The last screen of the wizard states that the changed settings require the application to restart. When you click
Finish, the Infoblox GUI application restarts.
Node 2
1. In the JWS (Java Web Start) login window, type 10.1.4.8 in the Hostname field.
When you enter the IP address, JWS queries the device at that address, checking for a login banner. The
following default Infoblox banner appears above the Hostname field: “Restricted Access – Login Required”.
2. Log in using the default user name and password admin and infoblox.
Note: User names and passwords are case-sensitive.
3. The Infoblox Appliance Startup Wizard opens with a splash screen that provides basic information about the
wizard, and then displays license agreement information. Beginning on the third wizard screen, enter or select
the following to set up node 2 of the HA pair:
Wizard Screen
Enter or Select
Deployment type
Stand alone
Node type
Second HA node
Node information
IP Address: 10.1.4.8
Subnet Mask: 255.255.255.0
Gateway: 10.1.4.1
Node provisioning
Master’s Virtual IP: 10.1.4.10
Grid Name: Infoblox
Shared Secret: 37eeT1d
On the last screen of the wizard, click Finish. The Infoblox GUI application terminates.
190
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
The setup of the HA pair is complete. From now on, when you make an HTTPS connection to the HA pair, use the VIP
address 10.1.4.10.
Enable Zone Transfers on the Legacy Name Server
To allow the Infoblox device to import zone data from the legacy server at 10.1.4.11, you must configure the legacy
server to allow zone transfers to the device at 10.1.4.10.
Legacy BIND Server
1. Open the named.conf file using a text editor and change the allow-transfer statement to allow zone transfers to
the device at 10.1.4.10. (For a sample of the required changes to the named.conf file, see Legacy BIND Server on
page 177.)
2. After editing the named.conf file, restart DNS service for the change to take effect.
Legacy Windows 2000/2003 Server
Navigate to the corp100.com Properties dialog box, and add 10.1.4.10 to the list of IP addresses to which you want
to allow zone transfers. (For more detailed navigation and configuration instructions, see Legacy Windows
2000/2003 Server on page 177.)
Import Zone Data
You can import zone data from a legacy server or manually enter it. When you import both forward- and
reverse-mapping zone data, the Infoblox device automatically creates Infoblox host records if corresponding A and
PTR records are present. You can then modify the host records to add MAC addresses. However, if you only import
forward-mapping zone data, the Infoblox device cannot create host records from just the A records. In that case,
because you cannot later convert A records to host records, it is more efficient to create the corp100.com zone, and
define host records manually.
Infoblox host records are data models that represent IP devices within the Infoblox semantic database. The Infoblox
device uses a host object to define A, PTR, and CNAME resource records in a single object as well as a DHCP fixed
address if you include a MAC address in the host object definition. The host object prevents costly errors because
you only maintain a single object for multiple DNS records and a DHCP fixed address. Therefore, it is advantageous
to use host records instead of separate A, PTR, and CNAME records.
Note: If you only have forward-mapping zones defined on your legacy servers and you want to add reverse-mapping
zones and automatically create host records in the imported forward-mapping zones and reverse host records
in corresponding reverse-mapping zones, create the reverse-mapping zones and then import the
forward-mapping zones data. The Infoblox device automatically converts the imported A records to host
records in the forward-mapping zones and creates the necessary reverse host records in the reverse-mapping
zones.
You also have the option of using the Data Import Wizard for loading DNS and DHCP configurations and data. For large
data sets, this option is an efficient approach. To download the Data Import Wizard, visit www.infoblox.com/support,
log in with your support account, and then click the Data Import Wizard hyperlink in the DNSone section.
In this example, when you create the corp100.com forward-mapping zone, you import zone data for the existing
corp100.com zone from the legacy server at 10.1.4.11. When you create the 1.10.in-addr.arpa reverse-mapping
zone, you also import the zone records for the existing 1.10.in-addr.arpa zone from the legacy server. After the device
has both the forward- and reverse-mapping zone data, it converts the A and PTR records to Infoblox host records.
1. Open a browser window, and log in to the HA pair at https://10.1.4.10, using the user name admin and the
password SnD34n534.
2. To check that the HA pair is set up and functioning properly, from the Device perspective, click ns3.corp100.com
and check that the status indicators are all green.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
191
Deploying Independent Devices
3. Click DNS to open the DNS perspective, and then click Infoblox Views -> + (for Infoblox Views) -> + (for default) ->
Forward Mapping Zones -> Edit -> Add Forward Mapping Zone -> Authoritative.
4. In the Authoritative Zone Properties section of the Add Forward Authoritative Zone editor, enter the following:
— Name: corp100.com
— Comment: Internal DNS zone
5. In the Primary Server Assignment section, click Select Member to open the Select Grid Member dialog box.
6. Select ns3.corp100.com, and then click OK to close the dialog box.
7. Click the Save icon.
8. In the Infoblox Views panel of the DNS perspective, click + (for Forward Mapping Zones) -> corp100.com -> Edit ->
Authoritative Zone Properties.
9. In the Forward Authoritative Zone editor, click Settings and enter the following:
— E-mail address: [email protected]
— Import zone from: Select this check box, and enter 10.1.4.11 in the adjacent text field.
10. Click the Save icon.
11. After successfully importing the zone data, click corp100.com in the Infoblox Views panel.
You can see all the imported forward-mapping zone data in the Records panel. Because you have not yet
imported the reverse-mapping zone data, most of the records appear as A records.
12. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> Reverse Mapping
Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
13. In the Authoritative Zone Properties section of the Add Reverse Authoritative Zone editor, enter the following:
— Network Address: 10.1.0.0
— Subnet Mask: 255.255.0.0
— Comment: Internal DNS zone
14. In the Primary Server Assignment section, click Select Member to open the Select Grid Member dialog box.
15. Select ns3.corp100.com, and then click OK to close the dialog box.
16. Click the Save icon.
17. In the Infoblox Views panel of the DNS perspective, click + (for Reverse Mapping Zones) -> 1.1.1.in-addr.arpa ->
Edit -> Authoritative Zone Properties.
18. In the Authoritative Reverse Zone editor, click Settings and enter the following:
— E-mail address: [email protected]
— Import zone from: Select this check box, and enter 10.1.4.11 in the adjacent text field.
19. Click the Save and Restart Services icons.
20. Click 1.1.1.in-addr.arpa -> View -> Records.
You can see all the imported reverse-mapping zone data in the Records panel.
21. Click corp100.com in the Infoblox Views panel.
Because you have now imported both the forward- and reverse-mapping zone data, most of the records appear
as host records.
22. Finally, you must remove the ns1 host record for the legacy server (value 10.1.4.11). To remove it, select ns3, and
then click Edit -> Remove.
Define Networks, Reverse-Mapping Zones, DHCP Ranges, and Infoblox Hosts
In this task, you enter data manually because the configuration is fairly simple. For large data sets, you have the
option of using the Data Import Wizard for loading DNS and DHCP configurations and data to make the process more
efficient. To download the Data Import Wizard, visit www.infoblox.com/support, log in with your support account, and
then click the Data Import Wizard hyperlink in the DNSone section.
192
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
Networks
You can create all the subnetworks individually (which in this example are 10.1.1.0/24, 10.1.2.0/24, 10.1.4.0/24,
and 10.1.5.0/24), or you can create a parent network (10.1.0.0/16) that encompasses all the subnetworks and then
use the Infoblox split network feature to create the individual subnetworks automatically. The split network feature
accomplishes this by using the IP addresses that exist in the forward-mapping zones to determine which subnets it
needs to create. This example uses the split network feature. For information about creating networks, see
Configuring a DHCP Network on page 350.
1. From the DHCP and IPAM perspective, click Networks -> Edit -> Add Network -> Network.
2. In the Network Properties section of the Add Configure Network editor, enter the following:
— Network Address: 10.1.0.0
— Netmask: /16 (255.255.0.0)
3. Click Member Assignment -> Add to open the the Select Grid Members dialog box.
4. Select ns3.corp100.com, and then click OK to close the dialog box.
5. Click the Save icon.
6. Click + (for Networks) -> 10.1.0.0/16 -> Edit -> Split Network.
— Subnetworks: Move the slider to 24.
— Immediately add only networks with ranges and fixed addresses: Select this check box.
The device immediately creates the following 24-bit subnets for the imported Infoblox hosts:
— 10.1.1.0/24
— 10.1.2.0/24
— 10.1.4.0/24
— 10.1.5.0/24
7. Click -> + (for Networks) -> + (for 10.1.0.0/16) -> 10.1.1.0/24 -> Edit -> Network Properties.
8. In the Configure Network editor, enter information in the following sections:
Network Properties
— Comment: MGT
Member Assignment
— Members: ns3.corp100.com
9. Click the Save icon.
10. To modify the other networks, repeat steps #8 – 10 for each network and use the following information:
10.1.2.0/24 Network:
— Comment: Dev
— Members: ns3.corp100.com
10.1.4.0/24 Network:
— Comment: Server
— Members: ns3.corp100.com
10.1.5.0/24 Network:
— Comment: DMZ
— Members: ns3.corp100.com
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
193
Deploying Independent Devices
Reverse-Mapping Zones
When you create a network, the device automatically creates a corresponding reverse-mapping zone and “reparents”
the relevant resource records from the parent zone (10.1.0.0/16) to that zone. To enable DNS service for the new
zone, you need to assign ns3.corp100.com as the primary DNS server for each zone. In this example, the device
creates four reverse-mapping zones. You must modify each zone by assigning ns3.corp100.com as its primary DNS
server.
1. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> + (for Reverse Mapping
Zones) -> + (for 1.10.in-addr.arpa) -> 1.1.10.in-addr.arpa -> Edit -> Authoritative Zone Properties.
2. In the Primary Server Assignment section, click Select Member to open the Select Grid Member dialog box.
3. Select ns3.corp100.com, and then click OK to close the dialog box.
4. Click the Save icon.
5. Repeat steps #1–4 for the 2.1.10.in-addr.arpa, 4.1.10.in-addr.arpa, and 5.1.10.in-addr.arpa reverse-mapping
zones.
DHCP Ranges
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> + (for 10.1.0.0/16) -> 10.1.1.0/24 ->
Edit -> Add DHCP Range.
2. In the DHCP Range section, enter the following:
Start Address: 10.1.1.10
End Address: 10.1.1.50
3. In the Member Assignment section, select ns3.corp100.com from the Grid Member drop-down list.
4. Click the Save icon.
5. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> + (for 10.1.0.0/16) -> 10.1.2.0/24 ->
Edit -> Add DHCP Range.
6. In the DHCP Range section, enter the following:
Start Address: 10.1.2.10
End Address: 10.1.2.100
7. In the Member Assignment section, select ns3.corp100.com from the Grid Member drop-down list.
8. Click the Save icon.
Infoblox Hosts
Defining both a MAC and IP address for an Infoblox host definition creates a DHCP host entry—like a fixed address—
that you can manage through the host object. To add a MAC address to each host record that the device created when
you imported forward- and reverse-mapping zone records, you must first delete the IP address for that host, and then
add the same IP address with the MAC address.
1. From the DNS perspective, click Infoblox Views -> + (for Infoblox Views) -> + (for default) -> + (for Forward Mapping
Zones) -> + (for corp100.com).
2. Double-click 10.1.1.2 to open the Host editor.
3. In the Host Record Properties section, select 10.1.1.2, and then click Remove.
4. Click Add next to the IP Address field to open the Host Address dialog box.
5. Enter the following, and then click OK to close the dialog box:
— IP Address: 10.1.1.2
— MAC Address: 00:00:00:aa:aa:aa
6. Click the Save icon.
7. Follow steps 1 – 6 to modify hosts with the following information:
printer2
194
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
— IP Address: 10.1.2.2
— MAC Address: 00:00:00:bb:bb:bb
storage1
— IP Address: 10.1.4.2
— MAC Address: 00:00:00:dd:dd:dd
storage2
— IP Address: 10.1.4.3
— MAC Address: 00:00:00:ee:ee:ee
proxymail
— IP Address: 10.1.4.4
— MAC Address: 00:00:00:ff:ff:ff
proxyweb
— IP Address: 10.1.4.5
— MAC Address: 00:00:00:11:11:11
www
— IP Address: 10.1.5.5
— MAC Address: 00:00:00:55:55:55
mail
— IP Address: 10.1.5.6
— MAC Address: 00:00:00:66:66:66
ftp
— IP Address: 10.1.5.7
— MAC Address: 00:00:00:77:77:77
Define Multiple Forwarders
Because ns3.corp100.com is an internal DNS server, you configure it to forward DNS queries for external DNS name
resolution to the primary and secondary DNS servers—ns1.corp100.com at 10.1.5.2 and ns2.corp100.com at
2.2.2.2.
1. From the DNS perspective, click DNS Members -> Infoblox -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Forwarders, and then enter the following:
— IP Address: Type 2.2.2.2, and then click Add.
— IP Address: Type 10.1.5.2, and then click Add.
— Use Forwarders Only: Clear the check box.
3. Click the Save icon.
The Infoblox device initially sends outbound queries to forwarders in the order that they appear in the Forwarders list,
starting from the top of the list. If the first forwarder does not reply, the device tries the second one. The device keeps
track of the response time of both forwarders and uses the quicker one for future queries. If the quicker forwarder
does not respond, the device then uses the other one.
Enable Recursion on External DNS Servers
Because the HA pair forwards outbound queries to the two external DNS servers ns1.corp100.com (10.1.5.2) and
ns2.corp100.com (2.2.2.2) for resolution, you must enable recursion on those servers. When a DNS server employs
recursion, it queries other DNS servers for a domain name until it either receives the requested data or an error that
the requested data cannot be found. It then reports the result back to the querist—in this case, the internal DNS
server ns3.corp100.com (10.1.4.10), which in turn reports back to the DNS client.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
195
Deploying Independent Devices
Infoblox Server in the DMZ Network (ns1.corp100.com, 10.1.5.2)
1. Log in to ns1.corp100.com at 10.1.5.2.
2. From the DNS perspective, click DNS Members -> Infoblox -> Edit -> Grid DNS Properties.
3. In the Grid DNS Properties editor, click Queries, and then select the Allow Recursion check box.
4. Click the Save icon.
BIND Server at ISP Site (ns2.corp100.com, 2.2.2.2)
1. Open the named.conf file using a text editor and change the recursion and allow-recursion statements to allow
recursive queries from 1.1.1.8 (the NAT address of ns3).
options {
zone-statistics yes;
directory "/var/named/named_conf";
version "";
recursion yes;
listen-on { 127.0.0.1; 2.2.2.2; };
…
allow-recursion { 1.1.1.8; };
transfer-format many-answers;
};
2. After editing the named.conf file, restart DNS service for the change to take effect.
Windows 2000/2003 Server at ISP Site (ns2.corp100.com, 2.2.2.2)
1. Click Start -> All Programs -> Administrative Tools -> DNS.
2. Right-click ns3, and then select Properties -> Advanced.
3. On the Advanced page in the ns3 Properties dialog box, clear the Disable recursion check box.
4. To save the configuration change and close the ns3 Properties dialog box, click OK.
Modify the Firewall and Router Configurations
Configure the firewall and router in your internal network to allow the following DHCP, DNS, and NTP traffic:
•
To allow messages to pass from the DHCP clients in the DMZ—the web, mail, and FTP servers—to ns3 in the
Server network, configure policies and DHCP relay agent settings on the firewall.
•
To forward DHCP messages from DHCP clients in the MGT and Dev networks to ns3 in the Server network,
configure relay agent settings on the router.
•
To translate the private IP address of ns3 (10.1.4.10) to the public IP address (1.1.1.8) when forwarding DNS
queries from ns3 to ns2, set a MIP (mapped IP) address on the firewall.
•
To allow DNS queries from ns3 to ns1 and ns2 and NTP traffic from ns3 to the NTP server, configure firewall
policies.
Firewall
For example, enter the following commands on a Juniper firewall running ScreenOS 4.x or later:
DHCP Relay Configuration
set address trust ns3 10.1.4.10/32
set interface ethernet2 dhcp relay server-name 10.1.4.10
set policy from dmz to trust ns1 ns3 DHCP-Relay permit
DNS Forwarding
set interface ethernet1 mip 1.1.1.8 host 10.1.4.10
196
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring an HA Pair for Internal DNS and DHCP
set policy from trust to untrust ns3 ns2 dns permit
set policy from trust to dmz ns3 ns1 dns permit
NTP
set policy from dmz to untrust ns1 ntp_server ntp permit
Router
For example, enter the following commands on a Cisco router running IOS for release 12.x or later:
DHCP Relay Configuration
interface ethernet1
ip helper-address 10.1.4.10
interface ethernet2
ip helper-address 10.1.4.10
Enable DHCP and Switch Service to the Infoblox Device
With the Infoblox in place and the firewall and router configured for relaying DHCP messages, you can switch DHCP
service from the legacy DHCP server at 10.1.4.11 to the HA pair at 10.1.4.10 (VIP address).
Tip: To minimize the chance of duplicate IP address assignments during the transition from the legacy DHCP server
to the device, shorten all lease times to a one-hour length in advance of the DHCP server switch. Then, when you
take the legacy DHCP server offline, the DHCP clients quickly move to the new server when their lease renewal
efforts fail and they broadcast DHCPDISCOVER messages. To determine how far in advance you need to shorten
the lease length, find the longest lease time (for example, it might be two days). Then change the lease length
to one hour at a slightly greater interval of time before you plan to switch DNS service to the device (for example,
three days before the switch over). By changing the lease length this far in advance, you can be sure that all
DHCP leases will be one-hour leases at the time of the switchover. If the longest lease length is longer—such as
five days—and you want to avoid the increased amount of traffic caused by more frequent lease renewals over
a six-day period, you can also employ a stepped approach: Six days before the switchover, change the lease
lengths to one-day leases. Then two days before the switchover, change them to one-hour leases.
1. Open a browser window, and log in to the HA pair at https://10.1.4.10, using the user name admin and the
password SnD34n534.
2. From the DHCP and IPAM Perspective, select DHCP Members -> + (for Infoblox) -> ns3.corp100.com -> Edit ->
Member DHCP Properties.
3. In the Member DHCP Properties editor, click General Properties and select Enable DHCP Server.
4. Click the Save and Restart Services icons.
The HA pair is ready to provide DHCP service to the network.
5. Take the legacy DHCP server at 10.1.4.11 offline.
When the DHCP clients are unable to renew their leases from the legacy DHCP server, they broadcast
DHCPDISCOVER messages to which the new DHCP server responds.
Manage and Monitor
Infoblox provides tools for managing IP address usage and several types of logs to view events of interest and DHCP
and DNS data. After configuring the device, you can use the following resources to manage and monitor IP address
usage, DNS and DHCP data, and administrator and device activity.
IPAM (IP Address Management)
IPAM offers the following services:
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
197
Deploying Independent Devices
•
Simple IP address modification – Within a single IP address-centric data set, you can modify the Infoblox host,
DHCP, and DNS settings associated with that IP address.
•
Address type conversion — Through IPAM functionality, you can make the following conversions:
— Currently active dynamic addresses -> fixed addresses, reserved addresses, or Infoblox hosts
— Fixed addresses -> reserved addresses or hosts
— Reserved addresses -> hosts
•
Device classification – You can make detailed descriptions of devices in DHCP ranges and devices defined as
Infoblox hosts and as fixed addresses.
•
Three distinct views of IP address usage – To monitor the usage of IP addresses on your network, you can see
the following different views:
— High-level overall network view: From the DHCP and IPAM perspective, click DHCP Members -> + (for
Infoblox) -> 10.1.4.10 -> View -> IPAM Statistics.
— Run-time view that allows you to zoom in and out to varying levels of detail: From the DHCP and IPAM
perspective, click Networks -> network -> View -> IP Address Management -> ip_addr -> View -> Properties.
— DHCP lease history records: From the DHCP and IPAM perspective, click View -> DHCP Lease History.
Logs
The following are some useful logs:
•
Logs
— Audit Log – Contains administrator-initiated events
— System Log – Contains events related to hardware and software operations
•
IPAM
— IPAM Statistics – Contains the number of currently assigned static and dynamic addresses, and the high
and low watermarks per network
•
DNS
— DNS Cache – Contains cached DNS-to-IP address mappings
— DNS Configuration – Contains DNS server settings for the Infoblox DNS server
— Zone Statistics – Contains a record of the results of all DNS queries per zone
•
DHCP
— DHCP Configuration – Contains DHCP server settings and network, DHCP range, and host settings for the
Infoblox DHCP server
— DHCP Leases – Contains a real-time record of DHCP leases
— DHCP Lease History – Contains an historical record of DHCP leases
— DHCP Statistics – Contains the number of static hosts, dynamic hosts, and available hosts per network
Verifying the Deployment
After you deploy a single independent device or HA pair, you can make an HTTPS connection to it, log in, and check
its status.
Single Independent Device
From the Device perspective, check the Status column in the Device panel.
— If the Status icon is green, the device has a network connection and is operating properly.
— If the Status icon is red, there is a problem. To determine what it is, look at the system log file for this device
by clicking device_name -> File -> System Log -> Node 1.
198
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Forcing an HA Failover
Independent HA Pair
1. Make an HTTPS connection to the VIP address of the HA pair, log in, and check the status of both nodes.
2. From the Device perspective, check the Status column in the Device panel.
— If the Status icon is green, both nodes have connectivity with each other and are operating properly.
— If the Status icon is yellow, the two nodes are in the process of forming an HA pair.
— If the Status icon is red, the passive node is offline or there is a problem. To determine what it is, look at the
system log file for each node by clicking host_name -> File -> System Log -> Node 1 or Node 2. You can also
gather information from the Detailed Status viewer. Click host_name -> View -> Detailed Status.
You can also check the status of each node in the Information section in the Device Properties viewer:
1. From the Device perspective, click View -> Properties -> + (for Information) -> + (for Node #1) and + (for Node #2).
2. Check the value in the Status row for each node. The three status values are:
— Active: The node is functioning properly as the active node in the HA pair.
— Passive: The node is functioning properly as the passive node in the HA pair.
— Offline: The active node cannot make a network connection to this node.
Forcing an HA Failover
If you want to change which node in an HA pair is active and which is passive, you can force a failover to occur. You
might want to do this if you need to move or perform maintenance on a currently active node. Within five seconds
after initiating a failover, the previously passive node becomes active and assumes ownership of the VIP address.
To force an HA failover:
1. Log in as a superuser.
2. From Device perspective, click ha_pair -> Edit -> Force Failover.
3. A message appears, prompting you to confirm the failover operation and noting that a forced failover causes a
temporary service disruption.
4. To proceed with the forced failover, click OK.
5. Close the management window, and then log back in.
6. To confirm that the two nodes have reversed their roles—that is, the previously passive node is now active, and
the previously active node is now passive—from the Device perspective, click hostname -> View -> Detailed
Status.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
199
Deploying Independent Devices
Infoblox Tools for Migrating Data
Typically, the next step after cabling a single independent device to a network and configuring its network settings—
or cabling two independent devices to a network and configuring them as an HA pair—is to import data from legacy
DNS, DHCP, and TFTP servers. Infoblox provides several tools to accomplish this:
•
The Infoblox Data Import Wizard is a useful tool that simplifies the importation of DNS, DHCP and IPAM (IP
address management), and TFTP settings and data into an Infoblox device. For large data sets, this option is an
efficient approach. To download the Data Import Wizard, visit www.infoblox.com/support, log in with your
support account, and then click the Data Import Wizard hyperlink in the DNSone section. For guidance in
selecting and using the different options in the wizard, refer to the online Help that accompanies it.
•
You can use prewritten Infoblox Perl API scripts or write your own scripts to ease the execution of large and
repetitive operations such as importing data for large numbers of networks and zones. To download script
packs, log in to www.infoblox.com/support, and navigate to the Downloads section. Each script has a
corresponding HTML Help file. For a more general introduction to using the Infoblox API, see the Infoblox API
Reference Guide, which is available in the Technical Library section of the Infoblox Support site.
•
For smaller DNS data sets, you can use the zone import feature, which allows you to import data on a per-zone
basis (seeImporting Zone Data on page 271).
•
You can also manually enter the settings and data for network identity services. For information, see the
relevant service-specific chapters in this guide.
200
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 9 Deploying a Grid
To deploy a grid, it is important to understand what a grid is, how to create a grid master and add members, and how
to manage the grid. This chapter explains these tasks in the following sections:
•
•
•
•
•
•
Introduction to Grids on page 202
— Grid Communications on page 203
— NAT Groups on page 204
— Automatic Software Version Coordination on page 206
— Grid Bandwidth Considerations on page 208
Creating a Grid Master on page 210
— VRRP Advertisements on page 212
— Port Numbers for Grid Communication on page 213
— Creating an HA Grid Master on page 214
— Creating a Single Grid Master on page 216
Adding Grid Members on page 220
— Adding a Single Member on page 220
— Adding an HA Member on page 221
Configuration Example: Configuring a Grid on page 223
Enabling IPv6 On a Grid Member on page 235
Managing a Grid on page 238
— Changing Grid Properties on page 238
— Setting the MTU for VPN Tunnels on page 238
— Removing a Grid Member on page 239
— Promoting a Master Candidate on page 239
— Replacing a Failed Grid Master on page 239
— Using the Recycle Bin on page 240
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
201
Deploying a Grid
Introduction to Grids
A grid is a group of two or more Infoblox devices that share sections of a common, distributed, built-in database and
which you configure and monitor through a single, secure point of access: the grid master. The basic concept of a grid
and database distribution (or “replication”) is shown in Figure 9.1.
Figure 9.1 Grid and Partitioned Database Replication
The administrator makes a secure
connection to the grid master to
configure and manage all grid
members.
Grid Master
Master Candidate
Database
VPN Tunnel
The grid master replicates the
section of the database that
applies to each member …
… and it replicates the
entire database to the
master candidate.
Administrator
Grid
Single
Member
HA Member
HA Member
Note: In addition to the VPN tunnel securing administrative traffic to the grid
master, all grid communications between the grid master and grid members
pass through encrypted VPN tunnels (not shown).
The grid master can be either an HA master or a single master; that is, an HA (high availability) pair or a single device.
Similarly, a grid member can be either a single member or an HA member. The grid master communicates with every
grid member in a hub-and-spoke configuration. For an HA member, the grid master communicates with the active
node, which in turn communicates with the passive node, as shown in Figure 9.2.
Figure 9.2 Grid Communications to an HA Member
1 The grid master communicates with
Grid Master
the active node of the HA member.
HA Member
VPN Tunnel
VIP
(on HA Port)
LAN Port
2 The active node communicates
with the passive node.
Node 1
Active
VIP
(on HA Port)
VPN Tunnel
LAN Port
Node 2
Passive
By default, grid communications use the UDP transport with a source and destination port of 1194. This port number
is configurable, but for a port change to take effect, the HA master must fail over or the single master must reboot.
202
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Introduction to Grids
After adding a device or HA pair to a grid, you no longer access the Infoblox GUI on that device. Instead, you access
the GUI running on the grid master. Although you can create multiple administrator accounts to manage different
services on various grid members, all administrative access is through the grid master. So even if someone has
administrative privileges to a single grid member, that administrator must access the GUI running on the grid master
to manage that member.
You can access the Infoblox GUI through an HTTPS connection to one of the following IP addresses and ports on the
grid master:
• The VIP address, which links to the HA port on the active node of an HA grid master
• The IP address of the LAN port on a single grid master
• The IP address of the MGMT port (if enabled) of the active node of an HA or single grid master (see Using the
MGMT Port on page 88)
Grid Communications
The grid master synchronizes data among all grid members using bloxSync through encrypted VPN tunnels. The
default source and destination UDP port number for VPN tunnels is 1194. You can continue using the default port
number or change it. For example, if you have multiple grids, you might want each grid to use a different port so that
you can set different firewall rules for each. Whatever port number you choose to use for the VPN tunnels in a grid, all
the tunnels in that grid use that single port number.
Before a device or HA pair forms a tunnel with the master, they first authenticate each other using the
Challenge-Response Authentication Mechanism (CRAM). The source and destination port number for this traffic is
2114. During the CRAM handshake, the master tells the device or HA pair what port number to use when building the
subsequent VPN tunnel.
Figure 9.3 VPN Tunnels within a Grid
If the grid master is a single device, it
communicates with the grid members
from its LAN port.
Single Member
Grid
HA Grid Master
Node 1 (Active)
LAN 10.1.1.16
Node 2 (Passive)
HA Member
VIP 10.1.1.11
(on Active Node)
Encrypted
VPN Tunnels
LAN 10.1.1.18
(on Active Node of
HA Member)
Node 1 (Active)
HA 10.1.1.13
HA 10.1.1.15
Node 2 (Passive)
VIP 10.1.1.22
(on Active Node)
HA 10.1.1.19
HA 10.1.1.21
If you enable grid communications on
the MGMT port of an HA member, the
active node communicates from its
MGMT port to the grid master and the
passive node communicates from its
MGMT port to the VIP on the HA port
on the active node.
LAN 10.1.1.14
(on Passive Node
of Grid Master)
Note: The default source and destination UDP
ports for all VPN tunnels in a grid is 1194.
LAN 10.1.1.20
(on Passive Node
of HA Member)
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
203
Deploying a Grid
Another type of traffic, which flows outside the tunnels, is the VRRP (Virtual Router Redundancy Protocol)
advertisements that pass between the active and passive nodes in an HA pair. The VRRP advertisements act like
heartbeats that convey the status of each node in an HA pair. If the active node fails, the passive node can become
active. The VIP (virtual IP) address for that pair then shifts from the previously active node to the currently active node.
NAT Groups
NAT groups are necessary if the grid master is behind a NAT device and there are members on both sides of that NAT
device. Any members on the same side as the master go into the same NAT group as the master and use their interface
addresses for grid communications with each other. Grid members on the other side of that NAT device do not go in
the same NAT group as the master and use the master's NAT address for grid communications. These other members
outside the NAT device can—but do not always need to be—in a different NAT group. To see when NAT groups become
necessary for grid communications, compare Figure 9.4 below with Figure 9.5 and Figure 9.6 on page 205.
Figure 9.4 NAT without NAT Groups
The grid members use the addresses in bold for
grid communications through their LAN ports.
Member 1
(Grid Master)
Interface 10.1.1.10
NAT
1.1.1.10
Member 2
Interface 1.2.2.20
NAT
––––
Network
Grid
In this case, there is no need for NAT groups. The
master (Member 1) always uses its NAT address
(1.1.1.10) when communicating with the grid members.
Also, if you ever promote Member 3 to master, it only
has to use its NAT address (1.3.3.30) to communicate
with the other grid members. Whichever device is
master, there is no other member behind the same NAT
device with which it needs to use its interface address.
Member 3
(Master Candidate)
Interface 192.168.1.30
NAT
1.3.3.30
Member 4
Interface 10.1.0.40
NAT
1.4.4.40
Member 5
Interface 10.1.0.50
NAT
1.4.4.50
Note: A single or HA member using its MGMT port for grid communications cannot be separated from the grid master
behind a NAT device. For more information, see Using the MGMT Port on page 88.
204
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Introduction to Grids
Figure 9.5 Grid Master in NAT Group
NAT Group 1
Members 2 – 5 use the addresses in black bold for grid communications.
Members 1 and 6 use their interface addresses in underlined blue bold.
Member 1
(Grid Master)
Interface 10.1.1.10
NAT
1.1.1.10
Member 2
Interface 1.2.2.20
NAT
––––
Member 6
Interface 10.1.1.60
NAT
1.1.1.60
Network
Member 3
(Master Candidate)
Interface 192.168.1.30
NAT
1.3.3.30
Grid
The master (Member 1) uses its interface address
(10.1.1.10) for grid communications with Member 6 and
its NAT address (1.1.1.10) when communicating with
the other grid members. Member 6 uses its interface
address (10.1.1.60) when communicating with the
master. If Member 3 (a master candidate) ever became
the grid master, then both Members 1 and 6 would use
their NAT addresses when communicating with it.
Member 4
Interface 10.1.0.40
NAT
1.4.4.40
Member 5
Interface 10.1.0.50
NAT
1.4.4.50
The same use of NAT groups that applies to a grid master also applies to master candidates. If there are no other
members behind the same NAT device as a master candidate, then the master candidate does not need to be in a
NAT group. It always uses its NAT address for grid communications. If another member is behind the same NAT device
as the master candidate, then both the candidate and that member need to be in the same NAT group so that—if the
candidate becomes master—they can use their interface addresses to communicate with each other (see Figure 9.6 ).
Figure 9.6 Grid Master and Master Candidate in NAT Groups
Members 1 – 5 use the addresses in black bold for grid communications.
Members 1 and 6 use their interface addresses in underlined blue bold.
If Member 4 became master, it would use its interface address in double
underlined green bold to communicate with Member 5, and its NAT
address to communicate with all other members.
NAT Group 1
Member 1
(Grid Master)
Interface 10.1.1.10
NAT
1.1.1.10
Member 6
Interface 10.1.1.60
NAT
1.1.1.60
Member 2
Interface 1.2.2.20
NAT
––––
Network
Grid
Members 3 and 4 are master candidates. Because
Member 3 is alone behind a NAT device, it does not
need to be in a NAT group. It always uses its NAT
address for grid communications. However, Member 4 is
behind the same NAT device as Member 5, so they are
put in the same NAT group. If Member 4 ever became
the grid master, it would use its interface address to
communicate with Member 5 and its NAT address to
communicate with all other members.
NIOS 4.1r3
NAT Group 2
Member 3
(Master Candidate)
Interface 192.168.1.30
NAT
1.3.3.30
Member 4
Interface 10.1.0.40
NAT
1.4.4.40
Member 5
Interface 10.1.0.50
NAT
1.4.4.50
Infoblox Administrator Guide (Rev. A)
205
Deploying a Grid
Although some members might not need to be in a NAT group, it is good practice to put all members in NAT groups in
anticipation of adding or rearranging grid members within the network. For example, in Figure 9.4 – Figure 9.6,
Member 4 did not need to be in a NAT group until it became configured as a master candidate in Figure 9.6 . At that
point, because Member 5 is also behind the same NAT device, it became necessary to create NAT Group 2 and add
Members 4 and 5 to it. Similarly, if you add another member behind the NAT device in front of Member 3, then you
must create a new NAT group and add Member 3 and the new member to it. Always using NAT groups can simplify
such changes to the grid and ensure that NAT devices never interrupt grid communications.
To create a NAT group:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties -> NAT Groups.
2. In the NAT Groups section of the Grid editor, click Add.
3. In the NAT Group dialog box, enter a name in the Group Name field and a useful comment in the Comment field,
and then click OK.
4. Click the Save icon.
To add members to the NAT group:
1. In the Grid perspective, click + (for id_grid) -> + (for Members) -> member -> Edit -> Member Properties -> NAT.
2. In the NAT section of the Grid Member editor, enter the following:
— Enable NAT compatibility: (select)
— Group: From the drop-down list, select the NAT group you previously created.
— NAT (V)IP Address: For a single grid master or member, enter the address configured on the NAT device that
maps to the interface address of the LAN port. A single master or member that serves DNS uses this NAT
address for grid communications and—if it serves DNS—for its NS records.
For an HA grid master or member, enter the address configured on the NAT device that maps to its VIP
address. An HA master uses its VIP NAT address when communicating with grid members. An HA member
that serves DNS uses its VIP NAT address for its NS records. It uses its LAN port NAT address for grid
communications.
— Node 1 (if HA)
•
NAT IP Address: Enter the address configured on the NAT device that maps to the interface address
of the LAN port on Node 1. When Node 1 of an HA member is active, it uses its NAT address for grid
communications.
— Node 2 (if HA)
•
NAT IP Address: Enter the address configured on the NAT device that maps to the interface address
of the LAN port on Node 2. When Node 2 of an HA member is active, it uses its NAT address for grid
communications.
3. Click the Save icon.
Automatic Software Version Coordination
When you add a device or HA pair to a grid as a new member, it is important that it is running the same version of
software as the other members in the grid. Infoblox provides two methods for coordinating the software version:
•
Manual Upgrade and Downgrade: Before adding a device or HA pair to a grid, you can manually upgrade or
downgrade the software on the device or HA pair to the version used by the rest of the grid.
•
Automatic Upgrade and Downgrade: The grid master automatically compares the software version of each
device attempting to enter a grid with that in use by the rest of grid. If the versions do not match, the grid master
downloads the correct version to the new device or HA pair.
Note: The grid master checks the software version every time a device or HA pair joins the grid. The software
version check occurs during the initial join operation and when a member goes offline and then rejoins
the grid.
206
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Introduction to Grids
Figure 9.7 Automatic Upgrade of a Device Joining a Grid
Grid
(NIOS 4.0r1)
Grid Master
The grid master synchronizes
configuration and data changes with
grid members through VPN tunnels
Single Grid Member
HA Grid Member
NIOS 4.0r1
Software
Download
When a device with a different version
of NIOS attempts to join the grid, the
grid master sends the software that the
rest of the grid is using to the device
through a tunnel.
The device loads the NIOS software that it
receives from the grid master, reboots, and
reestablishes a tunnel with the grid master.
Then—assuming everything else is in
order—the device successfully joins the grid.
Device Joining the Grid
(DNSone 3.2r10 -> NIOS 4.0r1)
When a single device attempts to join the grid for the first time, the following series of events takes place:
1. The device establishes an encrypted VPN tunnel with the grid master.
2. The master detects that the software version on the device is different from that in the rest of the grid. (For
example, the device is running DNSone 3.2r10 software but the rest of the grid is running NIOS 4.0r1 software.)
3. The grid master sends the NIOS 4.0r1 software through the tunnel to the device, which loads it.
4. After the upgrade is complete, the NIOS application automatically restarts.
5. After the device reboots, it again contacts the grid master and step 1 is repeated. Because the software versions
now match, the device can complete its attempt to join the grid.
When an HA pair attempts to join the grid for the first time, the following series of events takes place:
1. The active node of the HA pair establishes an encrypted VPN tunnel with the grid master.
2. The master detects that the software version on the node is different from that in the rest of the grid. (For
example, the active node is running DNSone 3.2r10 software but the rest of the grid is running NIOS 4.0r1
software.)
3. The grid master sends the NIOS 4.0r1 software through the tunnel to the active node, which loads it.
4. After the upgrade is complete, the NIOS application on the active node automatically restarts. This causes an HA
failover.
5. The new active node (which was previously the passive node) attempts to join the grid, repeating steps 1 – 4.
6. When the NIOS application on the currently active node restarts, there is another failover, and the currently
passive node becomes active again.
7. The active node again contacts the grid master and step 1 is repeated. Because the software versions now match,
it can complete its attempt to join the grid.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
207
Deploying a Grid
Grid Bandwidth Considerations
Infoblox grid technology relies upon database replication for its core functionality. When designing a grid, it is
important to consider the amount of traffic generated by this replication activity and the overall number of grid
members. Other communication between grid members occurs as well, such as log retrieval and monitoring
functions. All of this traffic is securely communicated between the grid master and grid members through encrypted
VPN tunnels.
The largest component of the traffic through the tunnels is database replication traffic. There are three types to
consider:
1. Complete database replication to a master candidate — This type of replication traffic occurs when a master
candidate joins or rejoins a grid. The grid master sends the complete database to a master candidate so that it
has all the data it needs if it ever becomes promoted from member to master.
2. Partial database replication — This type of replication traffic occurs when a device or HA pair joins or rejoins the
grid as a regular member (that is, a member that is not configured as a master candidate). The grid master sends
it the section of the database that mainly applies just to that member.
3. Ongoing database updates — This type of replication traffic occurs as changes are made to the grid configuration
and data. The grid master sends all ongoing database updates to master candidates and individualized
member-specific updates to regular members.
If there are no or very few DNS dynamic updates happening, and no or very few DHCP lease offers and renewals
issued, then this type of replication traffic is minimal.
If there are many DDNS (dynamic DNS) updates happening (many per second) and/or many DHCP lease offers
and renewals (many per second), then the replication traffic is the largest component of the VPN traffic among
grid members.
Note: A grid master replicates data to single members and to the active node of HA members. The active node then
replicates the data to the passive node in the HA pair.
At a minimum, there needs to be 256 Kbps (kilobits per second) bandwidth between the grid master and each
member, with a maximum round-trip delay of 200 milliseconds. For ongoing database updates, the formula for
bandwidth needed is 3 Kbps for every DDNS update, and 3 Kbps for every DHCP lease offer/renew, plus 4 Kbps as a
baseline amount for heartbeat and other maintenance traffic for each member. Measure the peak DNS and DHCP
traffic you see in your network to determine the bandwidth needed between the grid master and its members for this
activity.
For example, you might decide to place your grid members in the locations shown in Figure 9.6 on page 205.
208
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Introduction to Grids
Figure 9.8 Grid Deployment
Network Diagram
Large Branch
West
East
Site
Data Center
West
East
Site
West Site
West Site
East
Site
Data Center
East
Large Branch
Central
East Site
In this example, the grid master is optimally placed in the Data Center West. There are a total of seven members: the
HA grid master, three HA members, and three single members. If all the members are master candidates, the grid
master replicates all changes to the other six members. Assuming that the master receives 20 dynamic updates per
minute and 40 DHCP lease renews per minute, the calculation for grid bandwidth is:
20 DDNS updates/minute/60 secs = 0.333 DDNS updates/sec * 3 Kbps = 1 Kbps *6 members
= 6 Kbps
40 DHCP leases/minute/60 secs = 0.666 DHCP leases/sec * 3 Kbps = 2 Kbps * 6 members
= 12 Kbps
4 Kbps of grid maintenance traffic * 6 members
= 24 Kbps
Total
42 Kbps
Bandwidth requirements largely determine the maximum size of the grid you can deploy. Based on the various factors
discussed above, you can determine the amount of bandwidth your grid needs. If your calculations exceed the
available bandwidth, then you might need to modify your deployment strategy, perhaps by splitting one large grid
into two or more smaller ones.
Note: This calculation does not take into account existing traffic other than DNS and DHCP services, so factor and
adjust accordingly.
For international networks, because of bandwidth and delay requirements, a geographical grouping of grid members
might be the best approach. For example, if you have a global presence, it may make the most sense to have a North
American grid, a South American grid, a European grid, and an Asia/Pacific grid.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
209
Deploying a Grid
Creating a Grid Master
To create a grid, you first create a grid master and then add members. Although the grid master can be a single device
(a “single master”), a more resilient design is to use an HA pair (an “HA master”) to provide hardware redundancy.
The basic procedure for forming two devices into an HA master is shown in Figure 9.9.
Figure 9.9 Initially Configuring a Pair of Devices as a Grid Master
1 Connect your management
system to a switch and set its
IP address to 192.168.1.3.
Management
System
To Network
Node 2
Node 1
Switch
2 Connect Node 1 to the switch, log in to its
default IP address (192.168.1.2), check
that a Keystone license is installed, and
configure the following:
•
•
•
•
•
•
•
•
3
VIP address, netmask, gateway
Hostname
HA and LAN addresses of Node 1
HA and LAN addresses of Node 2
VRID (virtual router ID)
NTP settings
Grid name
Shared secret
After you configure Node 1, it listens for three
seconds for VRRP advertisements containing
its VRID number. When it does not receive
any, it assumes the active role in the HA pair
and starts sending advertisements.
Note: For more information about VRRP advertisements,
see VRRP Advertisements on page 212.
4
Connect Node 2 to the switch, log in to its
default IP address (192.168.1.2), check
that a Keystone license is installed, and
configure the following:
•
•
•
•
•
VIP address (for Node 1)
LAN address, netmask, gateway
Hostname
Grid name
Shared secret
Note: Because you do not set the VRID for
Node 2, it cannot listen for VRRP
advertisements yet. It learns its VRID
after it joins the grid and downloads the
database from Node 1. Then, when
Node 2 receives an advertisement
containing its VRID from Node 1, it
assumes the passive role in the HA pair.
5
After you configure Node 2, it contacts
the VIP address on Node 1 and initiates
a key exchange using the shared secret.
The nodes then construct an encrypted
VPN tunnel to secure grid
communications.
After the two nodes form an HA pair, Node 2 initiates a key exchange and creates an encrypted VPN tunnel with
Node 1. The two nodes communicate between the VIP interface linked to the HA port on Node 1 and the LAN port on
Node 2. The initialization of VPN communications between the two nodes is shown in Figure 9.10 on page 211.
210
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Creating a Grid Master
Figure 9.10 Establishing a VPN Tunnel for Grid Communications
Node 1
Node 2
Switch
VIP
LAN
Source and Destination
Port Numbers:
Key
Exchange
2114 (nonconfigurable)
The two nodes authenticate each other and
perform a VPN key exchange.
VPN
Tunnel
1194 – default VPN port
number (configurable)
The passive node establishes an encrypted
VPN tunnel with the active node.
Tunnel Established
After the nodes establish a VPN tunnel between themselves, Node 1 sends Node 2 its entire database (its
configuration settings and service data). Because the configuration contains the VRID (virtual router ID) for the HA
pair, Node 2 starts listening for VRRP advertisements containing that VRID number. Because Node 1 is already
sending such advertisements, Node 2 receives one and assumes the passive role in the HA pair.
After the initial transmission of its database, Node 1 continues to send Node 2 real-time database updates using an
Infoblox proprietary mechanism called bloxSYNC through the VPN tunnel.
Node 1 maintains the synchronization of the database throughout the grid—which, at this point, has no other
members—sends VRRP advertisements indicating its physical and network health, and—if configured to do so—
provides network services. Node 2 maintains a state of readiness to assume mastership in the event of a failover. You
can see the flow of HA- and grid-related traffic from ports on the active node to ports on the passive node in
Figure 9.11. This illustration also shows the ports that you can use for management traffic and network service.
Figure 9.11 Traffic and Ports that an HA Grid Master Uses
To Network
HA Master
VIP is a logical
interface linking
to the HA port on
the active node
of the HA pair.
Active
Passive
Node 1
Switch
Note: If you enable the
MGMT port, you can only
make an HTTPS connection
to the IP address of the active
node. If you try to connect to
the IP address of the passive
node, the device redirects
your browser to the IP
address of the active node.
Node 2
VIP
bloxSYNC inside
VPN Tunnel
HA
LAN
NIOS 4.1r3
HA
VRRP
Advertisements
LAN
SSHv2 / CLI
SSHv2 / CLI
HTTPS / GUI
Management
System
SSHv2, however, behaves
differently from HTTPS. If
you enable the MGMT port
and define its network
settings for both nodes in the
HA pair, you can make an
SSHv2 connection to the IP
addresses of the LAN and
MGMT ports on both the
active and passive nodes.
Infoblox Administrator Guide (Rev. A)
211
Deploying a Grid
From the management system, you can manage the active node of the HA master by making an HTTPS connection to
the VIP interface and using the GUI, and by making an SSHv2 connection to the LAN port (and MGMT port, if enabled)
and using the CLI. If you enable the MGMT port on an HA pair, you can make an HTTPS connection through the MGMT
port on the active node, and you can make an SSHv2 connection through the LAN or MGMT port on the active and
passive nodes.
Note: For information about enabling and using the MGMT port, the Infoblox GUI, and SSH, see Using the MGMT Port
on page 88, Accessing the Infoblox GUI on page 34, and Enabling Remote Console Access on page 80.
VRRP Advertisements
VRRP advertisements are periodic announcements of the availability of the HA node linked to the VIP. The active node
in an HA pair sends advertisements as multicast datagrams every second. It sends them from its HA port using the
source IP address of the HA port (not from the VIP address) and the source MAC address 00:00:5e:00:01:vrrp_id . The
last two hexadecimal numbers in the source MAC address indicate the VRID (virtual router ID) number for this HA pair.
For example, if the VRID number is 143, then the source MAC address is 00:00:5e:00:01:8f (8f in hexadecimal
notation = 143 in decimal notation).
The destination MAC and IP addresses for all VRRP advertisements are 01:00:5e:00:00:12 and 224.0.0.18. Because
a VRRP advertisement is a multicast datagram that can only be sent within the immediate logical broadcast domain,
the nodes in an HA pair must be in the same subnet together.
Only a device configured to listen for VRRP advertisements with the same VRID number processes the datagrams,
while all other devices ignore them. The passive node in an Infoblox HA pair listens for these on its HA port and the
active node listens on its LAN port. If the passive node does not receive three consecutive advertisements or if it
receives an advertisement with the priority set to 0 (which occurs when you manually perform a forced failover), it
changes to the active state and assumes ownership of the VIP address and virtual MAC address.
If both nodes go offline, the one that comes online first becomes the active node. If they both come online
simultaneously, or if they enter a dual-active state—that is, a condition arises in which both devices assume an active
role and send VRRP advertisements, possibly because of network issues—then the nodes apply the following rules
to resolve their roles:
•
The device with the numerically higher VRRP priority becomes the active node.
In NIOS, a node receives the priority value 30 when it first becomes active. If that node sends an advertisement
from its HA port but does not receive it on its own LAN port, it lowers its priority value by one to 29. If it does not
receive the next advertisement, it lowers the priority value to 28. This can continue until the priority reaches 10,
at which point the decrementation process stops. (Because the active node in an HA pair can function without
its LAN port, the decrementation process stops before the priority value reaches zero, which would cause a
device failover.) If the node starts receiving its own advertisements again, it starts increasing its priority value
by one for each received advertisement, stopping the incrementation process when it returns to 30.
•
If both nodes have the same priority, then the device whose HA port has a numerically higher IP address
becomes the active node. For example, if the IP address of the HA port on Node 1 is 10.1.1.80 and the IP
address of the HA port on Node 2 is 10.1.1.20, then Node 1 becomes the active node.
The basic decision tree that an Infoblox device configured as a node in an HA node uses to determine if it is the active
or passive node is shown in Figure 9.12 on page 213.
212
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Creating a Grid Master
Figure 9.12 Using VRRP Advertisements to Determine the Active Node in an HA Pair
Does an
advertisement
with its VRID
arrive within
3 secs?
A VRRP-enabled device
comes online …
Enter
passive
state
Yes
No
Become the active
node and start sending
VRRP advertisements.
If another VRRP-enabled device
sends VRRP advertisements
with the same VRID …
Enter
passive
state
Yes
Does
other device
have higher
priority?
Same
Does
other device
have higher IP
address?
No
No
Remain
active
Remain
active
Yes
Enter
passive
state
Port Numbers for Grid Communication
If connectivity between grid members must pass through a firewall, the firewall policies must allow the initial key
exchange and subsequent VPN traffic to pass. The key exchange uses UDP with a source and destination port of 2114.
VPN traffic uses UDP with a default source and destination port of 1194.
The VPN port number is configurable. From the Grid perspective on the grid master, click id_grid -> Edit -> Grid
Properties -> Grid Properties, type a new port number in the VPN Port Number field, and then click the Save icon. After
changing the port number, you must reboot the single master or the active node of an HA master (which forces an HA
failover). From the Grid perspective, click + (for id_grid) -> + (for Members) -> master -> Edit -> Reboot.
A member and master first perform a handshake to authenticate each other and exchange encryption keys. Then they
build an encrypted VPN tunnel between themselves. The member typically initiates both of these connections. The
master only initiates a key exchange if you manually promote a member to the role of master (see Promoting a Master
Candidate on page 239). Figure 9.10 on page 211 shows the typical connection exchange and default port usage not
only between the two nodes forming an HA pair but also between a member and master when the member joins a
grid.
The member and master key exchange occurs when a device joins a grid, during master promotion, and when a
member reconnects to a grid after becoming disconnected. At all other times, grid-related communications occur
through encrypted VPN tunnels.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
213
Deploying a Grid
Creating an HA Grid Master
To create a grid, you first create a grid master and then add members. Although you can define a single device as a
grid master, using an HA pair provides hardware redundancy for this vital component of a grid. The following
procedure explains how to put two Infoblox devices on the network and use the Infoblox NIOS Startup Wizard to
configure them as Nodes 1 and 2 to form an HA grid master.
To create an HA grid master using the Infoblox NIOS Startup Wizard:
Configuring the Connecting Switch
To ensure that VRRP (Virtual Router Redundancy Protocol) works properly, configure the following settings on the
network switch to which you cable the two nodes:
•
Portfast: enable
•
Trunking: disable
•
Port list: disable
•
Port channeling: disable
Note: By default, an Infoblox device automatically negotiates the optimal connection speed and transmission type
(full or half duplex) on the physical links between its LAN (or LAN1), HA, and MGMT ports and the ethernet
ports on the connecting switch. If the two devices fail to auto-negotiate the optimal settings, see Modifying
Ethernet Port Settings on page 87 for steps you can take to resolve the problem.
Putting Both Devices on the Network
1. Connect the power cable from each Infoblox device to a power source and turn on the power. If possible, connect
the devices to separate power circuits. If one power circuit fails, the other might still be operative.
2. Connect ethernet cables from the LAN (or LAN1) port and the HA port on each device to a switch on the network.
Note: The ethernet ports on the Infoblox-550, -1050, -1550, and -1552 appliances are autosensing, so you can
use either a straight-through or cross-over ethernet cable for these connections. For the Infoblox-500,
-1000, and -1200 appliances, use straight-through ethernet cables.
3. Use the LCD on one device or make a console connection to it, and configure the network settings of its LAN or
LAN1 port so that it is on the local subnet and you can reach it on the network.
Note: For details about using the LCD and console, see Using the LCD Panel on page 533 and Using the Serial
Console on page 533.
4. Similarly, configure the LAN or LAN1 port on the other device so that it is in the same subnet as the first device.
5. Connect your management system to the network so that it can reach the IP addresses of the LAN or LAN1 ports.
HA Master – Node 1
1. On your management system, open a browser window, and connect to https://ip_addr, where ip_addr is the
address of the LAN or LAN1 port on Node 1.
2. Click LAUNCH GRID MANAGER.
3. Log in using the default user name and password admin and infoblox. For detailed information about logging in
to the GUI, see Accessing the Infoblox GUI on page 34.
The Infoblox NIOS Startup Wizard appears. The first screen provides basic information about the wizard, and the
second screen displays license agreement information.
214
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Creating a Grid Master
4. Beginning on the third screen, enter the following, where
— string1 is a text string that the two devices use to authenticate each other when establishing a VPN tunnel
for ensuing bloxSYNC traffic. (The default grid name is Infoblox.)
— string2 is a text string that both devices use as a shared secret to authenticate each other when
establishing a VPN tunnel for ensuing bloxSYNC traffic. (The default shared secret is test.)
— vip_addr and netmask are the VIP (virtual IP) address and its netmask.
— ip_addr1 is the IP address of the gateway for the subnet on which the ports are set.
— hostname is a valid domain name for the device.
— ip_addr2-5 are the IP addresses of the LAN and HA ports for Nodes 1 and 2.
— number is the VRID (virtual router ID). This must be a unique VRID number—from 1 to 255—for this subnet.
— string3 is a single hexadecimal string (no spaces) for a password that is at least four characters long.
— ip_addr6 is the IP address of an NTP (Network Time Protocol) server. You can enter IP addresses for multiple
NTP servers.
Wizard Screen
Enter or Select
Deployment Type
Grid Master or Member
License Validation
Check that a Keystone license is installed.
Grid Master or Member
Grid Master
Single or HA Grid Master
HA Grid Master; Node 1
HA Pair Settings
HA Pair Name: string1
Shared Secret: string2
HA Pair Network Settings
VIP Address: vip_addr
Netmask: netmask
Gateway: ip_addr1
Host Name: hostname
Node 1: LAN/LAN1 Address: ip_addr2
HA Address: ip_addr3
Node 2: LAN/LAN1 Address: ip_addr4
HA Address: ip_addr5
Virtual Router ID: number
Admin Account Password
Time Settings
Change Admin Password: (select), string3
Enable NTP: (select)
NTP Server List: ip_addr6 (click Add)
Time zone: (choose the time zone for the location of the device)
Note: The startup wizard provides options such as not changing the default password and manually entering the
time and date. However, changing the password and using an NTP server improve security and accuracy
(respectively), and so these choices are presented here.
The last screen of the startup wizard states that the changed time settings require the application to restart.
When you click Finish, the application restarts.
5. Close the management window.
The configuration for Node 1 is complete.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
215
Deploying a Grid
HA Master – Node 2
1. On your management system, open a new browser window, and connect to https://ip_addr, where ip_addr is the
address of the LAN or LAN1 port on Node 2.
2. Log in using the default user name and password admin and infoblox.
The Infoblox NIOS Startup Wizard appears.
3. Beginning on the third wizard screen, enter the following to set up Node 2 (the variables are explained in the
previous section for Node 1):
Wizard Screen
Enter or Select
Deployment Type
Grid Master or Member
License Validation
Check that a Keystone license is installed.
Grid Master or Member
Grid Master
Single or HA Grid Master
HA Grid Master; Node 2
Node 2 Network Settings
IP Address: ip_addr4
Netmask: netmask
Gateway: ip_addr1
Grid Properties
Master’s IP Address: vip_addr
Grid Name: string1
Shared Secret: string2
4. After completing the wizard, close the management window.
The setup of the HA master is complete. From now on, when you make an HTTPS connection to the HA pair, use
the VIP address.
Creating a Single Grid Master
Although using an HA master is ideal because of the hardware redundancy it provides, you can also use a single
device as the grid master.
Setting up a device as a single grid master is very easy. If the device has the DNSone package with the Keystone
upgrade, it is already a grid master. You simply need to define the network settings for its LAN or LAN1 port. The
various procedures for defining the network settings for the LAN or LAN1 port of a single independent device apply
here as well; that is, you can use any of the following procedures to define the network settings for the LAN or LAN1
port of the device that you want to make a single grid master:
•
LCD – See Method 1 – Using the LCD on page 170.
•
Console port – Method 2 – Using the CLI on page 170.
You can also use the Infoblox NIOS Startup Wizard and the Infoblox Grid Manager to create a single grid master. In
addition to providing a simple method accompanied by helpful information, the startup wizard allows you to change
the admin password and configure time settings for the device. Through the GUI, you can configure other settings
(although the configuration presented here covers just the basics):
•
Infoblox NIOS Startup Wizard – See Using the Startup Wizard on page 217.
•
Infoblox Grid Manager – See Using the Infoblox GUI on page 218.
216
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Creating a Grid Master
Using the Startup Wizard
To create a single grid master using the Infoblox NIOS Startup Wizard:
1. Connect the power cable from the Infoblox device to a power source and turn on the power.
2. Connect an ethernet cable from the LAN (or LAN1) port on the device to a switch on the network.
Note: The ethernet ports on the Infoblox-550, -1050, -1550, and -1552 appliances are autosensing, so you can
use either a straight-through or cross-over ethernet cable for this connection. For the Infoblox-500, -1000,
and -1200 appliances, use a straight-through ethernet cable.
3. If you have not changed the default IP address (192.168.1.2/24) of the LAN or LAN1 port through the LCD or CLI—
and the subnet to which you connect the device does not happen to be 192.168.1.0/24—put your management
system in the 192.168.1.0/24 subnet and connect an ethernet cable between your management system and the
Infoblox device.
4. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port. (To reach the
default IP address, enter: https://192.168.1.2 )
Several certificate warnings appear during the login process. This is normal because the preloaded certificate is
self-signed (and, therefore, is not in the trusted certificate stores in your browser, Java application, and Java
Web Start application) and has the hostname www.infoblox.com, which does not match the destination IP
address you entered in step 3. To stop the warning messages from occurring each time you log in to the GUI, you
can generate a new self-signed certificate or import a third-party certificate with a common name that matches
the FQDN (fully qualified domain name) of the device. This is a very simple process. For information about
certificates, see Managing Certificates on page 41.
5. Click LAUNCH GRID MANAGER.
6. Log in to the Infoblox device. The default login name and password are admin and infoblox. For detailed
information about logging in to the GUI, see Accessing the Infoblox GUI on page 34.
The Infoblox NIOS Startup Wizard appears. The first screen provides basic information about the wizard, and the
second screen displays license agreement information.
7. Beginning on the third screen, enter the following, where
— string1 is a text string that the grid master and devices joining the grid use to authenticate each other when
establishing a VPN tunnel for ensuing bloxSYNC traffic. (The default grid name is Infoblox.)
— string2 is a text string that the grid master and devices joining the grid use as a shared secret to
authenticate each other when establishing a VPN tunnel for ensuing bloxSYNC traffic. (The default shared
secret is test.)
— ip_addr1 and netmask are the IP address and netmask for the LAN or LAN1 port.
— ip_addr2 is the IP address of the gateway for the subnet on which the LAN or LAN1 port is set.
— hostname is a valid domain name for the device.
— string3 is a single alphanumeric string (no spaces) for a password that is at least four characters long.
— ip_addr3 is the IP address of an NTP (Network Time Protocol) server.
Wizard Screen
Enter or Select
Deployment Type
Grid Master or Member
License Validation
Check that a Keystone license is installed.
Grid Master or Member
Grid Master
Single or HA Grid Master
Single Grid Master
Grid Settings
Grid Name: string1
Shared Secret: string2
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
217
Deploying a Grid
Wizard Screen
Enter or Select
Network Settings
IP Address: ip_addr1
Netmask: netmask
Gateway: ip_addr2
Host name: hostname
Admin Account Password
Change Admin Password: (select), string3
Time Settings
Enable NTP: (select)
NTP Server List: ip_addr3 (click Add)
Time zone: (choose the time zone for the location of the device)
Note: The startup wizard provides options such as not changing the default password and manually entering the
time and date. However, changing the password and using an NTP server improve security and accuracy
(respectively), and so these choices are presented above.
Record and retain this information in a safe place. If you forget the shared secret, you need to contact
Infoblox Technical Support for help. When you add a device to the grid, you must configure it with the same
grid name, shared secret, and VPN port number that you configure on the grid master.
The last screen of the startup wizard states that the changed settings require the device to restart. When you
click Finish, the device restarts.
The setup of the single master is complete. From now on, when you make an HTTPS connection to the device, use its
new IP address.
Using the Infoblox GUI
To create a single grid master using the Infoblox Grid Manager GUI:
1. Connect the power cable from an Infoblox device to a power source and turn on the power.
2. Connect ethernet cables from the LAN (or LAN1) port and the HA port on the device to a switch on the network.
Note: The ethernet ports on the Infoblox-550, -1050, -1550, and -1552 appliances are autosensing, so you can
use either a straight-through or cross-over ethernet cable for this connection. For the Infoblox-500, -1000,
and -1200 appliances, use a straight-through ethernet cable.
3. If you have not changed the default IP address (192.168.1.2/24) of the LAN or LAN1 port through the LCD or CLI—
and the subnet to which you connect the device does not happen to be 192.168.1.0/24—put your management
system in the 192.168.1.0/24 subnet and connect an ethernet cable between your management system and the
Infoblox device.
4. Open a web browser and make an HTTPS connection to the IP address of the LAN or LAN1 port. (To reach the
default IP address, enter: https://192.168.1.2 )
Several certificate warnings appear during the login process. This is normal because the preloaded certificate is
self-signed (and, therefore, is not in the trusted certificate stores in your browser, Java application, and Java
Web Start application) and has the hostname www.infoblox.com, which does not match the destination IP
address you entered in step 3. To stop the warning messages from occurring each time you log in to the GUI, you
can generate a new self-signed certificate or import a third-party certificate with a common name that matches
the FQDN (fully qualified domain name) of the device. This is a very simple process. For information about
certificates, see Managing Certificates on page 41.
5. Click LAUNCH GRID MANAGER.
218
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Creating a Grid Master
6. Log in to the Infoblox device. The default login name and password are admin and infoblox. For detailed
information about logging in to the GUI, see Accessing the Infoblox GUI on page 34.
The Infoblox NIOS Startup Wizard appears.
7. To bypass the wizard and access the Infoblox Grid Manager GUI, click Cancel or the Close button (⌧).
8. From the Grid perspective, click + (for Infoblox) -> + (for Members) -> infoblox.localdomain -> Edit -> Member
Properties.
9. In the Grid Member editor, click Node Properties, and then enter the following:
— Host Name: Type the FQDN (fully qualified domain name) of the device.
— (V)IP Address: Type the IP address of the LAN or LAN1 port.
— Subnet Mask: Choose the netmask for the subnet to which the LAN or LAN1 port connects.
— Gateway: Type the IP address of the default gateway of the subnet to which the LAN or LAN1 port connects.
— Comment: Type a comment that provides some useful information about the device, such as its location.
10. Click Save, and then close the management window.
11. Initiate a new management session, and log in to the device using its new IP address.
12. From the Grid perspective, click + (for Infoblox) -> Edit -> Grid Properties.
13. In the Grid editor, click Grid Properties, and then enter the following information:
— Name: Type the name of the grid. The default name is Infoblox.
— Shared Secret: Type a shared secret that all devices must use to authenticate themselves when joining the
grid. The default shared secret is test.
— Retype Shared Secret: Type the shared secret again to confirm its accuracy.
— VPN Port Number: Type the port number that the grid members use when communicating with the grid
master through encrypted VPN tunnels. The default port number is 1194.
After changing the port number, you must reboot the single master or the active node of an HA master
(which forces an HA failover). From the Grid perspective, click + (for id_grid) -> + (for Members) -> master ->
Edit -> Reboot. (For more information, see Port Numbers for Grid Communication on page 213.)
— Enable Recycle Bin: Select the check box to enable the recycle bin feature. This option is supported only for
superusers. The recycle bin stores the deleted items when the user deletes grid, DNS, or DHCP
configuration items in the GUI for the grid member. Enabling the recycle bin allows you to undo the
deletions and to restore the items on the device at a later time. If you do not enable the recycle bin feature,
deleted items from the GUI are permanently removed from the database.
Note: Record and retain this information in a safe place. If you forget the shared secret, you need to contact
Infoblox Technical Support for help. When you add a device to the grid, you must configure it with the same
grid name, shared secret, and VPN port number that you configure on the grid master.
The setup of the single master is complete. From now on, when you make an HTTPS connection to the device,
use its new IP address.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
219
Deploying a Grid
Adding Grid Members
You can add single devices and HA pairs to a grid, forming single members and HA members respectively. You can
also define an HA member on the grid master and then add two individual devices to the grid as Node 1 and Node 2
to complete the HA member you defined on the master.
Note: To learn about the maximum grid size limit, contact Infoblox Technical Support or your sales representative.
The process for adding either a single device or HA pair to a grid involves two steps:
1. Configuring the member on the grid master. In addition to defining the network and device settings for a member,
you can also configure service settings before you join the device or HA pair to the grid.
2. Defining the VIP or IP address of the grid master, the grid name, and the shared secret on the single device or HA
pair.
3. Joining the device or HA pair to the grid. If a device or HA pair join the grid because of MTU (maximum
transmission unit) limitations on its network link, you can reduce the MTU that the master uses when
communicating with it. See Setting the MTU for VPN Tunnels on page 238.
Note: New members inherit all settings that you create at the grid level unless you override them at the member
level.
If you want to preserve some or all of the configuration and data on a device or HA pair after you join it to a grid, you
can use the merge function. For information about merging data from a device or HA pair to a grid, see Merging Data
on page 156.
Adding a Single Member
The basic steps necessary to add a single member are as follows:
1. Define the network settings of the LAN port of the single device on the grid master.
2. Define the VIP or IP address of the grid master, the grid name, and the shared secret on the single device.
3. Initiate the join grid operation.
In addition, you can configure on the grid master the service settings such as DNS zones and records, DHCP networks
and address ranges, and so on for a member before or after you join the device to the grid. The basic steps for adding
a single member are presented below.
Configuring the Single Member on the Grid Master
1. Log in to the grid master as a superuser.
2. From the Grid perspective, click id_grid -> Edit -> Add Grid Member.
3. In the Add Grid Member editor, click Node Properties, and then enter the following:
— Host Name: Type the FQDN (fully qualified domain name) of the device.
— (V)IP Address: Type the IP address of the LAN or LAN1 port.
— Subnet Mask: Choose the netmask for the subnet to which the LAN or LAN1 port connects.
— Gateway: Type the IP address of the default gateway of the subnet to which the LAN or LAN1 port connects.
— Comment: Type a comment that provides some useful information about the device, such as its location.
4. Click the Save icon to add the single member to the grid.
220
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Grid Members
Joining a Device to a Grid
1. Log in to the device that you want to add to the grid. The device must be online and able to reach the grid master.
2. From the Grid perspective, click + (for id_grid) -> + (for Members) -> hostname -> Edit -> Join Grid.
3. In the Join Grid dialog box, enter the following:
— Virtual IP of Grid Master: Type the VIP address of the HA grid master or the LAN address of the single grid
master for the grid to which you want to add the device.
— Grid Name: Type the name of the grid.
— Grid Shared Secret: Type the shared secret of the grid.
— Retype Grid Shared Secret: To ensure accuracy, retype the shared secret.
— Use MGMT port to join grid: If you have already enabled the MGMT port (see Grid Communications on page
92), this option becomes available. Select it to connect to the grid through the MGMT port.
4. Click OK to begin the join operation.
5. To confirm that the device has successfully joined the grid, log in to the grid master and from the Grid perspective,
click + (for id_grid) -> + (for Members), and check the icon in the Status column (green = the device has joined
the grid and is functioning properly; yellow = the device is in the process of joining the grid; red = the device has
not joined the grid). Also, select the member, and then click View -> Detailed Status.
Note: You can also use the set network command to join a device to a grid.
Adding an HA Member
The basic steps necessary to add an HA member are as follows:
1. Define the network settings of the HA pair on the grid master.
2. Define the VIP or IP address of the grid master, the grid name, and the shared secret on the HA pair.
3. Initiate the join grid operation.
In addition, on the grid master you can configure the service settings such as DNS zones and records, DHCP networks
and address ranges, and so on for a member before or after you join the HA pair to the grid. The basic steps for adding
an HA member are presented below.
Note: The procedure for adding an HA pair to a grid when it uses the MGMT port of the active node for grid
communications differs slightly from that described below. See Grid Communications on page 92.
Configuring the HA Member on the Grid Master
1. Log in to the grid master as a superuser.
2. From the Grid perspective, click id_grid -> Edit -> Add Grid Member.
3. In the Add Grid Member editor, click Node Properties, and then enter the following:
— Host Name: Type the FQDN (fully qualified domain name) for the HA member.
— (V)IP Address: Type the VIP (virtual IP) address for the HA member.
— Subnet Mask: Choose the netmask for the subnet to which the VIP address connects.
— Gateway: Type the IP address of the default gateway of the subnet to which the VIP address connects.
— Comment: Type a comment that provides some useful information about the HA member, such as its
location.
— HA Pair: (select)
— Virtual Router ID: Enter a unique VRID number—from 1 to 255—for the local subnet.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
221
Deploying a Grid
— Master Candidate: Select the check box if you want to be able to promote the HA member to that of grid
master (see Promoting a Master Candidate on page 239). Clear the check box if you want the HA member to
be a regular member (that is, a member that is not and cannot be a grid master). If you want the HA member
to use the MGMT port of its active node for grid communications, it cannot be a master or master candidate.
Note: The VIP address and the IP addresses for all the following ports must be in the same subnet.
— Node #1:
•
LAN Address: Enter an IP address for the LAN (or LAN1) port of Node 1.
•
HA Address: Enter an IP address for the HA port of Node 1.
— Node #2:
•
LAN Address: Enter an IP address for the LAN (or LAN1) port of Node 2.
•
HA Address: Enter an IP address for the HA port of Node 2.
4. Click the Save icon to add the HA member to the grid.
Joining an HA Pair to a Grid
1. Log in to the HA pair that you want to add to the grid. The HA pair must be online and able to reach the grid master.
2. From the Grid perspective, click + (for id_grid) -> + (for Members) -> hostname -> Edit -> Join Grid.
3. In the Join Grid dialog box, enter the following:
— Virtual IP of Grid Master: Type the VIP address of the HA grid master or the LAN address of the single grid
master for the grid to which you want to add the HA pair.
— Grid Name: Type the name of the grid.
— Grid Shared Secret: Type the shared secret of the grid.
— Retype Grid Shared Secret: To ensure accuracy, retype the shared secret.
— Use MGMT port to join grid: If you have already enabled the MGMT port (see Grid Communications on page
92), this option becomes available. Select it to connect to the grid through the MGMT port of the active
node of the HA pair.
4. Click OK to begin the join operation.
5. To confirm that the HA pair has successfully joined the grid, log in to the grid master and from the Grid
perspective, click + (for id_grid) -> + (for Members), and check the icon in the Status column (green = the HA pair
has joined the grid and is functioning properly; yellow = the HA pair is in the process of joining the grid; red = the
HA pair has not joined the grid). Also, select the member, and then click View -> Detailed Status.
222
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring a Grid
Configuration Example: Configuring a Grid
In this example, you configure seven Infoblox devices in a grid serving internal DHCP and DNS for an enterprise with
the domain name corp100.com. There are four sites: HQ and three branch offices. A hub-and-spoke VPN tunnel
system connects the sites, with HQ at the hub. The distribution and roles of the Infoblox devices at the four sites are
as follows:
•
HQ site (four devices in two HA pairs):
— HA grid master – hidden primary DNS server
— HA member – secondary DNS server and DHCP server for HQ
•
Site 1 (two devices in an HA pair): HA member – secondary DNS server and DHCP server for Site 1
•
Site 2(one device): single member – secondary DNS server and DHCP server for Site 2
Note: When adding Infoblox-1050, -1550, and -1552 appliances to an existing grid, you must first upgrade the grid
to DNSone 3.2r9 or later.
To create a grid, you first create a grid master and then add members. The process involves these three steps:
1. Configuring two devices at HQ as the grid master. See Create the Grid Master on page 225.
2. Logging in to the grid master and defining the members that you want to add to the grid; that is, you configure
grid member settings on the grid master in anticipation of later joining those devices to the grid. See Define
Members on the Grid Master on page 226.
3. Logging in to the individual devices and configuring them so that they can reach the grid master over the network
and join the grid. See Join Devices to the Grid on page 228.
After creating the grid and adding members, you use the Data Import Wizard to import DHCP and DNS data from
legacy servers. See Import DHCP Data on page 229 and Import DNS Data on page 231.
Finally, you transition DHCP and DNS service from the legacy servers to the Infoblox grid members. See Enable DHCP
and Switch Service to the Grid on page 234.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
223
Deploying a Grid
Figure 9.13 Network Diagram
HQ Site
Zone: corp100.com
...
Zone: lab.corp100.com
...
Network: 10.0.1.0/24
Address Range:10.0.1.50 - 10.0.1.200
Network: 10.0.15.0/24
Address Range:10.0.15.50 - 10.0.15.200
NTP Server
3.3.3.3
All Infoblox
appliances are in
the Pacific time
zone
HA Grid Member
ns2.corp100.com
VIP: 10.0.2.10
VRID: 210
Secondary DNS Server
DHCP Server
Legacy Secondary
DNS Server
ns2.corp100.com; 10.0.2.5
and
DHCP server 10.0.2.20
Grid Master
ns1.corp100.com
VIP: 10.0.1.10
VRID: 143
Hidden Primary
DNS Server
Legacy Hidden Primary
DNS Server
ns1.corp100.com;
10.0.1.5
VPN Tunnel
Internet
Firewalls
...
Zone: site1.corp100.com
Network: 10.1.1.0/24
Address Range:10.1.1.50 - 10.1.1.200
HA Grid Member
ns3.site1.corp100.com
VIP: 10.1.1.10
VRID: 111
Secondary DNS Server
DHCP Server
Single Grid Member
ns4.site2.corp100.com
LAN: 10.2.1.10
Secondary DNS Server
DHCP Server
Legacy Secondary DNS Server
ns3.site1.corp100.com; 10.1.1.5 and
DHCP server 10.1.1.20
Branch Office: Site 1
...
Zone: site2.corp100.com
Network: 10.2.1.0/24
Address Range:10.2.1.50 - 10.1.1.200
Legacy Secondary DNS Server
ns4.site2.corp100.com; 10.2.1.5 and
DHCP server 10.2.1.20
Branch Office: Site 2
Cable All Devices to the Network and Turn On Power
Cable the Infoblox devices to network switches. After cabling each device to a switch and connecting it to a power
source, turn on the power. For information about installing and cabling the device, refer to the user guide or
installation guide that ships with the product.
1. At HQ and Site 1, connect ethernet cables from the LAN1 and HA ports on the devices in each HA pair to a switch,
connect the devices to power sources, and turn on the power for each device.
Note: When connecting the nodes of an HA pair to a power source, connect each node to a different power
source if possible. If one power source fails, the other might still be operative.
224
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring a Grid
2. At Site 2, connect an ethernet cable from the LAN1 port on the single device to a switch, connect the device to a
power source, and turn on the power for that device.
Create the Grid Master
Configure two devices at HQ to be the two nodes that make up the HA pair forming the grid master.
Grid Master – Node 1
1. By using the LCD or by making a console connection to the device that you want to make Node 1 of the HA pair
for the grid master, change the default network settings of its LAN1 port to the following:
— IP Address: 10.0.1.6
— Netmask: 255.255.255.0
— Gateway: 10.0.1.1
2. Connect your management system to the HQ network, open a browser window, and connect to https://10.0.1.6.
3. Log in using the default user name and password admin and infoblox.
The Infoblox Appliance Startup Wizard opens.
4. Enter the following to set up Node 1 of the HA pair:
Wizard Screen
Enter
Deployment type
Grid master/member
License validation
Check that a Keystone license is installed.
Grid type
Grid master
HA node type
First HA node
Grid information
Grid Name: corp100
Shared Secret: Mg1kW17d
Node information
Virtual IP: 10.0.1.10
Subnet Mask: 255.255.255.0
Gateway: 10.0.1.1
Host Name: ns1.corp100.com
Node 1:
•
LAN1 Address: 10.0.1.6
•
HA Address: 10.0.1.7
Node 2:
•
LAN1 Address: 10.0.1.8
•
HA Address: 10.0.1.9
Virtual Router ID: 143
Default password
Time settings
New admin password: 1n85w2IF
Enable NTP: Select check box.
IP address: 3.3.3.3
Time zone: (UMT – 8:00 Pacific Time (US and Canada),
Tijuana
When you click Finish, the Infoblox GUI application restarts. Close the browser window, leaving the JWS (Java
Web Start) login window open.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
225
Deploying a Grid
Grid Master – Node 2
1. By using the LCD or by making a console connection to the device that you want to make Node 2 of the HA pair
for the grid master, change the default network settings of its LAN1 port to the following:
— IP Address: 10.0.1.8
— Netmask: 255.255.255.0
— Gateway: 10.0.1.1
2. In the JWS login window, type 10.0.1.8 in the Hostname field.
3. Log in using the default user name and password admin and infoblox.
4. When the Infoblox Appliance Startup Wizard opens, enter the following to set up Node 2 of the HA pair:
Wizard Screen
Enter
Deployment type
Grid master/member
License validation
Check that a Keystone license is installed.
Grid node type
Grid master
HA node type
Second HA node
Node information
IP Address: 10.0.1.8
Subnet Mask: 255.255.255.0
Gateway: 10.0.1.1
Node provisioning
Master’s Virtual IP: 10.0.1.10
Grid Name: corp100
Shared Secret: Mg1kW17d
1. Confirm the configuration, and then on the last screen of the wizard, click Finish.
The HTTPS session terminates, but the JWS login window remains open.
2. In the JWS login window, type 10.0.1.10 (the VIP address for the grid master) in the Hostname field.
3. Log in using the default user name admin and the password 1n85w2IF.
4. To check the status of the two nodes forming the grid master, from the Grid perspective, click + (for corp100) ->
+ (for Members) -> 10.0.1.10. Check that the status indicators are all green in the Detailed Status panel.
During the joining process, a device passes through the following four phases:
1. Offline – the state when a grid member—in this case, the second node of the HA pair composing the grid master—
is not in contact with the active node of the master
2. Connecting – the state when a device matching a member configuration contacts the master to join the grid and
negotiates secure communications and grid membership
3. Synchronizing – the master transmits its entire database to the member
4. Running — the state when a member is in contact with the master and is functioning properly
Note: Depending on the network connection speed and the amount of data that the master needs to synchronize
with the member, the process can take from several seconds to several minutes to complete.
Define Members on the Grid Master
Before logging in to and configuring the individual devices that you want to add to the grid, define them first on the
grid master.
226
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring a Grid
HQ Site – HA Member
1. On the grid master, open the Grid perspective, and then click corp100 -> Edit -> Add Grid Member.
2. In the Add Grid Member editor, click Node Properties, and then enter the following:
— Host Name: ns2.corp100.com
— (V)IP Address: 10.0.2.10
— Subnet Mask: /24 (255.255.255.0)
— Gateway: 10.0.2.1
— Comment: HQ Site - ns2.corp100.com
— HA Pair: Select check box.
— Virtual Router ID: 210
— Node 1:
— LAN Address: 10.0.2.6
— HA Address: 10.0.2.7
— Node 2:
— LAN Address: 10.0.2.8
— HA Address: 10.0.2.9
3. Click the Save icon.
Site 1 – HA Member
1. On the grid master, open the Grid perspective, and then click corp100 -> Edit -> Add Grid Member.
2. In the Add Grid Member editor, click Node Properties, and then enter the following:
— Host Name: ns3.site1.corp100.com
— (V)IP Address: 10.1.1.10
— Subnet Mask: 255.255.255.0
— Gateway: 10.1.1.1
— Comment: Site 1 - ns3.site1.corp100.com
— HA Pair: Select check box.
— Virtual Router ID: 111
— Node 1:
— LAN Address: 10.1.1.6
— HA Address: 10.1.1.7
— Node 2:
— LAN Address: 10.1.1.8
— HA Address: 10.1.1.9
3. Click the Save icon.
Site 2 – Single Member
1. On the grid master, open the Grid perspective, and then click corp100 -> Edit -> Add Grid Member.
2. In the Add Grid Member editor, click Node Properties, and then enter the following:
— Host Name: ns4.site2.corp100.com
— (V)IP Address: 10.2.1.10
— Subnet Mask: 255.255.255.0
— Gateway: 10.2.1.1
— Comment: Site 2- ns4.site2.corp100.com
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
227
Deploying a Grid
3. Click the Save icon.
4. Log out from the grid master by clicking File -> Logout.
Join Devices to the Grid
To complete the process of adding devices to the grid, log in to and configure each individual device so that it can
contact the grid master.
HQ Site – HA Grid Member (Node 1)
Make a console connection to the device that you want to make Node 1 in the HA pair, and enter the following:
Infoblox > set network
NOTICE: All HA configuration is performed from the GUI. This interface is used only
to configure a standalone node or to join a grid.
Enter IP address: 10.0.2.6
Enter netmask [Default: 255.255.255.0]:
Enter gateway address [Default: 10.0.2.1]:
Become grid member? (y or n): y
Enter Grid Master VIP: 10.0.1.10
Enter Grid Name: corp100
Enter Grid Shared Secret: Mg1kW17d
New Network Settings:
IP address: 10.0.2.6
Netmask: 255.255.255.0
Gateway address: 10.0.2.1
Join grid as member with attributes:
Grid Master VIP: 10.0.1.10
Grid Name: corp100
Grid Shared Secret: Mg1kW17d
WARNING: Joining a grid will replace all the data on this node!
Is this correct? (y or n): y
Are you sure? (y or n): y
The Infoblox application restarts. After restarting, the device contacts the grid master and joins the grid as Node 1.
HQ Site – HA Member (Node 2)
Make a console connection to the device that you want to make Node 2 in the HA pair, and enter exactly the same
data you entered for Node 1 except that the IP address is 10.0.2.8.
After the application restarts, the device contacts the grid master and joins the grid as Node 2, completing the HA
member configuration for the HQ site.
Site 1 – HA Grid Member (Node 1)
Make a console connection to the device that you want to make Node 1 in the HA pair at Site 1, and use the set
command to configure its basic network and grid settings. Use the following data:
network
— IP Address: 10.1.1.6
— Netmask: 255.255.255.0
— Gateway: 10.1.1.1
228
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring a Grid
— Grid Master VIP: 10.0.1.10
— Grid Name: corp100
— Grid shared secret: Mg1kW17d
The Infoblox application restarts. After restarting, the device contacts the grid master and joins the grid as Node 1.
Site 1 – HA Grid Member (Node 2)
Make a console connection to the device that you want to make Node 2 in the HA pair at Site 1, and enter exactly the
same data you entered for Node 1 except that the IP address is 10.1.1.8.
After the application restarts, the device contacts the grid master and joins the grid as Node 2, completing the HA
member configuration for Site 1.
Site 2– Single Grid Member
Make a console connection to the device that you want to make Node 1 in the HA pair at Site 1, and use the set
network command to configure its basic network and grid settings. Use the following data:
— IP Address: 10.2.1.10
— Netmask: 255.255.255.0
— Gateway: 10.2.1.1
— Grid Master VIP: 10.0.1.10
— Grid name: corp100
— Grid shared secret: Mg1kW17d
The Infoblox application restarts. After restarting, the device contacts the grid master and joins the grid.
To check the status of all the grid members, log in to the grid master at 10.0.1.10, and from the Grid perspective, click
+ (for corp100) -> + (for Members) -> 10.0.1.10. Check that the status indicators are all green in the Detailed Status
panel. As a device joins a grid, it passes through the following phases: Offline, Connecting, (Downloading Release
from Master), Synchronizing, and Running.)
Note: Depending on the network connection speed and the amount of data that the master needs to synchronize
with the member, the process of joining a grid can take from several seconds to several minutes to complete.
The grid setup is complete.
Import DHCP Data
The Data Import Wizard is a software tool that you can download from the Infoblox Support site to your management
system. With it, you can import data from legacy DHCP and DNS servers to Infoblox devices. In this example, you use
it to import both DHCP and DNS data to the grid master at 10.0.1.10, which then uses the database replication
mechanism to send the imported data to other grid members. In the wizard, you also specify which grid members
serve the imported data. The wizard supports various types of DHCP formats, such as the following:
•
ISC DHCP
•
Lucent VitalQIP
•
Microsoft
•
Nortel NetID
•
CSV (comma-separated values); you can also import IPAM data in CSV format
In this example, all the DHCP data is in standard ISC DHCP format.
Note: Before using the Data Import Wizard, you must make an initial connection to the Infoblox GUI using JWS (Java
Web Start), which downloads to your management system the Java application files that you need to run the
wizard. Because you used JWS in Create the Grid Master on page 225, you already have the necessary files
installed.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
229
Deploying a Grid
Importing DHCP Data for HQ and Site 2
1. Save the DHCP configuration file from your legacy DHCP server at 10.0.2.20 to a local directory.
2. Visit www.infoblox.com/support , log in with your support account, and download the Data Import Wizard. The
Data Import Wizard application downloads to a container within a Java sandbox on your management system and
immediately launches, displaying the Welcome page.
3. After reading the information in the left panel, click Next.
4. Select Import to Infoblox Appliance, enter the following, and then click Next:
— Hostname or IP address: 10.0.1.10
— Username: admin
— Password: 1n85w2IF
5. Select the following, and then click Next:
— What kind of data would you like to import? DHCP/IPAM
— Which legacy system are you importing from? ISC DHCP
— Which appliance will be serving this data? 10.0.2.10
6. Type the path and file name of the DHCP configuration file saved from the legacy server, and then click Next.
or
Click Browse, navigate to the file, select it, click Open, and then click Next.
7. In the Global DHCP Configuration table, double-click the Value cell for the domain-name-servers row, and change
the IP addresses to 10.0.2.10.
8. When satisfied with the data, click Import.
You can view the status of the importation process and a summary report in the Data Import Wizard Log.
9. To enable DDNS updates, log in to the grid master, open the DHCP and IPAM perspective and click DHCP
Members -> corp100 -> Edit -> Grid DHCP Properties.
10. In the Grid DHCP Properties editor, click DNS Updates.
11. Select Enable dynamic DNS updates, and then click OK.
12. Click the Save and Restart Services icons.
13. To check the imported DHCP configuration file, click DHCP Members -> + (for corp100) -> 10.0.2.10 -> View -> DHCP
Configuration.
14. In the DHCP configuration file, check that all the imported subnets are present, and navigate to the beginning of
the file and check that you see the ddns-updates on statement. ( If you see ddns-updates off , enable
DDNS updates for the grid as explained in steps 9-12.)
Importing DHCP Data for Site 1
1. Repeat the steps in Importing DHCP Data for HQ and Site 2, saving the DHCP configuration file from your legacy
DHCP server at 10.1.1.20, and importing it to the grid master at 10.0.1.10 for the member with IP address
10.1.1.10 to serve.
2. Check the imported DHCP configuration file by logging in to the grid master and from the DHCP and IPAM
perspective, click DHCP Members -> + (for corp100) -> 10.1.1.10 -> View -> DHCP Configuration.
Importing DHCP Data for Site 3
1. Repeat the steps in Importing DHCP Data for HQ and Site 2, saving the DHCP configuration file from your legacy
DHCP server at 10.1.1.20, and importing it to the grid master at 10.0.1.10 for the member with IP address
10.3.1.10 to serve.
2. After the importation process completes, check the imported DHCP configuration file by logging in to the grid
master and from the DHCP and IPAM perspective, click DHCP Members -> + (for corp100) -> 10.3.1.10 -> View ->
DHCP Configuration.
230
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring a Grid
Import DNS Data
Using the Infoblox Data Import Wizard, import DNS data from the legacy hidden primary server at 10.0.1.5 to the new
hidden primary server at 10.0.1.10 (the grid master). There are three phases to this task:
•
Before Using the Wizard on page 231:
— Save the named.conf file from the legacy server to a file in a local directory on your management system.
— Enable the legacy server to perform zone transfers to the Infoblox device.
— Configure three name server groups for the grid, and allow the grid master/hidden primary DNS server at
10.0.1.10 to receive DDNS updates from the grid members at 10.0.2.10, 10.1.1.10, and 10.3.1.10. These
members act as secondary DNS servers and DHCP servers.
•
Using the Wizard on page 232: Define the source, destination, and type of DNS data in the DNS configuration
file (named.conf) that you want to import.
•
After Using the Wizard on page 234: Check the imported DNS configuration file.
In this example, all the DNS data is in BIND 9 format. The Data Import Wizard supports various types of DNS formats,
such as the following:
•
BIND 4, 8, and 9
•
Microsoft
•
Lucent VitalQIP
•
Nortel NetID
Before Using the Wizard
You must set up the legacy server and grid master before using the Data Import Wizard.
Legacy Server
1. Log in to the legacy name server at 10.0.1.5 and save the named.conf file, which contains all the DNS settings
that you want to import into the Infoblox name server, to a local directory on your management system.
2. On the legacy server, enable zone transfers to the Infoblox device.
Infoblox Grid Master– DDNS Updates
1. Log in to the grid master at 10.0.1.10, open the DNS perspective and click DNS Members -> + (for corp100) ->
10.0.1.10 -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Updates and enter the following:
3. Override grid update settings: Select check box.
4. Allow dynamic updates from: Click Add.
5. In the Dynamic Updater Item dialog box, enter the following, and then click OK:
6. IP Address Option: Select this option, and enter 10.0.2.10 in the adjacent field.
7. Permission: Allow
8. Click the Save icon.
9. Repeat steps 2 to 4 to add 10.1.1.10 and 10.2.1.10 as IP addresses from which you allow DDNS updates.
Note: When all DNS servers are members in the same grid, the members use database replication to synchronize all
their data—including DNS zone data. You can change the default behavior so that grid members use zone
transfers instead. In this example, grid members use database replication.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
231
Deploying a Grid
Infoblox Grid Master – Name Server Groups
1. From the DNS perspective, click DNS Members -> corp100 -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Name Server Groups -> Add, to open the Grid Name Server Group dialog
box.
3. Enter the following:
— Name Server Group Name: HQ-Group
— Grid Primary: ns1.corp100.com; Stealth: Select check box.
— Grid Secondaries: Click Add -> Select Member, select ns2.corp100.com in the Select Grid Member dialog
box, and then click OK. Select Grid replication (recommended), and then click OK to close the Name Server
Group Member Secondary dialog box and return to the Grid Name Server Group dialog box.
4. Click OK to close the Grid Name Server Group dialog box.
5. Repeat steps 2 to 4 to create another group. Name it Site1-Group, and use ns1.corp100.com as the hidden
primary server, ns3.site1.corp100.com as a secondary server, and grid replication for zone updates.
6. Repeat steps 2 to 4 to create another group. Name it Site2-Group, and use ns1.corp100.com as the hidden
primary server, ns4.site2.corp100.com as a secondary server, and grid replication for zone updates.
7. Click the Save and Restart Services icons.
Using the Wizard
While progressing through the Data Import Wizard, you must define the source, destination, and type of DNS data
that you want to import. You then make some simple modifications to the data and import it.
Defining the Source, Destination, and Type of DNS Data
1. Launch the Data Import Wizard.
2. After reading the information in the left panel of the welcome page, click Next.
3. Select Import to Infoblox Appliance, enter the following, and then click Next:
— Hostname or IP address: 10.0.1.10
— Username: admin
— Password: 1n85w2IF
The Data Import Wizard Log opens in a separate window behind the wizard. Leave it open while you continue.
4. Select the following, and then click Next:
— What kind of data would you like to import? DNS
— Which legacy system are you importing from? BIND 9
— Which appliance will be serving this data? 10.0.1.10
5. Select the following, and then click Next:
— What BIND 9 DNS configuration file would you like to use? Click Browse, navigate to the named.conf file you
saved from the legacy server, select it, and then click Open.
— What type of BIND 9 DNS data do you want to import? DNS zone information and DNS record data
— Where is the BIND 9 DNS record data? Zone transfer(s) from a DNS server; 10.0.1.5
The wizard displays two tables of data. The upper table contains global DNS server configuration parameters.
The lower table contains zone configurations.
The Data Import Wizard Log presents a summary listing the number of views, zones, and DNS records in the
configuration file.
232
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example: Configuring a Grid
Modifying DNS Data
While importing data from the legacy DNS server, you cancel the importation of global configuration settings, and
apply the name server groups you created in Before Using the Wizard on page 231 to the zones you want to import.
1. In the Global DNS Configuration table, select all rows by clicking the top row and then SHIFT+clicking the bottom
row.
2. Right-click the selected rows to display the Set Import Options dialog box, select Do not import, and then click
Apply.
3. In the DNS Zones table, clear the Import check box for the default view.
4. Select corp100.com, lab.corp100.com and all the corresponding reverse-mapping zones.
Note: You can use SHIFT+click to select multiple contiguous rows and CTRL+click to select multiple
noncontiguous rows.
5. Right-click the selected rows, and then select Set Import Options.
6. In the Set Import Options dialog box, enter the following, and then click Apply:
— Set Zone Type: No change
— Set Import Option: No change
— Set View: default
— Set Member: HQ-Group master
7. Select site1.corp100.com and all the reverse-mapping zones with 1 in the second octet in the zone name
(1.1.10.in-addr.arpa, 2.1.10.in-addr.arpa, 3.1.10.in-addr.arpa, and so on).
8. Right-click the selected rows, and select Set Import Options.
9. In the Set Import Options dialog box, make the same selections as in Step 6 , but choose Site1-Group master
from the Set Member drop-down list.
10. Similarly, select site2.corp100.com and all the reverse-mapping zones with 2in the second octet in the zone
name.
11. Right-click the selected rows, and select Set Import Options.
12. In the Set Import Options dialog box, make the same selections as in Step 6 , but choose Site2-Group master
from the Set Member drop-down list.
Importing DNS Data
1. Click Import.
The wizard imports the global DNS parameters and zone-specific configuration settings from the named.conf
file and performs a zone transfer of the data from the legacy server.
2. Use the Data Import Wizard Log to monitor progress and review results afterward.
The log lists all the zones that the wizard imports and concludes with a total of all the successfully and
unsuccessfully imported zones.
Note: If the wizard is unable to import a zone, an error message with an explanation appears in the log.
3. To close the Data Import Wizard, click Exit. This closes the Data Import Wizard Log as well.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
233
Deploying a Grid
After Using the Wizard
After you import data, you must restart services on the grid master and delete the A records for the legacy servers
from the corp100.com zone. You can also confirm that the imported data is correct and complete by checking the DNS
configuration and the forward- and reverse-mapping zones.
1. Log in to the grid master (10.0.1.10), and then click the Restart Services icon.
Note: When importing data through the wizard rather than entering it through the GUI, the Restart Services icon
does not change to indicate you must restart service for the device to apply the new data. Still, restarting
service on the grid master is necessary for the imported configuration and data to take effect.
2. To remove A records for the legacy servers, from the DNS perspective, click Infoblox Views -> + (for Infoblox Views)
-> + (for default) -> + (for Forward Mapping Zones) -> corp100.com.
3. CTRL+click the following A records in the corp100.com zone, and then click Edit -> Remove Multiple:
— ns1 (for 10.0.1.5)
— ns2 (for 10.0.2.5)
— ns3.site1.corp100 (for 10.1.1.5)
— ns4.site3.corp100 (for 10.2.1.5)
4. Remove the respective A records for legacy servers from the site1.corp100 and site3.corp100 subzones.
5. To check the imported DNS configuration file, from the DNS perspective, click DNS Members -> + (for corp100) ->
10.0.1.10 -> View -> DNS Configuration.
Note: If you do not see the imported DNS configuration file, make sure you enabled DNS and restarted services.
6. Scroll through the DNS configuration log to check that each imported zone has an allow-update statement like
the following one for the 10.1.10.in-addr.arpa reverse-mapping zone:
zone "10.1.10.in-addr.arpa" in {
…
allow-update { key DHCP_UPDATER; 10.0.2.10; 10.1.1.10; 10.2.1.10; };
…
};
Enable DHCP and Switch Service to the Grid
Finally, you must enable DHCP service on the three grid members at 10.0.2.10, 10.1.1.10, and 10.2.1.10, and switch
DNS and DHCP service from the legacy DNS and DHCP servers to them.
1. Log in to the grid master (10.0.1.10), from the DHCP and IPAM perspective, click DHCP Members -> + (for
corp100) -> 10.0.2.10 -> Edit -> Member DHCP Properties -> General Properties, select Enable DHCP Server , and
then click the Save icon.
2. Click 10.1.1.10 -> Edit -> Member DHCP Properties -> General Properties, select Enable DHCP Server , and then
click the Save icon.
3. Click 10.3.1.10 -> Edit -> Member DHCP Properties -> General Properties, select Enable DHCP Server , and then
click the Save and Restart Services icons.
Note: DNS service is enabled by default. To confirm that it is enabled, from the DNS perspective, click DNS
Members -> + (for corp100) -> 10.0.2.10 -> Edit -> Member DNS Properties -> General Properties, and make
sure the Enable DNS Server check box is selected.
The grid members are ready to serve DHCP and DNS, and send DDNS updates.
4. Take the legacy DHCP and DNS servers offline.
234
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Enabling IPv6 On a Grid Member
Enabling IPv6 On a Grid Member
The Infoblox device supports IPv6 (Internet Protocol version 6) connection on grid members. You can configure the
grid member to support both IPv4 (Internet Protocol version 4) and IPv6 connections by configuring an IPv6 address
on a member in addition to the standard IPv4 address. Grid members can support both IPv4 and IPv6 simultaneously,
otherwise known as dual-stack mode.
Infoblox integrates IPv6 address management into many of the same places where IPv4 addresses are entered. Data
validation occurs on all IP fields and automatic validation is done to ensure proper entry of either an IPv4 address or
an IPv6 address.
This section discusses the following topics:
•
•
Introduction to IPv6 on page 235
Configuring IPv6 on a Grid Member on page 236
Introduction to IPv6
IP (Internet Protocol) and TCP (Transmission Control Protocol) comprise the TCP/IP model, based on the OSI reference
model. IP provides the Layer-3 (network layer) connection and TCP provide the Layer-4 (transport layer) connection.
Together, TCP/IP encapsulates the data and provides the connection through a network.
You can configure the Infoblox device to provide DNS services over IPv4 and over IPv6 networks. The specific version
of IP used to reach a grid member determines the IP connection that the device uses to serve the query.
In general, a DNS resolver looks up a host name starting out at the root, and continues resolving down the name path
until reaching the appropriate authoritative name server. The authoritative name server containing the correct
hostname can operate with both IP versions as the connection. If the client and the name server are not supporting
similar versions of IP, then the query is unsuccessfully and terminated. With the introduction of IPv6 support, this
incompatibility is avoided by enabling dual-mode support of IP on the device.
You can configure the grid member as a dual-mode name server, capable of serving DNS data for both IPv4 and IPv6
queries. An IPv4 query returns an IPv4 response, while an IPv6 query returns an IPv6 response.
The Infoblox device supports one IPv6 address on the grid member. Grid communication between members
continues to use IPv4 over the HA interface.
An IPv6 address is a 128-bit number in colon hexadecimal notation. It consists of eight 16-bit groups of hexadecimal
digits separated by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
Figure 9.14 IPv6 Address Structure
n bits
m bits
Global Routing Prefix
Network Prefix
Subnet ID
128-n-m bits
Interface ID
Interface ID
When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros. You can
also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note that if there
are multiple noncontiguous groups of zeros, the double colon can only be used for one group to avoid ambiguity. The
Infoblox device displays an IPv6 address in its shortened form, regardless of its form when it was entered.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
235
Deploying a Grid
For more information about DNS for IPv6, see RFC 3596, “DNS Extensions to Support IP Version 6”. For more
information about DNS management options, see Managing DNS Data on page 245.
Configuring IPv6 on a Grid Member
You can enable IPv6 on the device by configuring an IPv6 address on the grid member in addition to the standard IPv4
address.
Configuring a grid containing an IPv4 zone primary and IPv6 secondaries is not supported. You must make sure to
enable IPv6 on both the primary (master) and the secondaries (slaves) within the grid to enable them to communicate
with each other. Infoblox highly recommends that you enable IPv6 on your grid devices before configuring IPv6
secondaries, forwarders, delegations, and subnets.
To configure the member to support both IPv6 and IPv6 connections:
1. Log in to the grid master as a superuser.
2. From the Grid perspective, click grid -> grid_member -> Edit -> Member Properties.
3. In the Edit Grid Member editor, click Node Properties to open up that section, and then enter the following:
— Enable IPv6: Select the check box if you want to enable IPv6 support on the interface.
— (V)IP Address: Type the IPv6 address for the grid member on the interface. An IPv6 address is a 128-bit
number in colon hexadecimal notation. It consists of eight 16-bit groups of hexadecimal digits separated
by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
— CIDR Prefix: Choose the CIDR netmask for the subnet to which the VIP address connects. CIDR is an
alternative to subnet masking that organizes IP addresses into subnetworks. Also known as supernetting,
CIDR allows multiple subnets to be grouped together for network routing. The prefix length can range from 0
to 128, due to the larger number of bits in the IPv6 address.
— Gateway: Type the IPv6 address of the default gateway of the subnet to which the VIP address connects.
— Comment: Type a comment that provides some useful information about the IPv6 interface.
4. Click the Save icon.
Configuration Example: Configuring IPv6 on a Grid Member
Let us revisit the example network topology from the previous section Configuration Example: Configuring a Grid on
page 223. In the previous example, you configured seven Infoblox devices in a grid serving internal DHCP and DNS
for an enterprise with the domain name corp100.com. There were four sites: HQ and three branch offices. The
distribution and roles of the Infoblox devices at the four sites are as follows:
•
HQ site (four devices in two HA pairs):
— HA grid master – hidden primary DNS server.
Enable this member (node 1 and node2) as a dual-mode member, supporting both IPv4 and IPv6
connections.
— HA member – secondary DNS server and DHCP server for HQ
•
Site 1 (two devices in an HA pair): HA member – secondary DNS server and DHCP server for Site 1.
•
Site 2(one device): single member – secondary DNS server and DHCP server for Site 2.
For this example, let us consider only the steps required to update the HA grid master as a dual-mode device,
supporting both IPv4 and IPv6 connections.
236
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Enabling IPv6 On a Grid Member
Figure 9.15 Network Diagram for IPv6 Grid Member Example
HQ Site
Zone: corp100.com
...
Zone: lab.corp100.com
...
Network: 10.0.1.0/24 (IPv4)
Network: 2001::/64 (IPv6)
Network: 10.0.15.0/24
Address Range:10.0.15.50 - 10.0.15.200
Grid Master
ns1.corp100.com
VIP: 10.0.1.10 (IPv4)
Gateway: 10.0.1.1
VIP: 2001::10 (IPv6)
Gateway: 2001::1
VRID: 143
Hidden Primary
HA Grid Member
ns2.corp100.com
VIP: 10.0.2.10
VRID: 210
Secondary DNS Server
DHCP Server
DNS Server
Legacy Hidden Primary
DNS Server
ns1.corp100.com;
10.0.1.5
VPN Tunnel
Internet
To configure the grid master to support both IPv4 and IPv6:
Node 1
1. Log in to the node 1 of the grid master as a superuser.
2. From the Grid perspective, click id_grid --> ns1.corp100.com -> Edit -> Member Properties.
3. In the Edit Grid Member editor, click Node Properties to open up that section, and then enter the following:
— Enable IPv6: Select the check box to enable IPv6.
— (V)IP Address: Type the IPv6 address 2001::10.
— CIDR Prefix: Choose /64 as the CIDR prefix.
— Gateway: Type the IPv6 gateway address 2001::1.
— Comment: Type any useful comment.
4. Click the Save icon.
Node 2
1. Log in to the node 2 of the grid master as a superuser.
2. From the Grid perspective, click id_grid --> ns1.corp100.com -> Edit -> Member Properties.
3. In the Edit Grid Member editor, click Node Properties to open up that section, and then enter the following:
— Enable IPv6: Select the check box to enable IPv6.
— (V)IP Address: Type the IPv6 address 2001::11.
— CIDR Prefix: Choose /64 as the CIDR prefix.
— Gateway: Type the IPv6 gateway address 2001::1.
— Comment: Type any useful comment.
4. Click the Save icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
237
Deploying a Grid
Managing a Grid
After you configure a grid master and add members, you might need to perform the following tasks:
•
•
•
•
•
Changing Grid Properties
Setting the MTU for VPN Tunnels
Removing a Grid Member
Promoting a Master Candidate on page 239
Replacing a Failed Grid Master on page 239
Changing Grid Properties
You can change a grid name, its shared secret, and the port number of the VPN tunnels that the grid uses for
communications. If you make such changes after populating a grid with members, all current members will lose grid
connectivity and you will have to rejoin them to the grid manually.
To modify the properties of a grid:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Name: Type the name of a grid. The default name is Infoblox.
— Shared Secret: Type a shared secret that all grid members use to authenticate themselves when joining the
grid. The default shared secret is test.
— Retype Shared Secret: Type the shared secret again to confirm its accuracy.
— VPN Port Number: Type the port number that the grid members use when communicating with the grid
master through encrypted VPN tunnels. The default port number is 1194. After changing the port number,
you must reboot the single master or the active node of an HA master (which forces an HA failover). For
more information, see Port Numbers for Grid Communication on page 213.
— Enable Recycle Bin: Select the check box to enable the recycle bin feature. This option is supported only for
superusers. The recycle bin stores the deleted items when the user deletes grid, DNS, or DHCP
configuration items in the GUI for the grid member. Enabling the recycle bin allows you to undo the
deletions and to restore the items on the device at a later time. If you do not enable the recycle bin feature,
deleted items from the GUI are permanently removed from the database.
3. Click OK to save your changes.
4. (If necessary after changing the VPN port number) From the Grid perspective, click + (for id_grid) -> + (for
Members) -> master -> Edit -> Reboot.
Setting the MTU for VPN Tunnels
You can configure the VPN MTU (maximum transmission unit) for any device with a network link that does not support
the default MTU size (1500 bytes) and that cannot join a grid because of this limitation. If a device on such a link
attempts to establish a VPN tunnel with a grid master to join a grid, the device receives a PATH-MTU error, indicating
that the path MTU discovery process has failed. (For information about the MTU discovery process, see RFC 1191,
Path MTU Discovery .)
To avoid this problem, you can set a VPN MTU value on the grid master for any device that cannot link to it using a
1500-byte MTU. When the device contacts the master during the key exchange handshake that occurs during the
grid-joining operation, the master sends the device the MTU setting to use.
To set the VPN MTU for a grid member:
1. From the Grid perspective, click + (id_grid ) -> + (for Members) -> member -> Edit -> Member Properties.
2. In the Grid Member editor, click VPN, select Set VPN MTU, and then enter a value between 600 and 1500.
3. Click the Save icon to save the VPN MTU settings for this member.
238
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing a Grid
Removing a Grid Member
You might want or need to remove a member from a grid, perhaps to disable it or to make it an independent device
or an independent HA pair.
To remove a grid member:
1. Log in to the grid master as a superuser.
2. From the Grid perspective, click + (for id_grid) -> + (for Members) -> member -> Edit -> Remove member.
Promoting a Master Candidate
To be able to promote a master candidate, you must have previously designated a grid member as a master candidate
before anything untoward happens to the current master. When adding or modifying a grid member, select the
Master Candidate check box in the Node Properties section in the Grid Member editor for that member.
To promote a master candidate, you can make a direct serial connection to the Console port on the active node of an
HA candidate or to the Console port on single candidate. You can also make a remote serial connection (using SSH
v2) to the candidate. Then enter the following Infoblox CLI command: set promote_master
Note: For information about making a serial connection, see Method 2 – Using the CLI on page 170 and Using the
Serial Console on page 533.
To promote a master candidate, do the following:
1. Establish a serial connection (through a serial console or remote access using SSH) to the master candidate.
2. At the prompt, enter the command:
set promote_master
3. Log in to the Infoblox Grid Manager GUI on the new master using the VIP address for an HA master or the IP
address of the LAN or LAN1 port for a single master.
4. From the Grid perspective, click + (for id_grid) -> + (for Members) -> master .
5. Look at the IP address of the master in the IP Address column to ensure it is the member you promoted.
6. To verify the new master is operating properly, check the icon in the Status column. Also, select the master, and
then click View -> Detailed Status.
Replacing a Failed Grid Master
If a grid master goes down due to network issues or a power or system failure and there is no master candidate, you
can convert an existing member into a new grid master. This procedure assumes the current grid master is
inaccessible. Keep in mind that this is a disaster recovery procedure that is not part of normal device management
and maintenance. You must have an accessible grid member currently operating to perform this procedure.
To replace a grid master:
1. Determine which member you want to assume the grid master role. The following steps refer to the two nodes
which form an HA member. The active node is Node 1, and the passive node is Node 2. If you are unfamiliar with
using the Console port, see Method 2 – Using the CLI on page 170 or Using the Serial Console on page 533.
2. Make a console connection to Node 2, and then enter the CLI command reset database
3. Make a console connection to Node 1, and then enter the CLI command set nogrid
These commands remove the HA pair from the grid and separate the two nodes that formed the HA pair. Node 1
becomes its own grid master. The result of this action is that this new grid master has all the service data as the
existing grid, but with all the member information removed.
4. Log in to the GUI of Node 1 using its LAN IP address. Configure the new master to be an HA pair. The VIP (virtual
IP) address of this HA pair will become the VIP address of the rebuilt grid. You do not need to use the same VIP
address of the failed grid master. Also, configure the grid name and shared secret.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
239
Deploying a Grid
5. Using a serial console connected to Node 2, enter the set network command, and enter the network IP
address, netmask, and gateway settings. When prompted, join it to the new grid by entering the VIP address, grid
name, and shared secret that you set on Node 1.
6. Log in to the new grid master GUI using the grid master VIP. Add the remaining grid members to the new grid.
7. Set the DNS or DHCP properties as required.
8. Assign zones and networks for each member.
9. For each member in the grid, use the serial console to enter the reset database command. After logging back
in, enter set network, and enter the network IP address, netmask, and gateway settings. When prompted, join
it to the new grid by entering the VIP address, grid name, and shared secret that you set on the new grid master.
The grid is now rebuilt with a new grid master.
Using the Recycle Bin
You can use the recycle bin feature on the Infoblox device to store deleted grid, DNS, and DHCP configuration items.
Items stored in the recycle bin can be restored to the active configuration on the device at a later time, or can be
permanently removed from the device database. If you do not use the recycle bin, the device deletes items
permanently from the database.
The Recycle Bin provides the capability to protect against major deletions of data. It is intended to provide a way to
restore data where the deletion of the object (such as a zone) would result in a major data loss.
This section discusses the following topics:
•
•
•
•
•
Disabling the Recycle Bin on page 240
Re-enabling the Recycle Bin on page 241
Viewing the Recycle Bin on page 241
Restoring Items in the Recycle Bin on page 241
Emptying the Recycle Bin on page 242
Disabling the Recycle Bin
You can disable the recycle bin feature globally in the Grid perspective. If you disable the recycle bin, you cannot
restore nor empty the recycle bin. The recycle bin feature is enabled by default on the Infoblox device. If you do not
have superuser privileges, a warning appears prompting you to relogin as superuser before disabling the recycle bin.
To disable the recycle bin feature:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Enable Recycle Bin: Deselect the check box to turn off the recycle bin feature. If you do disable the recycle
bin feature, deleted items from the GUI are permanently removed and unrecoverable.
3. Click OK to save your changes.
240
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing a Grid
Re-enabling the Recycle Bin
You can re-enable the recycle bin feature globally in the Grid perspective. You must enable the recycle bin before
restoring and emptying the recycle bin from the ID Grid perspective or any other perspective. The recycle bin feature
is enabled by default on the Infoblox device. If you do not have superuser privileges, a warning appears prompting
you to relogin as superuser before enabling the recycle bin.
To enable the recycle bin feature for items:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Enable Recycle Bin: Select the check box to enable the recycle bin feature. When you delete configuration
items in the GUI for the grid member, the recycle bin stores the deleted items. Enabling the recycle bin
allows you to undo the deletions and to restore the deleted items on the device at a later time. If you do not
enable the recycle bin feature, deleted items from the GUI are permanently removed and unrecoverable.
3. Click OK to save your changes.
Viewing the Recycle Bin
You can display the Recycle Bin panel and view all deleted items stored in the recycle bin. If you view the recycle bin
panel within the Grid perspective, all items for the grid are displayed. This includes all DHCP and DNS configuration
items. By default, records are sorted by Name. To display the Recycle Bin panel and to view the deleted configuration
items stored in the recycle bin:
1. From the Grid perspective, click id_grid -> View -> Recycle Bin. The Recycle Bin panel appears.
2. Scroll through the Recycle Bin panel pages using the page arrows located on the lower-left corner of the Recycle
Bin panel. The panel page length is set by the administrator as discussed in Creating an Admin Account on page
56. The panel displays each item with the following information:
— Name: Name of the configuration item deleted.
— Object Type: Type of configuration deleted.
— Parent/Container: Where the item was deleted.
— Admin: Who deleted the item.
— Time: When the item was deleted.
Restoring Items in the Recycle Bin
You can restore any configuration items in the recycle bin displayed in the Recycle Bin panel. The restore functionality
is available only if the recycle bin is enabled, and if an item is selected in the panel. Deleted items are stored in the
recycle bin until the recycle bin is emptied.
To restore items from the Recycle Bin panel:
1. From the Grid perspective, click grid -> View -> Recycle Bin. The Recycle Bin panel appears.
2. Select the configuration item you want to restore.
3. Click Edit -> Restore Selected Object. A warning message appears prompting you to confirm that you wish to
continue with the restore.
4. Confirm that the item was restored to the active configuration. You can do this by confirming that the item does
not appear in the Recycle Bin panel any longer, and that it is reestablished in the appropriate perspective.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
241
Deploying a Grid
Emptying the Recycle Bin
You can empty the contents of the recycle bin, permanently removing all of the items displayed in the Recycle Bin
panel from the device database. The empty functionality is available only if the recycle bin is enabled, and only for
superusers. To empty the recycle bin:
1. From the Grid perspective, click grid -> View -> Recycle Bin. The Recycle Bin panel appears.
2. Click Edit -> Empty Recycle Bin. A warning message appears prompting you to confirm that you wish to empty the
recycle bin.
3. Confirm that all items were removed from the Recycle Bin panel.
242
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Part 3 Service Configuration
This section describes how to configure Infoblox devices to provide various services on your network. It includes the
following chapters:
•
Chapter 10, "Managing DNS Data", on page 245
•
Chapter 11, "Configuring DNS Services", on page 313
•
Chapter 12, "Configuring IP Routing Options", on page 339
•
Chapter 13, "Managing DHCP Data", on page 349
•
Chapter 14, "Configuring DHCP Services", on page 369
•
Chapter 15, "Configuring DDNS Updates from DHCP", on page 401
•
Chapter 16, "Managing IP Data – IPAM", on page 419
•
Chapter 17, "NAC Foundation", on page 437
•
Chapter 18, "File Distribution Services", on page 457
•
Chapter 19, "RADIUS Services", on page 463
•
Chapter 20, "VitalQIP", on page 483
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
243
244
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 10 Managing DNS Data
DNS (Domain Naming System) translates IP addresses to host names and back. The types of DNS servers are:
•
Root name servers that are in each top-level domain (com, edu, gov, and net). They determine where the
individual records are stored.
•
Static servers that every computer on the Internet can access.
•
Authoritative server that contain the actual information about each individual domain. This information is
stored in a zone file. The root name servers query authoritative servers to determine the hostname or the IP
address.
DNS uses an efficient, reliable, distributed, and generic mapping system.
•
Efficient—it uses caching and maps most names locally; only a few require Internet traffic.
•
Reliable—a single machine failure does not break the system.
•
Distributed—a set of servers operating at multiple sites together solve the mapping.
•
Generic—it is not restricted to machine names.
The Infoblox device uses a standard, BIND-based DNS protocol engine, so it operates with any other name server that
follows the DNS RFCs (see DNS RFC Compliance on page 502). Managing DNS data includes configuring and
managing Infoblox views, zones, adding records, and managing hosts and records. This chapter explains these topics
and is organized as follows:
•
•
•
•
Configuring DNS Overview on page 247
— DNS Configuration Checklist on page 248
— Restarting Services on page 249
Using Infoblox Views on page 250
— Default View on page 252
— Creating Views on page 252
— Specifying Match Lists on page 254
— Adding Zones to a View on page 255
— Adding Records to a Zone on page 255
— Managing Views on page 257
— Configuration Example: Configuring a View on page 257
Understanding DNS for IPv6 on page 259
— IPv6 Overview on page 259
Delegating Zone Authority to Name Servers on page 261
— Specifying a Primary Server on page 262
— Specifying a Secondary Server on page 263
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
245
Managing DNS Data
•
•
•
•
•
•
•
•
•
•
•
•
246
Configuring Authoritative Zones on page 265
— Creating an Authoritative Forward-Mapping Zone on page 265
— Creating an Authoritative Reverse-Mapping Zone on page 266
— Adding an Authoritative Subzone on page 268
— Creating a Root Zone on page 270
Importing Zone Data on page 271
— Allowing Zone Transfers for a Device on page 274
— Importing Data into Zone on page 274
Configuring Delegated, Forward, and Stub Zones on page 275
— Configuring a Delegated Zone on page 275
— Configuring a Forward Zone on page 276
— Configuring Stub Zones on page 278
Using Name Server Groups
— Creating a Name Server Group on page 283
— Applying a Name Server Group on page 285
Managing Zones on page 286
— Locking and Unlocking Zones on page 286
— Removing Zones on page 287
— Enabling and Disabling Zones on page 289
Using the Recycle Bin on page 289
— Re-enabling the Recycle Bin on page 290
— Viewing the Recycle Bin on page 290
— Restoring Items in the Recycle Bin on page 290
— Emptying the Recycle Bin on page 291
Enabling and Disabling Zones on page 289
Specifying Host Name Restrictions on page 291
Adding a Host or Bulk Host on page 293
— Adding a Host on page 293
— Adding a Bulk Host on page 294
Adding Resource Records on page 296
— Adding an NS(A) Record on page 297
— Adding an AAAA Record on page 297
— Adding a PTR Record on page 298
— Adding an MX Record on page 300
— Adding an SRV Record on page 301
— Adding a TXT Record on page 302
— Adding a CNAME Record on page 303
— Adding a DNAME Record on page 305
Managing Hosts and Resource Records on page 311
— Specifying Time To Live Settings on page 310
— Modifying, Disabling, or Removing a Host or Record on page 311
— Disabling or Enabling a Host or Record on page 311
Viewing DNS Record Listings on page 312
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Overview
Configuring DNS Overview
An overview of the complete DNS configuration process is outlined in the following diagram, illustrating the required
steps for preparing an Infoblox device for use:
Begin the initial configuration of DNS zones and resource records.
Decide on the type of
DNS zones to configure
Forward zone
Primary or secondary zone
- Specify the IP address of the DNS
primary server
- Repeat this step to define other
forward zones or define other
types of zones (optional)
- Specify the IP address and the
FQDN of the DNS primary server
- Add resource records
- Repeat this step to define other
delegated zones or define other
types of zones (optional)
Choose type of
authoritative zone
Secondary only zone
Primary only zone
- Choose the primary member
Delegated zone
Primary and
secondary zone
- Specify the IP address and FQDN
of the external primary
- Choose the secondary members
- Choose the primary member(s)
- Choose the secondary member(s)
- Specify the IP addresses and FQDN for external secondaries
- Proceed to add resource records
Add resource records
- Select the zone to which you want to add records
- Choose a record zone type
- Enter the necessary data for the selected record
- Repeat these steps to add additional records (optional)
Do you want to create
more zones?
Yes
Initial configuration of DNS zones and resource records is complete
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
247
Managing DNS Data
DNS Configuration Checklist
Each step in the previous flowchart above is covered in the following checklist:
Table 10.1 DNS Configuration Checklist
Step
For more information
Decide if you want to create a new view,
in addition to the default view.
•
•
•
•
•
Decide which type of DNS zone you want
to configure
•
•
•
•
•
Configure the zone
•
•
•
Configure a host
•
•
Add resource records
•
•
•
•
•
•
•
•
•
248
Infoblox Administrator Guide (Rev. A)
Creating Views on page 252
Adding Zones to a View on page 255
Ordering Views on page 256
Managing Views on page 257
Configuration Example: Configuring a View on page 257
Configuring Authoritative Zones on page 265
Configuring a Delegated Zone on page 275
Configuring a Forward Zone on page 276
Configuring Stub Zones on page 278
Creating an Authoritative Reverse-Mapping Zone on page 266
Creating an Authoritative Forward-Mapping Zone on page 265
Adding an Authoritative Subzone on page 268
Importing Zone Data on page 271
Adding a Host on page 293
Adding a Bulk Host on page 294
Adding an A Record on page 296
Adding an NS(A) Record on page 297
Adding an AAAA Record on page 297
Adding a PTR Record on page 298
Adding an MX Record on page 300
Adding an SRV Record on page 301
Adding a TXT Record on page 302
Adding a CNAME Record on page 303
Adding a DNAME Record on page 305
NIOS 4.1r3
Configuring DNS Overview
Restarting Services
When you make changes to the services for a grid or member, you must restart services. You can make multiple
changes before restarting the service, however. This process invalidates the cache. To clear the DNS cache, from the
DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Clear Cache.
Note: Restarting services restarts both DNS and DHCP services on the selected nodes.
Restarting Services for a Grid
To restart services for a grid and all its members:
1. From the DNS perspective, click the DNS Members tab -> grid.
2. Select Restart Grid Services, and choose from the following options:
— Sequentially: If you have multiple nodes in the grid, this option restarts the services on each of the nodes
according to the number of seconds you enter in the field. For example, if 10 is entered in the field, each
subsequent node restarts services 10 seconds after the previous node restarted services. You must enter
numbers, not text.
— Immediately: This option restarts the services on all of the nodes in a grid immediately.
3. Click Restart Details to view the services being restarted.
4. Click Refresh to initiate the restart request. The more zones and networks that the member manages, the longer
this takes. When the term Requesting changes to Yes, the node is ready to be restarted.
5. Click OK.
Restarting Services for a Member
To restart services for a specific member of a grid:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member.
2. Click the Restart Services icon, and select from the following options:
— Restart Services: This option only restarts the services displayed in the Restart Service Status dialog box.
— Force Restart Services: This option restarts all of the services managed by the member.
3. Click Restart Details to view the services being restarted on this member.
4. Click Refresh to verify the services being restarted. Only the service(s) with a Yes are restarted.
5. Click OK.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
249
Managing DNS Data
Using Infoblox Views
Infoblox views provide the ability to serve one version of DNS data to one set of clients and another version to another
set of clients. With Infoblox views, the Infoblox device can provide a different answer to the same DNS query,
depending on the source of the query.
In Figure 10.1, the device has two views: an internal view that contains private IP addresses and an external view that
contains public IP addresses. The device receives queries from both internal and external clients. When it receives a
query from Client A (an internal client) the device accesses the internal view and responds with the private IP address
of the site. When it receives a query from Client B (an external client) the device accesses the external view and
responds with the public IP address of the requested site.
Figure 10.1 Internal and External Views
A-1 Client A, an internal client, sends a
request for sales.corp100.com.
A-2 The device retrieves the answer
from the internal view.
Client A
A-3
Internal View
The device responds
with 10.1.1.5.
corp100.com zone
10.1.1.5 sales.corp100.com
B-1 Client B, an external client, sends
a request for sales.corp100.com.
Client B
External View
corp100.com zone
1.1.1.5 sales.corp100.com
B-3 The device responds with
1.1.1.5.
B-2 The device retrieves the answer
from the external view.
You can configure both forward and reverse mapping zones in views and provide DNS services, such as name
resolution, zone transfers and dynamic DNS updates. For information about these services, see Configuring DNS
Services on page 314.
You can provide multiple views of a given zone with a different set of records in each view. In Figure 10.2, both views
contain the corp100.com zone and the sales.corp100.com zone. The finance.corp100.com zone is only in the internal
view, and only internal users are allowed access records in that zone. Resource records can also exist in multiple
zones. In the Figure 10.2 example, the A records for serv1.sales.corp100.com and serv2.sales.corp100.com are in
the sales.corp100.com zones in both views.
Figure 10.2 Zone Data in Each View
Internal View
corp100.com
MX
NS
A
A
External View
A
A
A
A
A
A
corp100.com
MX
A
A
250
rmail.corp100.com
dnsoneA.corp100.com
host1.corp100.com
host2.corp100.com
sales.corp100.com
email.corp100.com
web1.corp100.com
web2.corp100.com
Infoblox Administrator Guide (Rev. A)
serv1.sales.corp100.com
serv2.sales.corp100.com
serv3.sales.corp100.com
printer.sales.corp100.com
host1.sales.corp100.com
host2.sales.corp100.com
finance.corp100.com
A
A
A
A
server.finance.corp100.com
printer.finance.corp100.com
fin1.finance.corp100.com
fin2.finance.corp100.com
sales.corp100.com
A
A
A
A
web3.sales.corp100.com
ftp.sales.corp100.com
serv1.sales.corp100.com
serv2.sales.corp100.com
NIOS 4.1r3
Using Infoblox Views
You can control which clients access a view by through the use of a match list specifying IP addresses and/or TSIG
(transaction signature) keys. When the Infoblox device receives a request from a client, it tries to match the source IP
address and/or TSIG key with its match list when determining which view, if any, the client can access. After the
device determines that a client can access a view, it checks the zone level settings to determine if it can provide the
service the client is requesting.
For information on TSIG keys or defining zone transfer settings, see Enabling Zone Transfers on page 317. For more
information on match lists, see Specifying Match Lists on page 254. For information on defining query settings, refer
to Specifying DNS Queries on page 319.
Figure 10.3 illustrates how the Infoblox device resolves a query for a domain name in a zone of a view. In the example,
the internal view is listed before the external view. Therefore, when the device receives a query, it checks the match
list of the internal view first. When it does not find the source address in the match list of the internal view, it checks
the match list of the external view. The match list of the external view allows all IP addresses.
Next, the Infoblox device checks the zone level settings to determine if it is allowed to resolve queries from the client
for domain names in that zone. After the device determines it is allowed to respond to queries from this client, it
resolves the query and sends back the response to the client.
Figure 10.3 Query Resolution
Internal View
1
Client sends a query for
web1.corp100.com.
2
Infoblox device checks if
the host IP address is
allowed in the match list of
the internal view. It does
not find the client address
in the match list
corp100.com
finance.corp100.com
Match List
cs.corp100.com
Infoblox
Device
External View
Client
5
The device sends
the answer back to
the client.
3 Infoblox device checks if the
host IP address is allowed in
the match list of the external
view. The match list allows all
IP addresses.
Match
Any
corp100.com
Match List
cs.corp100.com
4 Infoblox device checks if it can respond to queries for
domain names in the corp100.com zone from this client.
It determines that it can. The device then looks for the
requested domain name in the corp100.com zone.
When you create more than one view, as shown in Figure 10.3, the order of the views is important. View order
determines the order in which the Infoblox device checks the match lists. In Figure 10.3, the internal view is listed
before the external view. If the views were reversed, no hosts would receive DNS replies from the internal view
because the match list of the external view allows replies to clients with any IP address. For information on how to
order views, see Ordering Views on page 256.
In a grid, each grid member can host its own set of views. A grid member can serve as the primary or secondary server
for multiple views of a particular zone. For information about specifying primary and secondary servers, see
Configuring DNS Zone Services on page 323.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
251
Managing DNS Data
Default View
The Infoblox device provides one default view, with the ability to create multiple custom views. When you upgrade or
migrate from a name server, or an earlier version of software that does not support views, the device places all the
zones defined in the older release in the default view. You can then create additional views and organize the zones
in each view.
Note: Creating a network causes the device to create a reverse zone in the default view, if that reverse zone does not
exits in any other view. For information about creating a network, see Configuring a DHCP Network on page
350
The default view allows all IP addresses access, and has the same recursion setting as its associated member host.
You can rename the default view and modify its settings, but you cannot remove it.
Creating Views
You can create up to 255 views. This section decribes the process for creating and configuring new views.
If you have multiple views, you can order the views, as described in Ordering Views on page 256.
Once created, you can modify the view by:
•
Specifying Match Lists on page 254
•
Adding Zones to a View on page 255
Adding Records to a Zone on page 255
•
Configuring a View
When you configure a view, specify the following:
• A match list specifying the hosts allowed access to the view
If you do not specify a match list, the device allows all hosts to access the view. For more information, see
Specifying Match Lists on page 254. Members of a grid cannot access each other’s view unless explicitly
allowed. To allow a primary server of a zone to receive dynamic DNS updates from grid members, you must add
the members to the match list when you configure a view.
•
Whether or not recursive queries are allowed
When a name server is authoritative for the zones in a view, you can disable recursion since your name server
should be able to respond to the queries without having to query other servers. If you allow recursion in a view,
you can use the match client list to provide the security that queries are only allowed from specified IP
addresses.
Note: This setting overrides the recursion setting at the grid and member levels.
For Match Clients, you specify IP addresses and network addresses allowed or denied access to the view. If you do
not make these specifications, the Infoblox device allows all IP addresses access. You must also specify the IP
address of the management system you are using to connect to the device. For additional information, see Specifying
Match Lists on page 254.
For Match TSIG Clients, you specify the TSIG keys the Infoblox device tries to match to determine whether or not a host
presenting a TSIG key is allowed access to the view. For additional information, see Defining the Match TSIG List for
an Existing View on page 254.
For Match Members, you must add the members to the Match Client List to allow a primary server of a zone to receive
dynamic DNS updates from grid members. Members in a grid cannot access each other’s view unless you explicitly
allow them.
252
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Infoblox Views
To configure a new view:
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Edit -> Add Infoblox View.
2. In the Add Infoblox View editor, click Infoblox View Properties, and specify the following:
— Name: Enter the name of the view. It can be up to 64 characters long and can contain any combination of
printable characters.
— Comment: Enter notes regarding the view.
— Disable this view: Select this check box to disable this view.
— Override member recursive query settings: Select this check box to override grid and member recursive
query settings with the settings specified for this view. If the query is recursive and the recursion option is
enabled, the device queries other servers for the DNS data it needs.
— Allow recursion: Select this check box to enable recursion within the view. This setting overrides the
recursion setting at the grid and member levels.
3. To specify a Match Client list or Match TSIG clients, click Match Clients and do the following:
— For Match Clients: Click Add, specify the following information, and then click OK:
• IP Address: Enter an IP address for the match client.
•
Network: Enter a network IP address for the match client, and select a Subnet mask from the
drop-down list (1-31).
•
Any: Select to allow or deny the local device to send zone transfers to any IP address.
•
Allow: Select to allow a match with the specified destination.
•
Deny: Select to deny a match with the specified destination.
— Optionally, you can:
Modify client properties: Select the member from the list and click Modify.
Remove client: Select the member from the list and click Remove.
Move a client up the list: Select the member and click Move up. The member moves up the list
incrementally with each click of the button.
Move a client down the list: Select the member and click Move down. The member moves down the list
incrementally with each click of the button.
— For Match TSIG Clients: Click Add, specify the following information, and then click OK.
• Key name: Enter a meaningful name for the key, such as a zone name or the name of the remote
name server with which the local server authenticates zone transfer requests and replies. This
name must match the name of the same TSIG key on other name servers that use it to authenticate
zone transfers +with the local server.
•
Key: To use an existing TSIG key, type or paste the key in the Key field.
•
Generate: Click to create a new key.
•
Use DNS One 2.x TSIG: Select check box when the other name server is an Infoblox device running
DNS One 2.x code.
— Optionally, you can:
Modify a TSIG key: Select the member from the list and click Modify.
Remove a TSIG key: Select the member from the list and click Remove.
Move a TSIG key up the list: Select the member and click Move up. The member moves up the list
incrementally with each click of the button.
Move a TSIG key down the list: Select the member and click Move down. The member moves down the
list incrementally with each click of the button.
— Under Match Members, specify the following:
• Match all grid members: Select check box to include all grid members in the address match list.
•
To include specific members only, select each member and click Add.
•
Optionally, you can select a member from the list and click Remove.
4. Click the Save and Restart Services icons, and then click OK.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
253
Managing DNS Data
Specifying Match Lists
When you configure a view, you can create match lists to specify source IP addresses and TSIG keys that are allowed
or denied access to the view. The Infoblox device determines which hosts can access a view by matching the source
IP address or TSIG key with its match lists of IP addresses and TSIG keys. After the device determines a host can
access a view, it checks the zone level settings to determine whether it can provide the service the host is requesting
for that zone. If you do not configure a match client list or a match TSIG list, all devices are allowed access to the view.
To add a match client list or match TSIG list to a new view, see Creating Views on page 252. The following tasks walk
you through modifying a view to add a match client list or match TSIG list.
Defining a Match Client List for an Existing View
To add a Match Client list to an existing view:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View editor, click Match Clients.
3. Click Add, and specify the following information:
— IP Address: Enter an IP address for the match client.
— Network: Enter a network IP Address for the match client, and select a Subnet mask from the drop-down list
(1-31).
— Any: Select to allow or deny the local device to send zone transfers to any IP address.
— Allow: Select to allow a match with the specified destination.
— Deny: Select to deny a match with the specified destination.
— Optionally, you can:
Modify zone member properties: Select the member from the list and click Modify.
Remove a zone member: Select the member from the list and click Remove.
Move a zone member up the list: Select the member and click Move up. The member moves up the list
incrementally with each click of the button.
Move a zone member down the list: Select the member and click Move down. The member moves down the
list incrementally with each click of the button.
4. Click OK.
5. Click the Save and Restart Services icons.
Defining the Match TSIG List for an Existing View
When a device tries to access a view with a TSIG key, the Infoblox device tries to match the TSIG key with the TSIG keys
in this list. It allows a device to access the view only if the TSIG key that the device presents matches a key on its list
of allowed keys.
To add a Match TSIG list to an existing view:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View Properties editor, click Match Clients.
3. In the Match TSIG Clients section, click Add, and specify the following information:
— Key name: Enter a meaningful name for the key, such as a zone name or the name of the remote name
server with which the local server authenticates zone transfer requests and replies. This name must match
the name of the same TSIG key on other name servers that use it to authenticate zone transfers with the
local server.
— Key: To use an existing TSIG key, type or paste the key in the Key field.
— Generate: Click to create a new key.
254
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Infoblox Views
— Use DNS One 2.x TSIG: Select check box when the other name server is an Infoblox device running DNS One
2.x code.
— Optionally, you can:
Modify a TSIG key: Select the member from the list and click Modify.
Remove a TSIG key: Select the member from the list and click Remove.
Move a TSIG key up the list: Select the member and click Move up. The member moves up the list
incrementally with each click of the button.
Move a TSIG key down the list: Select the member and click Move down. The member moves down the list
incrementally with each click of the button.
4. Click OK.
5. Click the Save and Restart Services icons.
Adding Zones to a View
You can add both forward mapping or reverse mapping zones to a view.
To add a zone to a view:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Add Forward
Mapping Zone, Add IPv4 Reverse-Mapping Zone, or Add IPv6 Reverse-Mapping Zone, and select from the
following:
— Authoritative: Delegates the Infoblox device as an authoritative primary or secondary name server for the
zone.
— Forward: Configures the Infoblox device to forward queries for the zone to another name server that can
resolve the queries.
— Stub: Configures the Infoblox device to receive changes automatically to delegation information for a zone
for which another name server is authoritative.
2. Configure the zone. For information about configuring each type of zone, see Configuring Authoritative Zones on
page 265 and Creating an Authoritative Reverse-Mapping Zone on page 266.
3. Click the Save and Restart Services icons.
Adding Records to a Zone
After adding a zone to a view, you can add hosts and records to the zone. For information about adding hosts, see
Adding a Host or Bulk Host on page 293. For information about adding records, see Adding Resource Records on
page 296.
Copying Zone Records
Different views of the same zone may have a number of records in common. If this is the case, you can copy zone
records between views and zones.
Note: You cannot copy records that the Infoblox device automatically creates, such as NS records and glue A records.
In addition, you cannot copy a host record that has a MAC address configured because the device does not
allow duplicate fixed addresses.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
255
Managing DNS Data
To copy zone records between views:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Copy
Zone Records.
2. In the Copy Zone Records dialog box, select the view and zone from the list, and then select a Copy Record Policy:
— Copy All records: Copies all the zone records, including those records not created on the Infoblox device,
such as HINFO records.
— Copy only the following record types: Allows you to select the types of records to copy by clicking the
appropriate check boxes.
3. Click OK.
4. Click the Save and Restart Services icons.
Ordering Views
The Infoblox device can order the views automatically, or you can order the views manually. If you choose to have the
device automatically update the order of the views, it does so after each of the following events:
•
Adding a view to a member.
•
Removing a view from a member.
•
Changing the address match list of a view hosted by the member.
The Infoblox device orders views based on the Match Client list for each view. If you decide to order the views
manually, the device displays a warning message after each of the previously listed events.
Note: Only superusers have the authority privilege to change the order of the views.
To change the order of the views:
1. From the DNS perspective, click DNS Members-> + (for grid) -> grid_member -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Views.
3. Select one of the following:
— Automatically order the views: Click this to automatically order views after adding a new view, removing a
view, or changing the match client list.
— View Ordering: Select a view, and then click Move Up or Move Down to change its location in the list.
4. Click the Save and Restart Services icons.
Understanding Views and IPv6 Addresses
Infoblox devices with both IPv4 and IPv6 enabled can contain both types of addresses in the match client lists. When
you enable IPv6 on the device, the ordering for DNS views in the GUI may be affected. Views are ordered and sorted
automatically based on match client lists. Views with IPv6 enabled are sorted as follows:
•
If the match client lists of all views contain IPv4 addresses only—The device orders views based on IPv4
addresses.
•
If the match client lists of all views contain IPv6 addresses only—The device orders views based on IPv6
addresses.
•
If the match client list of one view have IPv6 addresses and all other views have IPv4 addresses—The device
orders views based on IPv4 addresses, and the IPv6 address is given lowest priority in the ordering.
•
If the match client list of one view have IPv4 addresses and all other views have IPv6 addresses—The device
orders views based on IPv6 addresses, and the IPv4 address is given lowest priority in the ordering.
•
If the match client lists of one view have both IPv4 and IPv6 addresses—The device orders views based on both
IPv4 and IPv6 addresses, but more priority is given to the IPv4 addresses in the ordering.
256
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Infoblox Views
Managing Views
You can add, modify, disable, or remove any custom view. You can also modify and disable the default view, however,
under no circumstances can it be removed.
Modifying a View
To modify a view:
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View editor, modify the necessary properties. For a description of the fields, see Configuring a
View on page 252.
3. Click the Save and Restart Services icons.
Disabling Views
Use this feature when you want to block access to this view temporarily. Disabling a view excludes it from the
named.conf file.
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Infoblox View
Properties.
2. In the Infoblox View editor, click General.
3. Click Disable this view. A check mark appears to show the view is disabled. Click the check box again to re-enable
the view.
4. Click the Save and Restart Services icons.
Removing Views
You can remove all views, except the default view. When you remove a view, the Infoblox device removes the forward
and reverse mappings of all the zones defined in the view.
To remove a view:
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> view -> Edit -> Remove view.
2. Click Yes to confirm the delete request.
3. Click the Save and Restart Services icons.
Configuration Example: Configuring a View
In Figure 10.4, Member-A is a member of a grid. It is the primary name server for the corp100.com zone in the internal
view. It allows the IP address 11.0.0.1 and the 10.2.2.0/24 subnet access to DNS zone data in the internal view. At
the zone level, it allows transfers to an external secondary server, Infoblox-B, with an IP address of 11.0.0.1.
Infoblox-B is a secondary server for the corp100.com zone. The process follows these steps:
•
•
•
Creating an Internal View on Member-A
Adding a Zone to a View, a corp100.com zone to the internal view
Copying Records Between Views, from the corp100.com zone in the default view to the corp100.com zone in the
internal view
•
Verifying the Configuration
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
257
Managing DNS Data
Figure 10.4 Configuring a View
Master
Grid
Member-A 10.0.0.1
Primary Name Server
for corp100.com
View “internal” {
match clients {11.0.0.1; 10.2.2.0/24; };
zone “corp100.com” {
type master;
allow-query {10.2.2.0/24; };
allow-transfer {11.0.0.1; //auto added
Infoblox-B 11.0.0.1
External Secondary Name
Server for corp100.com
zone “corp100.com” {
type slave;
masters { 10.0.0.1; };
Creating an Internal View
1. From the DNS perspective, click the Infoblox Views tab -> Infoblox Views -> Edit -> Add Infoblox View.
2. In the Add Infoblox View editor, click Infoblox View Properties.
3. Specify the following:
— Name: internal.
— Comment: internal view
4. Click Match Clients, and in the Match Clients section, click Add.
5. Do the following for IP addresses 10.2.2.0/24:
— Click IP Address, and enter the IP address in the text field.
— Click Allow.
You will have 25 allowed client addresses in the Match Clients list when you are done.
6. Click the Save and Restart Services icons.
Adding a Zone to a View
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
Zones -> Edit -> Add Forward Mapping Zone -> Authoritative.
2. Click Primary Server Assignment, click Use external primaries, and then click Add.
3. Enter the following information, and then click OK:
— Name: Member-A
— IP Address: 10.0.0.1
4. Click Secondary Server Assignment, and in the External Secondaries section click Add.
5. Enter the following information, and then click OK:
— Name: InfobloxB
— IP Address: 11.0.0.1
6. Click Queries, click Override grid queries settings, and then click Add.
7. In the Zone Query Access Item dialog, click Network, enter the following information, and then click OK:
258
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Understanding DNS for IPv6
— IP Address: 10.2.2.0
— Subnet mask (drop-down list): /8
This allows queries that the device answers from its internal view.
8. Click Authoritative Zone Properties, and enter the following in the Name field: corp100.com
9. Click the Save and Restart Services icons.
Copying Records Between Views
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit Copy Zone Records.
2. In the Copy Zone Records dialog, select default view -> Forward-Mapping Zones -> corp100.com.
3. In the Copy record policy section, select Copy all records, and then click OK.
4. The records from corp100.com in the default view are copied to corp100.com in the internal view.
Verifying the Configuration
1. In the DNS perspective, click DNS Members-> grid -> corp100_grid -> view -> DNS Configuration.
2. In the DNS Config File viewer, scroll through the contents of the file.
Verify that the internal view section is similar to the configuration file shown in Figure 10.4.
Understanding DNS for IPv6
The Infoblox device supports IPv6 (Internet Protocol version 6) addresses for the DNS services described in the
chapter. The following section discusses these topics:
•
•
•
IPv6 Overview on page 259
Configuring DNS for IPv6 Addressing on page 260
Configuring DNS for IPv6 Addressing on page 260
IPv6 Overview
The Infoblox device supports both IPv4 and IPv6 versions of the Internet Protocol. This means that you can configure
DNS services to accommodate queries and responses for IPv4 addresses as well as IPv6 addresses. The device
utilizes authoritative forward-mapping zones containing AAAA records mapping host names to IPv6 addresses, as
well as authoritative reverse-mapping zones with PTR records mapping IPv6 addresses to host names.
Infoblox integrates IPv6 address management into many of the same places where IPv4 addresses are entered. Data
validation occurs on all IP fields and automatic validation is done to ensure proper entry of either an IPv4 address or
an IPv6 address.
Address Structures
IPv4 uses a 32-bit, 4-octet (each octet separated by decimals) addressing structure to designate sources and
destinations within a network. Since there are 32 bits that make up the address, IPv4 can support up to 4 billion
unique addresses.
An IPv6 address is a 128-bit number in colon hexadecimal notation. It consists of eight groups of four hexadecimal
digits separated by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef). Since there are 128 bits that
make up the address, IPv6 can support up to 3.4x1038 unique addresses. The increase in the number of unique IPv6
addresses is one of the biggest advantages of an IPv6 implementation.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
259
Managing DNS Data
Figure 10.5 IPv6 Address Structure
n bits
m bits
Global Routing Prefix
Subnet ID
Network Prefix
128-n-m bits
Interface ID
Interface ID
The IPv6 address structure consists of the following:
•
Global Routing Prefix—Global routing prefix is a (typically hierarchically-structured) value assigned to a site.
•
Subnet ID—Subnet ID is an identifier of a link within the site.
•
Interface iD—Interface Identifier. This portion of the address identifies the interface on the subnet. This is
equivalent to the host identifier for IPv4 addresses.
When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros. You can
also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note that if there
are multiple noncontiguous groups of zeros, the double colon can only be used for one group to avoid ambiguity. The
Infoblox device displays an IPv6 address in its shortened form, regardless of its form when it was entered.
The Infoblox device supports the following DNS functions for IPv6:
•
AAAA records—You can import, serve queries, display, add, delete, and modify AAAA records on the device. An
AAAA record is equivalent to an IPv4 A record, relying upon a forward-mapping zone to map a hostname to an
IPv6 address. A single forward-mapping zone can map names to both IPv4 and IPv6 addresses. The device
autogenerates AAAA records for any of its interfaces that have IPv6 addresses.
•
ip6.arpa— A specific domain for IPv6 is used for DNS reverse lookups called ip6.arpa. This domain maps an
IPv6 address to a hostname. When you specify an IPv6 network, the device automatically creates the
appropriate zone under ip6.arpa.
•
PTR records—Import, serve queries, display, add, delete, and modify PTR records within an ip6.arpa reverse
zone. The PTR record returns a domain name corresponding to an IPv6 address contained in the ip6.arpa zone.
The device does not autogenerate PTR records; the user must configure PTR records manually.
•
DDNS—The device supports AAAA and PTR records for DDNS (Dynamic DNS).
For more information about DNS for IPv6, see RFC 3596, DNS Extensions to Support IP Version 6.
The Infoblox device supports dual-mode IP implementation. DNS services can run on both IPv4 transport and IPv6
transport, implemented by configuring both an IPv4 address and an IPv6 address on the LAN (HA) interface for a grid
member. For information about configuring IPv6 on a grid member, see Enabling IPv6 On a Grid Member on page 235.
Configuring DNS for IPv6 Addressing
Configuring the device to manage DNS services for IPv6 connections are similar to configuring DNS services for IPv4
connections. For simplicity, the IPv6 procedures are located in the same location as the corresponding procedures
for IPv4 in this chapter. In most cases, the key difference within the procedure involves selecting an IPv6 mapping
zone instead of an IPv4 mapping zone. You can configure the following tasks:
260
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Delegating Zone Authority to Name Servers
Table 10.2 IPv6 DNS Configuration Checklist
Step
For more information
Create primary or secondary name
servers and specify an IPv6 root server
•
•
•
•
•
Decide which type of IPv6 zone you want
to configure
•
Configure the IPv6 zone
•
•
•
•
•
•
•
•
•
•
•
Configure IPv6 resource records
•
•
•
•
Adding Zones to a View on page 255
Specifying a Primary Server on page 262
Specifying a Secondary Server on page 263
Creating a Root Zone on page 270
Creating an Authoritative Forward-Mapping Zone on page 265
Creating an Authoritative Reverse-Mapping Zone on page 266
Importing Data into Zone on page 274
Configuring a Delegated Zone on page 275
Configuring a Forward Zone on page 276
Configuring Stub Zones on page 278
Applying a Name Server Group on page 285
Locking and Unlocking Zones on page 286
Removing Zones on page 287
Deleting Multiple Zones on page 289
Enabling and Disabling Zones on page 289
Specifying Host Name Restrictions on page 291
Adding a Host on page 293
Adding an AAAA Record on page 297
Adding a PTR Record on page 298
Specifying Time To Live Settings on page 310
Modifying, Disabling, or Removing a Host or Record on page
311
For information on configuring an IPv6 address on a grid member, see Enabling IPv6 On a Grid Member on page 235.
Delegating Zone Authority to Name Servers
Forward-mapping zones answer name-to-address queries, and reverse-mapping zones answer address-to-name
queries. When you create an authoritative forward-mapping zone or reverse-mapping zone, you must define one or
more name servers as a primary server for that zone. A primary server contains editable zone data, which that server
can send to other (secondary) servers through zone transfers. You can also create one or more secondary name
servers for a zone. A secondary server for a zone receives read-only zone data from the primary server.
Note: The primary/secondary relationship between name servers is also called “master”/”slave”. You can enter,
modify, and remove zone data on the primary (or master) server, which can then send new and modified data
in a read-only form to the secondary (or slave) server. Both primary and secondary name servers are
authoritative for the zone data they serve. The distinction between them is how they get their zone data.
If a zone is part of an internal DNS structure for a private network, the inclusion of a secondary DNS server is optional,
though highly recommended. If a zone is part of an external DNS structure for a public network such as the Internet,
then a secondary server in a different subnet from the primary server is required. This requirement provides an
additional safeguard against localized network failures causing both primary and secondary name servers for a zone
to become inaccessible.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
261
Managing DNS Data
Specifying a Primary Server
Although a zone typically has just one primary name server, you can specify up to ten independent servers for a single
zone. When the primary server is a grid member, however, then only that member can be the primary server. The
ability to specify several primary servers allows you to enter the various IP addresses of a single multihomed server
and to specify multiple individual servers to provide device resiliency in case one becomes inaccessible.
A primary server can be in stealth mode, which means that its NS record is not published among the zone data, and
it does not respond to queries from resolvers and other name servers. Such a server is also called a “hidden primary”.
A hidden primary provides data to its secondary servers, that in turn respond to DNS queries using this data. One of
several advantages of this approach is that you can take the primary server offline for administrative or maintenance
reasons without causing a disruption to DNS service (within the expiration interval set for the validity of its zone
data—the default is 30 days).
To specify a primary server for a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit ->
Authoritative Zone Properties.
2. In the Authoritative Zone editor, click Primary Server Assignment.
3. Choose from the following options:
— Use External Primaries: Click this check box if the device is in a grid and you want to specify a primary server
outside the grid (“external” to the grid). Then click Add (if the device is not already deployed independently
from a grid), enter the following information, and click OK.
•
Name: Type a resolvable domain name for the external primary server.
•
IP Address: Type the IP address of the external primary server.
•
Use TSIG: To authenticate zone transfers between the local device and the external primary server
using a TSIG (transaction signature), select check box. Infoblox TSIGs use HMAC-MD5 hashes.
These are keyed one-way hashes for message authentication codes using the Message Digest 5
algorithm. (For details, see RFC 1321, The MD5 Message-Digest Algorithm, and RFC 2104, HMAC:
Keyed-Hashing for Message Authentication.)
•
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as
that of the TSIG key on the external primary server.
•
Key: Type or paste a previously generated key. This key must also be present on the external
primary server. You can generate a TSIG key, or you can obtain the TSIG key name and key from the
external name server, either by accessing the device yourself or by requesting the device
administrator to deliver them to you through some out-of-band mechanism. Then type or
copy-and-paste that name and key into the appropriate fields.
•
Use DNS One 2.x TSIG: If you want to use TSIG authentication and the external primary name server
is an Infoblox device running DNS One 2.x code, select check box. The local device generates the
required TSIG key for authenticating DNS messages to and from devices running DNS One 2.x code.
If the external primary name server is not running DNS One 2.x, clear check box.
— Grid Primary Name: Enter the domain name of the primary server, or click Select Member, choose a grid
member from the list to be the primary name server, and then click OK.
— Stealth: Click this check box to hide the NS record for the primary name server from DNS queries. The
Infoblox device does not create an NS record for the primary name server in the zone data. Select the check
box again to display the NS record for the primary name server in responses to queries.
— Select Member: Click this button display a Grid Member list from which you can select a member or
members. Click OK to apply your selection.
4. Optionally, you can proceed to Specifying a Secondary Server.
5. Click the Save and Restart Services icons.
262
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Delegating Zone Authority to Name Servers
Note: On the device you configure as a secondary server for a zone, you must associate a TSIG key for each primary
server to which the secondary server requests zone transfers. On the device you configure as a primary server
for a zone, you can set a TSIG key at the grid, member, or zone level. Because the secondary server requests
zone transfers, it must send a specific key in its requests to the primary server. Because the primary server
responds to the requests, it can have a set of TSIG keys from which it can draw when responding. As long as
the primary server can find the same TSIG key that the secondary sends it, it can verify the authenticity of the
requests it receives and authenticate the responses it sends.
Specifying a Secondary Server
A secondary name server is as authoritative for a zone as a primary server. Like a primary server, a secondary server
answers queries from resolvers and other name servers. The main difference between a secondary and primary server
is that a secondary server receives all its data from a primary server, or possibly from another secondary server that
forwards zone data it receives. The zone data passes from a primary to a secondary server (and possibly from that
secondary server on to another secondary server). This process is called a zone transfer.
The advantage of using primary and secondary name servers is that you enter and maintain zone data in one place—
on the primary server. The data is then distributed to the one or more secondary servers.
To specify a secondary zone for a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit ->
Authoritative Zone Properties.
2. In the Authoritative Zone editor, click Secondary Server Assignment.
3. Choose from the following options:
— Grid Secondaries: To select the local device as the secondary server (or if the device is deployed in a grid
and you want to make a different member the secondary server), click Add, enter the following, and then
click OK:
•
Grid Member Name: Enter a grid member domain name, or click Select Member, choose a grid
member from the list, and then click OK.
•
Stealth: Select this check box to hide the NS record for the secondary name server from DNS
queries. The Infoblox device does not create an NS record for this name server in the zone data.
Select the check box again to display the NS record for the secondary name server in responses to
queries. A secondary server in stealth mode is also known as a “hidden secondary”. One possible
case for configuring a hidden secondary is when a secondary server is at a branch office that has a
slow connection to the rest of corporate network. You configure local hosts at that office to send
DNS queries to the secondary server, but you keep it hidden from other name servers on the rest of
the network so that they do not send it queries. Instead, they use a primary server located in a
different part of the network that has faster connection speeds.
•
Lead Secondary: When a primary server is external to a grid whose members are secondary
servers, you can select this check box to designate one member as a lead secondary. The primary
server sends zone transfers to the lead secondary, which distributes the zone data to the other
secondary servers in the grid using zone transfers (not the grid data replication mechanism). After
you designate one grid member as a lead secondary for a zone, you do not have to configure the
members to use the lead secondary server. All other grid members acting as secondary servers for
that zone automatically use that lead secondary to get zone data. Using a lead secondary
simplifies the addition, modification, and removal of other secondary servers in the grid. As long
as the lead secondary remains unchanged, you do not have to update intervening firewall policies
or the external primary server whenever you make changes to non-lead secondary grid members.
This approach also reduces the amount of traffic between primary and secondary servers.
Note: The Lead Secondary option only becomes available after you specify the primary name server as external.
— Updates zones using: Select one of the following options:
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
263
Managing DNS Data
•
Grid replication (recommended): Select to use grid replication to move zone data from the primary
to secondary servers.
•
DNS zone transfers: Select to use zone transfers to move data from the primary to secondary
servers. This option is available only when the primary server is a grid member. If any grid member
is the primary server, you can use zone transfers or database replication to move zone data from
the primary to the secondary servers. A zone transfer can be up to ten times faster than database
replication. However, database replication updates zone data on both the active and passive
nodes on an HA member. Therefore, if there is a failover, the new active node (the previous passive
node) can immediately begin serving zone data with fresh information. If you use zone transfers,
the passive node does not receive the zone data until it becomes an HA master after a failover.
Only then does it send a notify message to the primary server to perform a zone transfer. If there is
a lot of zone data, the transfer can take several minutes—during which the new HA master cannot
serve its zone data. If you have no HA members as secondary servers, zone transfers improve
performance without potential service interruption. If you have HA members as secondary servers,
the zone transfer option can result in service interruption after a failover. Furthermore, if the
primary server is down when the HA member fails over, the new active node cannot get zone data
until the primary server comes back online.
•
External Secondaries: Select this check box if the device is in a grid and you want to specify a
secondary server outside the grid (“external” to the grid), or if the device is deployed
independently from a grid. Then click Add, enter the following, and click OK:
•
Name: Enter a resolvable domain name for the external secondary server.
•
IP Address: Enter the IP address of the external secondary server.
•
Use TSIG: To authenticate zone transfers between the local device and the external secondary
server using a TSIG (transaction signature), select check box. Infoblox TSIGs use HMAC-MD5
hashes. These are keyed one-way hashes for message authentication codes using the Message
Digest 5 algorithm. (For details, see RFC 1321, The MD5 Message-Digest Algorithm, and RFC 2104,
HMAC: Keyed-Hashing for Message Authentication.)
•
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as
that of the TSIG key for this zone on the external secondary server.
•
Key: Type or paste a previously generated key. On the external secondary server, this key must also
be present and associated with this zone. You can generate a TSIG key, or you can obtain the TSIG
key name and key from the external name server, either by accessing the device yourself or by
requesting the device administrator to deliver them to you through some out-of-band mechanism.
Then type or copy-and-paste that name and key into the appropriate fields.
•
Use DNS One 2.x TSIG: Select this check box to use TSIG authentication and the external secondary
name server is an Infoblox device running DNS One 2.x code. The local device generates the
required TSIG key for authenticating DNS messages to and from devices running DNS One 2.x code.
If the external secondary server is not running DNS One 2.x, clear check box.
— Stealth: Click this check box to hide the NS record for the secondary name server from DNS queries. The
Infoblox device does not create an NS record for the secondary name server in the zone data. Select the
check box again to display the NS record for the secondary name server in responses to queries.
Note: On the device you configure as a secondary server for a zone, you must associate a TSIG key for each
primary server to which the secondary server requests zone transfers. On the device you configure as a
primary server for a zone, you can set a TSIG key at the grid, member, or zone level. Because the secondary
server requests zone transfers, it must send a specific key in its requests to the primary server. Because
the primary server responds to the requests, it can have a set of TSIG keys from which it can draw when
responding. As long as the primary server can find the same TSIG key that the secondary sends it, it can
verify the authenticity of the requests it receives and authenticate the responses it sends. Use NTP to
synchronize the time on both name servers that use TSIG-authenticated zone transfers.
4. Click the Save and Restart Services icons.
264
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring Authoritative Zones
Configuring Authoritative Zones
An authoritative zone is a zone for which the local (primary or secondary) server references its own data when
responding to queries. The local server is authoritative for the data in this zone and responds to queries for this data
without referencing another server.
There are two types of authoritative zones:
•
Forward-mapping – An authoritative forward-mapping zone is an area of domain name space for which one or
more name servers have the responsibility for responding authoritatively to name-to-address queries.
•
Reverse-mapping – A reverse-mapping zone is an area of network space for which one or more name servers
have the responsibility for responding to address-to-name queries.
When you add an authoritative forward-mapping zone and delegate responsibility for that zone to a primary name
server whose host name belongs to the name space of that zone, the Infoblox device automatically generates an NS
(name server) record and an A (address) record for that name server. This type of A record is called a glue record
because it “glues” the NS record to the IP address (in the A record) of the name server.
The following sections explain how to create authoritative forward-mapping zones, reverse-mapping zones,
subzones, and a custom root zone:
•
•
•
•
Creating an Authoritative Forward-Mapping Zone on page 265
Creating an Authoritative Reverse-Mapping Zone on page 266
Adding an Authoritative Subzone on page 268
Creating a Root Zone on page 270
Creating an Authoritative Forward-Mapping Zone
An authoritative forward-mapping zone is an area of domain name space for which one or more name servers have
the responsibility for responding authoritatively to name-to-address queries.
Note: A single forward-mapping zone can map names to both IPv4 and IPv6 addresses.
To create an authoritative forward-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
Zones -> Edit -> Add Forward Mapping Zone -> Authoritative.
2. In the Add Forward Authoritative Zone editor, click Authoritative Zone Properties and specify the following:
— Name: Enter the domain name for the zone. Omit the trailing period (“ . ”) that signifies the root zone.
— Comment: Enter a descriptive comment about the zone.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
— NS group: Select from the drop-down menu.
3. Configure the following zone settings:
— Specifying a Primary Server on page 262
— Specifying a Secondary Server on page 263
— Specifying TTL Settings for a Zone on page 325
— Allowing Zone Transfers for a Zone on page 326
— Allowing Query Access for a Zone on page 327
— Supporting Active Directory on page 328
— Enabling the DNS Server to Receive Updates on page 413
— Specifying Host Name Restrictions on page 291
4. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
265
Managing DNS Data
Creating an Authoritative Reverse-Mapping Zone
An authoritative reverse-mapping zone is an area of network space for which one or more name servers—primary and
secondary—have the responsibility for responding to address-to-name queries. Infoblox supports reverse-mapping
zones for both IPv4 and IPv6 addresses.
Note: When you add an IPv4 reverse-mapping zone, the device automatically generates an in-addr.arpa space for
the network address that you specify. When you add an IPv6 reverse-mapping zone, the device automatically
generates an ip6.arpa space.
IPv4 Reverse-Mapping Zone
To add an IPv4 reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> IPv4
Reverse-Mapping Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, click Authoritative Zone Properties.
3. Specify the following zone information:
— Network Address: Enter the IPv4 address for the address space for which you want to define the
reverse-mapping zone. An IPv4 address is a 32-bit number in dotted decimal notation. It consists of four
8-bit groups of decimal digits separated by decimal points (example: 192.168.1.2).
— Subnet Mask: Select a netmask from the drop-down list to define the size of the subnet.
— Comment: Enter a descriptive comment about the zone.
— RFC 2317 Prefix: To use an RFC 2317 prefix, the netmask must be greater than 24 bits; that is, from a 25- to
31-bit netmask (255.255.255.128 – 255.255.255.252). For information, see Enabling an RFC 2317 Prefix.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
— NS Group: Select a group from the drop-down menu, to apply a previously defined name server group to
provide the primary and secondary name servers for this zone.
4. Configure the following zone settings as appropriate:
— Specifying a Primary Server on page 262
— Specifying a Secondary Server on page 263
— Specifying TTL Settings on page 314
— Allowing Zone Transfers for a Zone on page 326
— Allowing Query Access for a Zone on page 327
— Enabling the DNS Server to Receive Updates on page 413
5. Click the Save and Restart Services icons.
266
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring Authoritative Zones
IPv6 Reverse-Mapping Zone
To add an IPv6 reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> IPv6
Reverse-Mapping Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, click Authoritative Zone Properties.
3. Enter the following zone information:
— IPv6 Network Address: Enter the 128-bit IPv6 address for the address space for which you want to define
the reverse-mapping zone. The format of an IPv6 address is eight groups of up to four hexadecimal digits,
each group separated by a colon. Example: 2006:0000:0123:4567:89ab:cdef:0000:0123.
Note: When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros.
You can also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note
that if there are multiple noncontiguous groups of zeros, the double colon can only be used for one group
to avoid ambiguity. The Infoblox device displays an IPv6 address in its shortened form, regardless of its
form when it was entered.
— Network Prefix: Choose the network prefix that defines the IPv6 network address space.
— Comment: Enter a descriptive comment about the zone.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
— NS Group: Select a group from the drop-down menu, to apply a previously defined name server group to
provide the primary and secondary name servers for this zone.
4. Configure the following zone settings as appropriate:
— Specifying a Primary Server on page 262
— Specifying a Secondary Server on page 263
— Specifying TTL Settings on page 314
— Allowing Zone Transfers for a Zone on page 326
— Allowing Query Access for a Zone on page 327
— Enabling the DNS Server to Receive Updates on page 413
5. Click the Save and Restart Services icons.
Enabling an RFC 2317 Prefix
RFC 2317, Classless IN-ADDR.ARPA delegation is an IETF (Internet Engineering Task Force) document that describes a
method of delegating parts of the DNS IPv4 reverse-mapping tree that correspond to subnets smaller than 24 bits in
size; that is, from 25 to 31 bits. The DNS IPv4 reverse-mapping tree has nodes broken at octet boundaries of IP
addresses, which correspond to the old classful network masks. This means that IPv4 reverse-mapping zones (and
hence, delegation points) fall on /8, /16, or /24 boundaries.
With the proliferation of CIDR (Classless Inter-Domain Routing) support for routing, ISPs no longer assign entire Class
C networks to customers that only need a handful of IPv4 addresses. In general, IPv4 address assignments no longer
fall on nice, classful boundaries. For DNS, a problem comes into play when an ISP gives a customer an address range
that is smaller than a Class C, but that customer also wants to be delegated the DNS reverse-mapping zone.
The Infoblox device handles mapping a 24-bit network. If the ISP gives you, for example, a subnet with a 25-bit mask,
then you only have half of the Class C address range. If you configure your DNS server to be authoritative for the zone
corresponding to a 24-bit subnet, the DNS server cannot resolve half of the possible reverse-mapping records in the
zone. RFC 2317 defines an approach, considered a best practice, which addresses this issue.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
267
Managing DNS Data
Note: Before enabling RFC 2317 support for zones, disable forwarders for that zone, especially when any sort of
delegation (including RFC 2317) is being used. If you do not, reverse lookups may fail. For more information,
contact Infoblox Support for the Tech Note on RFC 2317 delegation.
To enable RFC 2317 support:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> IPv4
Reverse-Mapping Zones -> Edit -> Add Reverse Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, click Authoritative Zone Properties.
3. Specify the following information:
— Network Address: Enter the network IP Address for the address space for which you want to define the
reverse-mapping zone, and select a Subnet mask from the drop-down menu.
— Comment: Enter a descriptive comment about the zone.
— RFC 2317 Prefix: Enter a prefix in the text field. Prefixes can be alphanumeric characters, without blank
spaces.
— NS Group: Select a group from the drop-down menu, to apply a previously defined name server group to
provide the primary and secondary name servers for this zone. This option is for authoritative zones only.
4. For other zone configuration options, see Creating an Authoritative Reverse-Mapping Zone on page 266.
5. Click the Save and Restart Services icons.
Adding an Authoritative Subzone
After creating one zone you can add more zones at the same level, or add subordinate zones (or subzones). The
subzones can be authoritative, delegated, forward, or stub. For simplicity, the zones created in this section are
authoritative (as are all zones by default). For information about configuring the other zone types, see Configuring
Delegated, Forward, and Stub Zones on page 275.
You create an authoritative zone when you delegate authority for all the resource records of a particular domain to
one or more name servers. You create a subzone when you delegate authority for all the resource records of a
subdomain to name servers. The name servers can be the same as, or different from, the name servers that serve
resource records for the parent domain.
The distinction between domains and zones is that domains provide a logical structure to the DNS name space while
zones provide an administrative structure. The distinction between domains and subdomains and zones and
subzones is that the terms subdomains and subzones reference their relationship to a parent domain or zone. With
the exception of the root domain and root zone, all domains are subdomains and all zones are subzones.
You can organize a domain based on logical divisions such as type (.com, .gov, .edu; or sales, eng, sup) or location
(.uk, .jp, .us; or hq, east, west). Figure 10.6 on page 269 shows one way to organize the external (public) name space
and the internal (private) name space for a corporation with the domain name corp100.com. The external name space
follows standard DNS conventions. Internally, you create an individual subdomain and corresponding subzone for
each department.
268
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring Authoritative Zones
Figure 10.6 Domains and Subdomains, and Forward-Mapping Zones and Subzones
The DNS name space is logically
structured into domains and subdomains.
“ . “ = root domain
The DNS name space is administratively
structured into zones and subzones.
.
top-level domain “com”
(subdomain of “ . “)
“ . “ (root) name server
com
domain “corp100“
(subdomain of “com”)
“com” name server
corp100
name server for
“corp100.com” ,
“sales.corp100.com” ,
and
“eng.corp100.com”
“sales”, “eng”, and “sup” (subdomains of “corp100“ )
sales
eng
sup
sales.corp100.com.
eng.corp100.com.
sup.corp100.com.
name server for
“sup.corp100.com”
Note: Throughout this documentation, the trailing dot indicating the root zone is not shown, although its presence
is assumed.
For example, if you add subzones named engineering, hr, marketing, sales, and support subzones to a parent zone
named infoblox.com, the zone structure would resemble that of the following illustration.
Subzones
To add an authoritative subzone:
1. From the DNS perspective, click Infoblox Views -> view -> Forward-Mapping Zones -> zone -> Edit -> Add Forward
Mapping Zone -> Authoritative.
2. In the Add Authoritative Forward Zone editor, click Authoritative Zone Properties.
3. Enter a name for the zone.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
269
Managing DNS Data
4. Define primary and secondary name servers. For more information, see Specifying a Primary Server on page 262
and Specifying a Secondary Server on page 263.
5. To add other subzones under the same parent zone, repeat steps 1 through 4.
6. Click the Save and Restart Services icons.
Note: To learn how to modify, remove, or disable a zone, refer to Managing Zones on page 286.
Creating a Root Zone
The Infoblox device allows you to create an internal root zone for your organization. When the device receives a query
for DNS data that is not in its cache or authoritative data, it can query an internal root server after querying any
specified forwarders.
If the device does not receive a response from the forwarders, it sends the query to the specified internal root name
server. If you do not specify an internal root server and the device can access the Internet, it queries the Internet root
servers.
To create an internal root zone, do NOT enter any text in the Name field. You must specify a host for the root zone—
either a grid member or a DNS server that is external to the grid. Once created, the root zone automatically becomes
the parent of all the zones under the root zone.
To create a root zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
Zones -> Edit -> Add Forward-Mapping Zone -> Authoritative.
2. In the Add Authoritative Forward Zone editor, click Authoritative Zone Properties. Leave the Name field blank, and
enter a Comment to uniquely identify the zone.
3. Click Primary Server Assignment, and then click Select Member.
4. Select a grid member from the list (to be the primary name server), and then click OK.
— If you have not yet added members to this grid, see Adding an HA Member on page 221 or Adding a Single
Member on page 220.
— To specify an external primary name server, see Specifying a Primary Server on page 262.
5. Click the Save and Restart Services icons.
270
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Importing Zone Data
Importing Zone Data
Importing zone information alleviates having to manually enter data through the Infoblox GUI. You can import data
from existing name servers that run DNS implementations, as well as from Infoblox devices running 3.1r4 version
software or later. You can import existing zone data in the following ways:
•
Create a new zone
•
Modify an existing zone
The device imports the data through a zone transfer, so the name server you retrieve existing zone data from must be
authoritative for the zone data being imported. You must also configure the name server to allow zone transfers to
the IP address of the device to which the data will be imported. You can only import one zone (and its subzones) at
a time.
For the remainder of this section, the name server that stores the existing zone data (that will be imported) is referred
to as the source name server (regardless of whether it is a 3rd-party server or another Infoblox device). The device
that receives the zone data is referred to as the destination device. The following illustration shows the import zone
data process.
Figure 10.7 Importing Zone Data Process
1
Use the management system to
allow zone transfers on the source
DNS server to the Infoblox device
IP address (10.1.1.5)
Management
System
(10.1.1.3)
2 Log in to the device and
specify the IP address of the
source DNS server when you
create or modify a zone.
Infoblox
device
(10.1.1.5)
Login
3 The device sends a request to
import the specified zone data from
the source DNS server at 1.1.1.5.
Source DNS
Server
(1.1.1.5)
4 The source DNS server sends the
specified zone(s) data listed in the
zone file to the device.
zone data
The source name server must allow zone transfers to the destination device. For this to happen, you must modify the
allow-transfer substatement to include the IP address of the destination device prior to importing the data. This
section does not address how to change BIND substatements, but does explain how to configure zone transfers on
an Infoblox device running v3.1 software or later.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
271
Managing DNS Data
Zone data can be imported to both independent and grid deployed devices. If the destination device(s) consists of
an HA pair (like a grid master) using the VIP (virtual IP) address shared by the HA pair. For an independent device, use
the IP address.
If the source server uses BIND views, and the destination device is running v3.2 software (with Infoblox views), enter
the IP or VIP of the destination device(s) in the Import Zone From field to add the imported zone to the appropriate
view. Otherwise, the device imports all zones to the default view.
Importing Data into a New Zone
When you create a new zone and import zone data, the zone you import retains all records except for the NS (and A
records matching that NS record) and SOA records. The NS and SOA records are auto-created when a destination
device is specified as the primary or secondary name server for the new zone. If the imported zone has extra NS
records, they are rewritten to specify the source server as an external secondary. For more information on how specific
zones and records are imported, refer to Table 10.2 on page 250.
The device only imports subzones directly under the zone being imported, and creates a delegated NS record for
those subzones (to the source name server). No other subzone records or second-level subzones are imported.
Figure 10.8 illustrates the process for adding records to a new zone.
Figure 10.8 Importing Zone Records
tative
Authori
.com
0
0
1
rp
co
100.com
ns1.corp
rd
o
c
NS Re
2.088
10.34.2
rd
o
c
e
R
A
2.123
10.34.2
rd
o
c
e
R
Host
ary
Second
100.com
hq.corp
100.com
ns2.corp
ord
NS Rec
Create a new
1 corp100.com zone
in GUI.
2 Enter the IP address of the source
server (1.1.1.5) where the
corp100.com zone data is stored.
Source
Name Server
10.1.1.5
Device requests zone transfer for
10.1.1.3
Management
System
3 corp100.com data...
1.1.1.5
Destination
device
...and the server sends back all
zone data for corp100.com (if the
source server allows transfers to
the IP address of the device).
Device imports the existing A, CNAME,
4 DNAME, SRV, TXT, MX,
PTR, host, and bulk host records
for corp100.com, but creates the
destination server NS and SOA records.
All subzone data under corp100.com,
like hq.corp100.com, are added as
delegated zones. Subzone records are
not imported.
272
Infoblox Administrator Guide (Rev. A)
0.com
corp10
ord
NS Rec
rd
A Reco
cord
Host Re
100.com
hq.corp
corp100.com
zone data
tative
Authori
z
ated by
Auto-cre
2.088
10.34.2
2.123
10.34.2
ted
Delega
NIOS 4.1r3
Importing Zone Data
Importing Data into an Existing Zone
When you modify an existing zone on the destination device by importing zone data from a source server, the GUI
only retains the NS and SOA records automatically created when the zone was originally added. All DNS records on
the destination device, as well as host and bulk host records, for a zone are deleted and replaced by the imported
records of the same type. If there are no replicas, the destination device records are retained. If the imported zone
has extra NS records, those records change to designate the source server as an external secondary. For more
information on how specific zones and records are imported, refer to Table 10.2 on page 250.
The device imports first-level subzones, but delegates the subzones of the imported zone to the source name server.
The first-level subzone records are not imported. Second-level subzones, meaning subzones under another subzone,
are not imported. Figure 10.9 illustrates the process of zone data being added to an existing zone.
Figure 10.9 Importing Zone Data
0.com
corp20
ord
NS Rec
rd
A Reco
om
rp200.c
o
.c
hq
om
rp200.c
sv.hq.co
1 Modify the
corp200.com zone
in the GUI.
2
tative
Authori
rp100.c
old1.co
0.45
10.34.2
er
Forward
Stub
Enter the IP address of the
source server (1.1.1.5) where the
corp200.com zone data is stored.
Source
Name Server
10.1.1.5
3 Device requests zone transfer for
10.1.1.3
Management
System
corp200.com data...
Destination
device
1.1.1.5
...and the server sends back all
zone data for corp200.com (if the
source server allows transfers to
the IP address of the device).
4 Device replaces existing zone data
for corp200.com on the device with
the imported zone data, but retains
the destination server NS and SOA
records.
All subzone data under corp200.com,
like hq.corp200.com, are added as
delegated zones. Only first level
subzones are imported, but not their
records. All existing subzones that
are not duplicates of imported
subzones, like it.corp200.com,
remain as they originally were.
0.com
corp20
ord
NS Rec
rd
A Reco
om
rp200.c
o
.c
hq
00.com
IT.corp2
corp200.com
zone data
tative
Authori
100.com
ns1.corp
0.45
10.34.2
ted
Delega
ary
Second
2nd-level and subsequent subzones
and their records are not imported.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
273
Managing DNS Data
Allowing Zone Transfers for a Device
This section explains how to allow zone transfers to an Infoblox device. If the source name server uses a BIND
implementation, refer to the O’Reilly® DNS and BIND (or other industry reference) book for information on how to
change the allow-transfer substatements for the source name server.
Allowing Zone Transfers and Queries
Specifying zone transfers and queries allows the destination device access to the zone data being imported. This
procedure must be performed before attempting to import zone data (to a destination device).
You can specify whether zone transfers are allowed to a single address or a network. The difference between the two
is simple: use an IP address if to designate a single system, use the network option to use a range of addresses on a
network.
To allow zone transfers and queries, perform the following steps on the source device:
1. From the DNS perspective, click the DNS Members tab -> + (for grid) -> member -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Zone Transfers.
3. Click the Override Grid Settings check box.
4. Click Add and do the following:
— IP Address: Select and enter a system IP address.
— Network: Select and enter a network IP Address and select a Subnet mask from the drop-down menu.
— Allow: Select to allow zone transfers.
— Deny: Select to restrict permissions for zone transfers.
5. Click OK.
6. Click the Save and Restart Services icons.
Importing Data into Zone
When you create a new authoritative zone, or any time there after, you can import data from another server. When
you import zone data into an existing zone, the local device retains only the NS and SOA resource records for that
zone and replaces all other records—A, PTR, MX, TXT, SRV, CNAME, DNAME, host, and bulk host. The local device also
retains subzones and records in the subzones that exist locally.
Note: When the local server successfully imports the zone data, a Confirmation message appears. If the local server
cannot import the zone data, an Error message appears, recommending that you verify the correctness of the
IP address of the remote server and zone information.
To import data into a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit ->
Authoritative Zone Properties.
2. In the Authoritative Zone Properties editor, click Settings.
3. Click the Import Zone from check box, and specify the following:
— The IP address of the name server from which you want to import data.
— Optional: Click the Automatically create Infoblox host records from A records check box.
4. Click the Save and Restart Services icons.
How Specific Zones and Records Are Imported
The following table explains how an Infoblox device imports each type of zone and record.
274
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring Delegated, Forward, and Stub Zones
Table 10.3 The Resource Records and Subzones
If the source name
server for
the imported
authoritative
zone is a:
then the destination name server imports the following:
authoritative
zone resource
records
authoritative, forward, or
delegated subzones redefined
as delegated subzones
stub subzone
subzone
resource
records
primary server,
secondary server,
If you import data directly from an authoritative zone or subzone, the destination server imports the resource records
for the imported zone. If you import data from a zone that contains an authoritative subzone, the destination server
imports the subzone—and redefines it as a delegated zone—but does not import the resource records for that
subzone. To import those records, change the imported subzone type from delegated to authoritative (on the
destination server), and then directly import the records for that zone.
Configuring Delegated, Forward, and Stub Zones
In addition to authoritative zones, the Infoblox device allows you to configure delegated, forward, and stub zones. A
delegated zone is a zone managed by (delegated to) someone else, who owns the authority for the zone. A forward
zone is where queries are sent before being forwarded to primary name servers. A stub zone contains records that
identify the authoritative name servers in another zone. This section covers the following topics:
•
•
•
Configuring a Delegated Zone on page 275
Configuring a Forward Zone on page 276
Configuring Stub Zones on page 278
Configuring a Delegated Zone
Delegated zone data is maintained with remote name servers (that the local server knows), instead of on the local
name server. When the local name server receives a query for a delegated zone, it either responds with the NS record
for the delegated zone server (if recursion is disabled on the local server) or it queries the delegated zone server on
behalf of the resolver (if recursion is enabled).
For example, there is a remote office with their own name servers, and you want them to manage their own local data.
On the name server at the main corporate office, you define the remote office zone as delegated, and then specify
the remote office name servers as authorities for that zone.
You can delegate a zone to one or more remote name servers, which are typically the authoritative primary and
secondary servers for that zone. If recursion is enabled on the local name server, it queries multiple delegated name
servers using a round-robin technique.
To create a delegated zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> + (for Forward-Mapping Zones, IPv4
Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add Forward Mapping Zone ->
Delegated.
2. In the Add Forward Mapping Delegated Zone editor, click Delegated Zone Properties.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
275
Managing DNS Data
3. Specify the following information:
—
Name: Enter the domain name of the delegated zone.
Note: You do not need to enter an FQDN (fully qualified domain name). The Infoblox device appends the
delegated zone name to the name of its parent zone.
— Comment: Enter a distinguishing comment.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
4. Click Delegated Servers.
5. In the Delegated Servers editor, click Add, specify the following information, and then click OK:
— Server Name: Enter the name of a remote name server to which you want the local server to redirect queries
for data for this zone.
— Server Address: Enter the IP address of the delegated server.
6. Optional: Repeat the previous step to define multiple delegated servers.
You can define multiple delegated servers, such as the primary and secondary servers that serve DNS data for
that zone.
7. Click the Save and Restart Services icons.
For information about modifying, removing, or disabling zones, refer to Managing Zones on page 286.
Configuring a Forward Zone
When you want to forward queries for data in a particular zone, you can define that zone as a forward zone and specify
a name server that can resolve queries for that zone. For example, you might define a forward zone so that the
Infoblox device forwards queries about a partner’s internal site to a name server that partner hosts and which is
configured just for other partners to access.
Note that the use of a forward zone is different from that of a forwarder. (A forwarder is a name server that performs
recursive lookups on behalf of the name servers that forward queries to it. For more information, see Using
Forwarders with a Grid on page 322.) An Infoblox device forwards queries to the name server of a forward zone
because that name server can resolve queries for that zone. An Infoblox device forwards queries to a forwarder
regardless of zones.
To configure a forward zone for a forward-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Forward-Mapping Zone -> Forward.
2. Enter the following information:
Forward Zone Properties
— Name: Enter the domain name for which you want the Infoblox device to forward queries.
— Comment: Enter a descriptive comment.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
Forwarders
— For Forwarders, click Add, specify the following information, and then click OK.
— Forwarder Name: Enter a domain name for the server to which you want the Infoblox device to forward
queries for the specified domain name.
— Forwarder Address: Enter the IP address of the server to which you want the Infoblox device to forward
queries.
276
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring Delegated, Forward, and Stub Zones
— In the Forwarding Servers section, click Add, select the Infoblox device from which you want to forward
queries, and then click OK. For an independent deployment, select the local device (it is the only choice).
For a grid, you can select one or more grid members.
3. Click the Save and Restart Services icons.
To configure a forward zone for an IPv4 reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for IPv4
Reverse-Mapping Zones) -> zone -> Edit -> Add IPv4 Reverse-Mapping Zone -> Forward.
2. Enter the following:
Forward Zone Properties
— Network Address: Enter the 32-bit IPv4 address for which you want the Infoblox device to forward queries.
— Subnet Mask: Choose the subnet mask that defines the IPv4 network address space.
— Comment: Enter a descriptive comment.
— RFC 2317 Prefix: Use this field when the subnet mask is greater than 24 bits; that is, for a mask between 25
and 31 bits. Enter a prefix, such as the name of the allocated address block. The prefix can be
alphanumeric characters, without blank spaces; for example: 128/26 , 128-189 , or sub-B . For more
information, see Enabling an RFC 2317 Prefix.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
Forwarders
— For Forwarders, click Add, specify the following information, and then click OK:
— Forwarder Name: Enter a domain name for the DNS server to which you want the Infoblox device to
forward queries.
— Forwarder Address: Enter the IP address of the server to which you want the Infoblox device to forward
queries.
— In the Forwarding Servers section, click Add, select the Infoblox device that you want to forward queries for
the defined address space, and then click OK. For an independent deployment, select the local device (it is
the only choice). For a grid, you can select one or more grid members to forward queries.
3. Click the Save and Restart Services icons.
To configure a forward zone for an IPv6 reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for IPv6
Reverse-Mapping Zones) -> zone -> Edit -> Add IPv6 Reverse-Mapping Zone -> Forward.
Forward Zone Properties
— IPv6 Network Address: Enter the 128-bit IPv6 address for which you want the Infoblox device to forward all
queries. The format of an IPv6 address is eight groups of up to four hexadecimal digits, each group
separated by a colon. Example: 2006:0000:0123:4567:89ab:cdef:0000:0123.
— Network Prefix: Choose the network prefix that defines the IPv6 network address space.
— Comment: Enter a descriptive comment.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
Forwarders
— For Forwarders, click Add, specify the following information, and then click OK.
— For Forwarders, click Add, specify the following information, and then click OK:
— Forwarder Name: Enter a domain name for the DNS server to which you want the Infoblox device to
forward queries.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
277
Managing DNS Data
— Forwarder Address: Enter the IP address of the server to which you want the Infoblox device to forward
queries.
— In the Forwarding Servers section, click Add, select the Infoblox device that you want to forward queries for
the defined address space, and then click OK. For an independent deployment, select the local device (it is
the only choice). For a grid, you can select one or more grid members to forward queries.
2. Click the Save and Restart Services icons.
Configuring Stub Zones
A stub zone contains records that identify the authoritative name servers in that zone. It does not contain resource
records for resolving IP addresses to hosts in that zone. Instead, it contains the following records:
•
SOA (Start of Authority) record of the zone
•
NS (name server) records at the apex of the stub zone
•
A (Address) records that map the name servers to their IP addresses
When a name server hosting a stub zone receives a query for a domain name that it determines is in the stub zone,
the name server uses the records in the stub zone to locate the correct name server to query, eliminating the need to
query the root server.
Stub zones, like secondary zones, obtain their records from other name servers. Their records are read only, therefore
administrators do not manually add, remove, or modify the records.
Stub zone records are also periodically refreshed, just like secondary zone records. Secondary name servers, though,
contain a complete copy of the zone data that is on the primary server. Therefore, zone transfers from a primary server
to a secondary server, or between secondary servers, can increase CPU usage and consume excessive bandwidth. A
name server hosting a stub zone maintains a much smaller set of records; therefore updates are less CPU intensive,
consuming less bandwidth.
Figure 10.10 and Figure 10.11 illustrate how the Infoblox device resolves a query for a domain name for which it is
not authoritative. Figure 10.10 illustrates how the device resolves a query when it does not have a stub zone.
Figure 10.11 illustrates how the device resolves the query with a stub zone.
In Figure 10.10, a client sends a query for ftp.sales.corp200.com to the Infoblox device. When the device receives the
request from the client, it checks if it has the data to resolve the query. When the device determines it does not have
the data, it tries to locate the authoritative name server for the requested domain name. It sends nonrecursive
queries to a root name server and to the closest known name servers until it learns the correct authoritative name
server to query.
278
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring Delegated, Forward, and Stub Zones
Figure 10.10 Processing a Query without a Stub Zone
“ . “ (root)
1 Client sends a query
for ftp.sales.corp200
.com to the Infoblox
device.
Client
2 The device
3 The device sends a
determines it
does not have
the record to
resolve the
query.
query to a root server.
...which responds with a referral
to the .com servers.
.com
4 The device sends a query to a
.com server...
...which responds with a referral
to the corp200.com servers.
7 The device
responds to the
client with the
requested data
corp200.com
Infoblox Device
5
The device sends a query
to a corp200.com server...
...which responds with a
referral to the
sales.corp200.com servers.
sales.corp200.com
6 The device sends a query to a
sales.corp200.com server.
The sales.corp200.com server
checks its resource records
and responds with the
requested data.
Resource
Records
In Figure 10.11, when the Infoblox device receives the request for the domain name in corp200.com, it determines it
does not have the resource records to resolve the query. It does, however, have a list of the authoritative name
servers in the stub zone, corp200.com. The device then sends a query directly to the name server in corp200.com.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
279
Managing DNS Data
Figure 10.11 Processing a Query with a Stub Zone
“ . “ (root)
1 Client sends query for
ftp.sales.corp200.com
to the Infoblox device.
2 The device has a
corp200.com
stub zone.
Client
.com
Stub Zone
Configuration
corp200.com
5 The device
responds to the
client with the
requested data.
Infoblox Device
3 The device send a query directly
to a corp200.com server...
... which respond with a referral to
the sales.corp200.com servers.
sales.corp200.com
4 The device send a query to a
sales.corp200.com server.
The sales.corp200.com
server checks its resource
records and responds with
the requested data.
Resource
Records
Stub zones facilitate name resolution and alleviate name server traffic in your network. For example the client in the
previous examples is in corp100.com. The corp100.com and corp200.com zones are partners, and send all their
communications through a VPN tunnel, as shown in Figure 10.12 on page 280. The firewall protecting corp100.com
is configured to send all messages for the 10.2.2.0/24 network through the VPN tunnel. Infoblox_A hosts the stub
zone for corp200.com. Therefore, when the host in corp100.com sends a query for ftp.sales.corp200.com, Infoblox_A
obtains the IP address of Infoblox_B (10.2.2.7) from its stub zone records and sends the query to the firewall
protecting corp100.com.
Because the destination of the query is in the 10.2.2.0/24 network, the firewall (configured to encrypt all traffic to
that network) sends the request through a VPN tunnel to Infoblox_B. Infoblox_B resolves the query and sends back
the response through the VPN tunnel. All name server traffic went through the VPN tunnel to the internal servers,
bypassing the root servers and external name servers.
Figure 10.12 Stub Zone Configuration
corp100.com
Host
280
Infoblox_A
10.1.1.3
Infoblox Administrator Guide (Rev. A)
corp200.com
Infoblox_B
10.1.1.3
sales.corp200.com
NIOS 4.1r3
Configuring Delegated, Forward, and Stub Zones
In parent-child zone configurations, using stub zones also eases the administration of name servers in both zones.
For example, as shown in Figure 10.12, sales.corp200.com is a child zone of corp200.com. On the corp200.com
name servers, you can create either a delegated zone or a stub zone for sales.corp200.com.
When you create a delegated zone, you must first specify the name servers in the delegated zone and manually
maintain information about these name servers. For example, if the administrator in sales.corp200.com changes the
IP address of a name server or adds a new name server, the sales.corp100.com administrator must inform the
corp200.com administrator to make the corresponding changes in the delegated zone records.
If, instead, you create a stub zone for sales.corp200.com, you set up the stub zone records once, and updates are
then done automatically. The name servers in corp200.com that are hosting a stub zone for sales.corp200.com
automatically obtain updates of the authoritative name servers in the child zone.
In addition, a name server that hosts a stub zone can cache the responses it receives. Therefore, when it receives a
request for the same resource record, it can send the answer back without having to query another name server.
Creating a Stub Zone
When you create a stub zone on the Infoblox device, you specify the following:
•
The grid member that is hosting the stub zone
You can specify multiple devices if you want the stub zones on multiple name servers. If you do, the devices
store identical records about the stub zone.
•
The IP address of the primary server(s) that the Infoblox device can query in the stub zone
If you specify multiple primary servers, the device queries the primary servers, starting with the first server on
the list.
After you create a stub zone, the Infoblox device does the following:
•
First, it sends a query to the primary server for the SOA (Start of Authority) record of the stub zone.
The primary server returns the SOA record.
•
Then, it sends a query for the NS (name server) records in the zone.
The primary server returns the NS records and the A (address) records of the name servers. (These A records are
also called glue records)
After this process is complete, the device has all the records it needs to identify the authoritative servers in the stub
zone.
Maintaining a Stub Zone
The Infoblox device maintains the stub zone records, and updates them based on the values in the SOA record as
follows:
•
The refresh interval indicates when the device sends a discrete query to the primary name server in the stub
zone. The device learns about any changes in the stub zone and updates the NS and A records in the stub zone
accordingly.
•
If the update fails, the retry interval indicates when the device resends a discrete query.
•
If the query continues to fail, the expiry value indicates when the device stops using the zone data.
Configuring a Stub Zone
To configure a stub zone, you must identify the device that hosts the stub zone, and provide the IP address of the
primary server. You can configure a stub zone for forward mapping or reverse mapping zones.
To configure a stub zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add
Forward-Mapping Zone, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones -> Stub.
2. In the Add Stub Zone editor, click Stub Zone Properties and enter the following information:
— Name: Enter a name for the stub zone.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
281
Managing DNS Data
— Comment: Enter a useful comment, such as the admin to contact for the stub zone.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
3. Click Stub Server Assignment.
4. In the Grid Members section, click Add.
5. In the Stub Zone Member Server Item dialog select the grid member(s) hosting the stub zone, and then click OK.
6. In the External Primaries section, click Add.
7. In the Stub External Primary Item dialog, enter the Name and IP Address of the primary server in the stub zone,
and then click OK.
You can specify multiple primary servers for redundancy. If the external primary server is an Infoblox device, that
device must have the Minimal Response feature turned off so it can propagate the data to the stub server. For
information about the Minimal Response feature, see Specifying Minimal Response Returns on page 323.
8. Optional: Click the Disable Forwarding check box to indicate that the name servers hosting the stub zone should
not forward queries that end with the domain name of the stub zone to any configured forwarders.
9. Click the Save and Restart Services icons.
Viewing SOA Records
The timer values in the SOA record determines when the stub zone records are updated. A zone contains one SOA
record that accounts for the following properties for the zone:
•
Name of the primary DNS server—The domain name for the primary DNS server for the zone. The zone should
contain a matching NS record.
•
E-mail address of the responsible person—The e-mail address of the person responsible for maintaining the
zone.
•
Serial number—The number used by secondary DNS servers to check if the zone has changed. If the serial
number is higher than what the secondary server currently has, a zone transfer is initiated. This number is
automatically increased when changes are made to the zone or its record.
•
Refresh interval—The time lapse between checks the secondary server makes for changes to the zone.
•
Retry interval—The time lapse after which the secondary server checks for changes if the first refresh fails.
•
Expire interval—The time period the zone remains valid after a successful refresh.
•
Minimum TTL—The default TTL for new records created within the zone.
To view zone SOA record values:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Authoritative
Zone Properties.
2. In the Forward Authoritative Zone editor, click Settings.
3. Click Override grid settings, and specify the following:
— Refresh every: The interval at which the Infoblox device sends a discrete query to the primary name server
in the stub zone.
— Retry every: The interval at which the device retries sending a discrete query to the primary name server.
— Expires after: Specifies when the device should stop using the zone data if it is unable to refresh the data.
— Default TTL: Specifies how long a name server can cache the record.
— Negative TTL: Specifies how long a name server caches negative responses from name servers authoritative
for the zone.
— Set primary for SOA: Enter the primary server for the zone.
— Increment serial number by: Click this check box and enter an incremental value in the text box that
appears. The Serial number option is disabled (grayed out) when this check box is selected.
282
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Name Server Groups
— Serial numbers: Enter a serial numbers for the zone data file.
— Email Address: Enter the e-mail address of the contact for the zone.
— Import zone data from: To import data from another zone, click this check box and specify the following:
•
Enter the FQDN (fully qualified domain name) of a zone from which you want to import data.
•
Optional: Click the Automatic reverse mapping during import check box.
— Disable forwarding: Click this check box to disable the forwarding function.
4. Click the Save and Restart Services icons.
Using Name Server Groups
A name server group is a collection of one primary DNS server and one or more secondary DNS servers. Grouping a
commonly used set of primary and secondary DNS servers together simplifies zone creation, allowing you to specify
a single name server group instead of specifying multiple name servers individually.
Creating a Name Server Group
To create a name server group:
1. From the DNS perspective, click the DNS Members tab -> member -> Edit -> Grid or Device DNS Properties.
2. In the Grid or Device DNS Properties editor, click Name Server Groups.
3. In the Name Server Groups section, click Add, enter the following information, and then click OK:
— Name Server Group Name: Type a name that provides a meaningful reference for this set of servers.
— Grid Primary: To create a name server group for a grid with the primary name server as a member of the grid,
click Select Member, choose the member from the Select Grid Member dialog list, and then click OK.
— Stealth: To hide the NS record for the primary name server from DNS queries, select this check box. The
Infoblox device does not create an NS record for the primary name server in the zone data. To display the NS
record for the primary name server in responses to queries, clear the check box.
— Use external primaries: If you are not using a grid or you want the primary name server to be a device
outside a grid, select Use external primaries, click Add, specify the following information, and click OK:
— Name: Type the FQDN (fully qualified domain name) of the primary name server.
— IP Address: Type the IP address of the name server. If the external primary name server is behind a NAT
device, use the NAT address, not its interface address.
— Use TSIG: To authenticate zone transfers using a TSIG (transaction signature), select check box.
Infoblox TSIGs use HMAC-MD5 hashes. These are keyed one-way hashes for message authentication
codes using the Message Digest 5 algorithm. (For details, see RFC 1321, The MD5 Message-Digest
Algorithm, and RFC 2104, HMAC: Keyed-Hashing for Message Authentication.)
•
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as
that of the TSIG key on other DNS devices with which you intend to send and receive
TSIG-authenticated messages
•
Key: Type or paste a previously generated key. This key must be present on other DNS devices with
which you intend to send and receive TSIG-authenticated messages.
You can generate a TSIG key in the TSIG Key dialog box (accessed from the Zone Transfers section), or
you can obtain the TSIG key name and key from the external name server, either by accessing the device
yourself or by requesting the device administrator to deliver them to you through some out-of-band
mechanism. Then type or copy-and-paste that name and key into these fields.
To send DNS messages without TSIG authentication, clear the Use TSIG check box.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
283
Managing DNS Data
— Use DNS One 2.x TSIG: If you want to use TSIG authentication and the external primary name server is
running DNS One 2.x code, select check box. The Infoblox device generates the required TSIG key to use
when authenticating DNS messages to and from devices running DNS One 2.x code. If the external
primary name server is not running DNS One 2.x, clear the check box.
— Stealth: To hide the NS record for the primary name server from DNS queries, select this check box. The
Infoblox device does not create an NS record for the primary name server in the zone data. To display
the NS record for the primary name server in responses to queries, clear the check box.
— Grid Secondaries: If you are creating a name server group for a grid and you want to use a grid member as a
secondary name server, click Add, enter the following information in the Name Server Group Member
Secondary dialog box, and click OK.
— Click Select member, select a member from the list in the Select Grid Member dialog box, and click OK.
— Stealth: To hide the NS record for the secondary name server from DNS queries, select this check box.
The Infoblox device does not create an NS record for the secondary name server in the zone data. To
display the NS record for the secondary name server in responses to queries, clear the check box.
— Lead Secondary: Select if the primary name server is outside the grid, and you want the chosen
secondary name server to forward zone transfers it receives from the primary to other secondary name
servers, which can be either inside the grid or outside it.
— Update zones using—Select one of the following options:
•
Grid replication (recommended): Select this check box if the primary and secondary servers are
grid members and they use database replication for zone updates.
•
DNS zone transfers: Select this check box if the primary and secondary servers use zone transfers
for zone updates.
— External Secondaries: If you are not using a grid or you want to add a secondary name server that is not part
of a grid, click Add, specify the following, and then click OK:
— Name: Type the FQDN (Fully Qualified Domain Name) of the secondary name server.
— IP Address: Type in the IP Address for the secondary name server.
— Use TSIG: To authenticate zone transfers using a TSIG (transaction signature), select this check box.
Infoblox TSIGs use HMAC-MD5 hashes. These are keyed one-way hashes for message authentication
codes using the Message Digest 5 algorithm. (For details, see RFC 1321, The MD5 Message-Digest
Algorithm, and RFC 2104, HMAC: Keyed-Hashing for Message Authentication.)
•
Key name: Type or paste the name of the TSIG key you want to use. This must be the same name as
that of the TSIG key on other DNS devices with which you intend to send and receive
TSIG-authenticated messages.
•
Key: Type or paste a previously generated key. This key must be present on other DNS devices with
which you intend to send and receive TSIG-authenticated messages.
You can generate a TSIG key in the TSIG Key dialog box (accessed from the Zone Transfers section), or
you can obtain the TSIG key name and key from the external name server, either by accessing the device
yourself or by requesting the device administrator to deliver them to you through some out-of-band
mechanism; then type or copy-and-paste that name and key into these fields.
To send DNS messages without TSIG authentication, clear the Use TSIG check box.
— Use DNS One 2.x TSIG: If you want to use TSIG authentication and the external secondary name server
is running DNS One 2.x code, select this check box. The Infoblox device generates the required TSIG key
to use when authenticating DNS messages to and from devices running DNS One 2.x code. If the
external primary name server is not running DNS One 2.x, clear the check box.
— Stealth: Click this check box to hide the NS record for the secondary name server from DNS queries. The
Infoblox device does not create an NS record for the secondary name server in the zone data. To display
the NS record for the secondary name server in responses to queries, clear check box.
4. Click the Save icon to apply the new name server group configuration. A newly created name server group
appears in the Default Name Server Group drop-down list only after you save the configuration.
284
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Name Server Groups
5. From the Default Name Server Group drop-down menu, select a name server group to be the default.
6. Click the Save and Restart Services icons.
Applying a Name Server Group
To specify a name server group when creating a forward-mapping zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> Forward-Mapping Zones -> Edit -> Add Forward
Mapping Zone -> Authoritative.
2. In the Add Forward Authoritative Zone editor, specify the following:
— Name: Enter the name of the forward-mapping zone.
— Comment: Enter a meaningful comment.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
— NS Group: From the drop-down list, select the group of name servers that you want to serve DNS for this
zone.
3. Click the Save and Restart Services icons.
To specify a name server group when creating an IPv4 reverse-mapping zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> IPv4 Reverse-Mapping Zones -> Edit -> Add IPv4
Reverse-Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, specify the following:
— Network Address: Enter the 32-bit IPv4 address for the reverse-mapping zone.
— Subnet Mask: Choose the subnet mask that defines the IPv4 network address space.
— Comment: Enter a descriptive comment.
— RFC 2317 Prefix: Use this field when the subnet mask is greater than 24 bits; that is, for a mask between 25
and 31 bits. Enter a prefix, such as the name of the allocated address block. The prefix can be
alphanumeric characters, without blank spaces; for example: 128/26 , 128-189 , or sub-B . For more
information, see Enabling an RFC 2317 Prefix.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
— NS Group: From the drop-down list, select the previously defined name server group that you want to serve
DNS for this zone.
3. Click the Save and Restart Services icons.
To specify a name server group when creating an IPv6 reverse-mapping zone:
1. From the DNS perspective, click Infoblox Views -> + (for view ) -> IPv6 Reverse-Mapping Zones -> Edit -> Add IPv6
Reverse-Mapping Zone -> Authoritative.
2. In the Add Authoritative Reverse Zone editor, specify the following:
— IPv6 Network Address: Enter the 128-bit IPv6 address for the reverse-mapping zone.
— Network Prefix: Choose the network prefix that defines the IPv6 network address space.
— Comment: Enter a descriptive comment.
— Disable this zone: Click this check box to temporarily disable this zone.
— Lock this zone: Click this check box to lock the zone so that you can make changes to it, and also prevent
others making conflicting changes.
— NS Group: From the drop-down list, select the previously defined name server group that you want to serve
DNS for this zone.
3. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
285
Managing DNS Data
Note: If you apply a name server group to at least one zone or specify it as the default group, you cannot rename or
remove it. To rename or remove a group, you must first disassociate it from all zones and unassign it as the
default group.
Managing Zones
The following sections describe how to edit, delete, enable, disable, lock, and unlock zones after you create them.
•
•
•
•
Locking and Unlocking Zones
Modifying Zones
Removing Zones
Enabling and Disabling Zones on page 289
Locking and Unlocking Zones
Administrators can lock a zone before changing its properties or records so that other administrators cannot make
conflicting changes. Administrators can select a zone, lock it, make changes, and then unlock it.
If you lock a zone and other administrators try to make changes to it, then the system displays a warning message
that the zone is locked by admin_name.
You can perform dynamic updates through mechanisms such as DDNS and nsupdate on a locked zone. The system
can also add auto-generated records such as glue A records and NS records to a locked zone. Locks on a zone do not
impact its child zones.
To lock a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) zone -> Edit -> Lock
Zone.
2. Click the Save and Restart Services icons.
You can also lock a zone using the zone editor as follows:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit
Properties.
2. In the Edit Zone Properties dialog box, select the check box Lock this zone.
A lock icon appears on the left panel next to the zone.
Only a superuser or the administrator who locked the zone can unlock it. Locks do not expire; you must manually
unlock a locked zone.
To unlock a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) zone -> Edit ->
Unlock Zone.
2. Click the Save and Restart Services icons.
You can also unlock a zone using the zone editor as follows:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit
Properties.
2. In the Edit Zone Properties dialog box, deselect the check box Lock this zone.
3. Click the Save and Restart Services icons.
A lock icon on the left panel next to the zone disappears indicating that the zone is unlocked.
286
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Zones
Modifying Zones
The Infoblox device allows you to modify existing zone settings. The one item you cannot change is the name.
To change the zone type or settings:
1. From the DNS perspective, click Infoblox Views -> view -> Forward Mapping Zone or Reverse Mapping Zone -> zone
-> Edit -> Authoritative Zone Properties.
2. Click Settings, and make the necessary changes.
3. Make other changes, as necessary. For more information, see Configuring Delegated, Forward, and Stub Zones
on page 275.
4. Click the Save and Restart Services icons.
Removing Zones
When you remove a zone, the Infoblox device removes the zone from the database, along with all resource records in
that zone. If a zone has subzones, you can choose to remove them and their resource records or “reparent” them to
the parent zone of the one you are removing. These two options are shown in Figure 10.13.
Figure 10.13 Removing or Reparenting Subzones
Remove Zone B and …
… remove its subzones.
or
… reparent its subzones.
Zone A
Zone A
Zone A
Zone B
Zone B
Zone B
Subzone C
Subzone C
Subzone C
The Infoblox device removes zone B,
subzone C, and all their resource
records.
The Infoblox device removes zone B and
its resource records. It reparents subzone
C to zone A. It creates a new NS record in
zone A for subzone C and possibly
changes admin privileges for subzone C.
If you choose to reparent the subzones, be aware of the following caveats and possible effects of the reparenting:
•
You cannot remove a zone and reparent its subzones if at least one of the subzones is a delegated zone. You
must first remove any delegated subzones, and then you can remove the zone and reparent its subzones.
•
If there are AD (Active Directory) subzones (_msdcs, _sites, _tcp, _udp, domaindnszones, foresetdnszones) and
you opt to remove the parent zone only, the Infoblox device reparents all subzones except the AD subzones,
which it removes regardless of the removal option you specify.
•
The subzone reparenting option is unavailable when you select multiple zones for removal.
•
When you remove a zone and reparent its subzones, any subzone that inherited its admin access settings from
its previous parent zone (as opposed to having specific access settings for that subzone) now receive their
settings from its new parent zone, which might be different. See Figure 10.14.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
287
Managing DNS Data
Figure 10.14 Changed Admin Access Settings after Reparenting Subzones
If you remove Zone B and …
… reparent its subzones …
Zone A
Read/Write
Zone A
Read/Write
Zone B
Deny
Zone B
Deny
Subzone C
Inherits “Deny”
Subzone C
Inherits
“Read/Write”
… the admin access settings for subzone C change because the privileges for its new parent
zone (zone A) are different from those of its previous parent zone (zone B).
Before you remove zone B, subzone C inherits a “Deny” admin access setting from zone B.
After the removal, subzone C inherits “Read/Write” access from its new parent zone, zone A.
Note that if you set a specific “Deny” admin access privilege for subzone C before removing its
parent zone (zone B), subzone C retains its specified “Deny” setting.
Note: Instead of removing a zone, you can also disable it. For more information, refer to Enabling and Disabling
Zones on page 289.
To remove a zone:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Remove zone.
2. In the Remove Zone confirmation box, enter the following:
— Remove Zone: Select the check box to confirm the removal of the zone.
Note: Because of the potentially large loss of data that can occur when you remove a zone, by default the
Infoblox appliance requires a double confirmation of its removal. To change the default behavior so that
a zone removal does not require you to confirm its removal twice, in the DNS perspective click the DNS
Members tab -> grid -> Edit -> Grid DNS Properties -> General, clear the Enable double confirm for zone
deletion check box, and then click the Save icon.
— Also remove all subzones: Select to remove the selected zone all its subzones and all the resource records
of the selected zone and its subzones.
— Remove zone only: Select to remove the zone and its resource records. The Infoblox appliance reparents all
subzones to the parent zone of the zone that you remove. Automatically created AD (Active Directory)
subzones are an exception. Even if you select Remove zone only, the Infoblox appliance still removes AD
subzones.
3. Click OK to execute the zone removal.
288
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Zones
Deleting Multiple Zones
Instead of deleting zones individually, you can select multiple zones and delete the entire selected group.
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones).
2. Select the zones you want to remove in one of the following ways:
— Select a contiguous set of zones, holding down the SHIFT key and clicking the zones.
— Select noncontiguous zones, holding down the CTRL key and clicking the zones.
Note: You cannot remove the first reverse mapping zone. If the first reverse mapping zone is one of your
selections, the Remove menu option is grayed out and unavailable.
3. Click Edit -> Remove.
A removal confirmation message appears.
4. To confirm the removal of the selected zones, select Remove zone, and then click OK.
5. Click the Save and Restart Services icons.
Enabling and Disabling Zones
The Infoblox device allows you to disable and enable existing zones, providing a viable option for removing them from
the database. This feature is especially helpful when you have to move or repair the server for a particular zone. When
you disable a zone, a red square appears next to the network listing in the tree view.
To disable a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit ->
Authoritative Zone Properties.
2. In the Forward (or Reverse) Authoritative Zone editor, click Disable. A check mark appears.
3. Click the Save and Restart Services icons.
Using the Recycle Bin
You can use the recycle bin feature on the Infoblox device to store deleted DNS configurations. Items contained in the
recycle bin can be restored to active configuration at a later time, or can be permanently removed from the device
database. If you do not use the recycle bin, the device deletes items permanently from the database. The recycle bin
is enabled by default on the Infoblox device.
You can use the recycle bin to restore DNS views and zones. NIOS does not support restoring deleted DNS resource
records.
This section discusses the following topics:
•
•
•
•
•
Disabling the Recycle Bin on page 290
Re-enabling the Recycle Bin on page 290
Viewing the Recycle Bin on page 290
Restoring Items in the Recycle Bin on page 290
Emptying the Recycle Bin on page 291
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
289
Managing DNS Data
Disabling the Recycle Bin
You can disable the recycle bin feature globally in the Grid perspective. If you disable the recycle bin, you cannot
restore nor empty the recycle bin. The recycle bin feature is enabled by default on the Infoblox device. If you do not
have superuser privileges, a warning appears prompting you to relogin as superuser before disabling the recycle bin.
To disable the recycle bin feature:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Enable Recycle Bin: Deselect the check box to turn off the recycle bin feature. If you do disable the recycle
bin feature, deleted items from the GUI are permanently removed and unrecoverable.
3. Click OK to save your changes.
Re-enabling the Recycle Bin
You must first enable the recycle bin globally in the Grid perspective. If you do not have superuser privileges, a
warning appears prompting you to relogin as superuser before enabling the recycle bin.
To enable the recycle bin feature for deleted DNS configuration items:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Enable Recycle Bin: Select the check box to enable the recycle bin feature. When you delete DNS
configuration items in the GUI for the grid member, the recycle bin stores the deleted items. Enabling the
recycle bin allows you to undo the deletions and to restore the deleted items on the device at a later time. If
you do not enable the recycle bin feature, deleted items from the GUI are permanently removed and
unrecoverable.
3. Click OK to save your changes.
Viewing the Recycle Bin
You can display the Recycle Bin panel and view all deleted items stored in the recycle bin. From the DNS perspective,
all deleted DNS items are shown if you have superuser privilege. If you are not a superuser, only the items deleted by
you are shown. By default, records are sorted by Name. To display the Recycle Bin panel and to view the deleted items
for DNS stored in the recycle bin:
1. From the DNS perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
2. Scroll through the Recycle Bin panel pages using the page arrows located on the lower-left corner of the Recycle
Bin panel. The panel page length is set by the administrator as discussed in Creating an Admin Account on page
56. The panel displays each item with the following information:
— Name: Name of the configuration item deleted.
— Object Type: Type of configuration deleted.
— Parent/Container: Where the item was deleted.
— Admin: Who deleted the item.
— Time: When the item was deleted.
Restoring Items in the Recycle Bin
You can restore any configuration items in the recycle bin displayed in the Recycle Bin panel. The restore functionality
is available only if the recycle bin is enabled, and if an item is selected in the panel. Deleted items are stored in the
recycle bin until the recycle bin is emptied.
To restore items from the Recycle Bin panel:
1. From the DNS perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
2. Select the configuration item you want to restore.
290
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Specifying Host Name Restrictions
3. Click Edit -> Restore Selected Object. A warning message appears prompting you to confirm that you wish to
continue with the restore.
4. Confirm that the item was restored into the GUI by viewing the configuration where the item was originally
removed, and by confirming that the item does not appear in the Recycle Bin panel any longer.
Emptying the Recycle Bin
You can empty the recycle bin, permanently removing all of the items displayed in the Recycle Bin panel from the
device database. The empty functionality is available only if the recycle bin is enabled, and only to superusers. To
empty the recycle bin:
1. From the DNS perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
2. Click Edit -> Empty Recycle Bin. A warning message appears prompting you to confirm that you wish to empty the
recycle bin.
3. Confirm that all items were removed from the Recycle Bin panel.
Specifying Host Name Restrictions
Use the host name restriction feature to enforce a naming policy for the host names of A, AAAA, Host, MX, and NS
records based on user-defined or default patterns.
Records that you created before you enabled the host name checking policy, need not comply with the host name
restriction that you specify.
You can select one of three preconfigured policies or define your own host naming policy with a POSIX regular
expression. The policies Infoblox provides implement standard host naming restrictions according to RFC 952 (“DOD
Internet Host Table Specification”) and RFC 1123 (“Requirements for Internet Hosts -- Application and Support”).
Note: The host name restriction limits the host name of A, AAAA, Host, MX, and NS records only.
You can specify (and override) host name templates at the grid, member, and zone level.
To specify host name restrictions for a grid:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Host Name Restrictions.
The Record Policies section lists the following default record policies:
— Allow Any: You can use any host name.
— Allow Underscore: You can only use host names with alphanumeric characters, dashes, and underscores
("-" and "_")
— Strict Hostname Checking: You can only use host names that contain alphanumeric characters and dashes
(“-’).
3. Click Add to define your own host name checking policy. The Record Template dialog box appears. Enter a record
policy name and a regular expression string, and click OK. See Appendix B, "Regular Expressions", on page 505
for definitions of regular expressions.
The software does not validate the regular expressions that you enter. You can even specify an invalid regular
expression that might cause noncompliant errors when you create records.
You can only define your own host name restriction policy at the grid level. At the member level and at the zone
level, you can only select a policy.
Use the drop-down menu in the Host Name Restriction Policy section to select one of the following host name
checking policies: Allow Any, Allow Underscore, Strict Host Name Checking, or a user-defined policy. This sets
the policy for all the zones in the grid.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
291
Managing DNS Data
4. Click the Save and Restart Services icons.
After you specify a host name restriction policy, if you create a record name that does not comply with this policy and
try to save it by clicking the Save icon, an error message appears.
To configure the host name restriction policy for an individual member:
1. From the DNS perspective, click the DNS Members tab -> member -> Edit -> Member DNS Properties.
2. In the Edit Zone Properties dialog box, click Host Name Restrictions.
3. Click the Override grid host name restriction policy check box to override the grid host name restriction policy,
and specify the settings for this member. If you choose the override option, then you must select a host name
policy from the Host Name Restriction Policy drop-down menu.
4. Use the drop-down menu in the Host Name Restriction Policy section to select one of following the host name
checking policies or a user-defined policy:
— Allow Any: You can use any host name.
— Allow Underscore: You can only use host names with alphanumeric characters and underscores ("-" and
"_")
— Strict Hostname Checking: You can only use host names that contain alphanumeric characters and dashes
(“-’).
To configure the host name restriction policy for an authoritative forward-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit Properties.
You can only specify host name restrictions for authoritative forward-mapping zones. You cannot specify host
name restrictions for forward zones, stub zones, IPv4 reverse-mapping zones, and IPv6 reverse mapping zones.
2. In the Edit Zone Properties dialog box, click Host Name Restrictions.
3. Click the Override grid host name restriction policy check box to override the grid host name restriction policy,
and specify the settings for this zone. If you choose the override option, you must select a host name policy from
the Host Name Restriction Policy drop-down menu.
4. Use the drop-down menu in the Host Name Restriction Policy section to select one of the following host name
checking policies or a user-defined policy:
— Allow Any: You can use any host name.
— Allow Underscore: You can only use host names with alphanumeric characters, dashes, and underscores
("-" and "_")
— Strict Hostname Checking: You can only use host names that contain alphanumeric characters and dashes
(“-’).
Example
For example, if you create a zone myAuthZone and specify the host name restriction to be Strict Hostname Checking
and then you add an A record to myAuthZone and enter corp_100 as the domain name, the following error message
appears:
RR name “corp_100” does not comply with policy “Strict Hostname Checking”
To resolve this error, change the domain name to corp100.
292
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding a Host or Bulk Host
Obtaining a List of Invalid Record Names
To get a list of all record names that do not comply with the host name checking policy, from the DNS perspective,
click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for Forward-Mapping Zones) -> zone -> Report
Invalid Records.
The Noncompliant Records panel appears. It lists the record name, type, value, and comment for all records that do
not comply with the host name restriction policy. You can right-click a record name and edit it to make it compliant or
delete it.
Adding a Host or Bulk Host
After adding zones, you are ready to add hosts and records for the zones. You can choose to add a bulk host, that
assigns a range of addresses to a set of hosts. While adding a host, you can choose to add an alias (CNAME record)
for the host.
This section covers the following topics:
•
•
Adding a Host on page 293
Adding a Bulk Host on page 294
Adding a Host
A host record defines attributes for a node, such as the name-to-address and address-to-name mapping. This
alleviates having to specify an A record and a PTR record separately for the same node. A host can also define aliases
and DHCP fixed address nodes.
You must first create a zone before you can add a host record for the zone. For more information, see Adding an
Authoritative Subzone on page 268 To create a host record, you need to know the host name and one or more IP
addresses.
Note: The hosts in a zone can be located on different networks.
To add a host:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add
Resource Records -> Host.
2. In the Add Host editor, click Host Record Properties, and specify the following information:
— In the Name field, enter a unique name for the host. For example, you might enter BigWin for the sales
organization host system. For A, AAAA, Host, MX, and NS records in the forward-mapping zones, ensure that
the name you enter complies with the host name restriction policy defined for the zone. If you create a
record name that does not comply with this policy and you try to save it by clicking the Save icon, a Save
Error message appears.
— In the Comment field, enter a distinguishing comment.
— Click Disable this host to temporarily disable the host.
3. In the IP Address section, click Add, enter the following information, and then click OK.
— Enter the IP Address of the host.
— Enter a MAC Address (e.g., for a DHCP fixed address) for the host. You must enter an IP address, however,
entering the MAC address is optional. The MAC Address field defines a fixed address for a DHCP host. For
more information on fixed address host, see Adding a Host on page 293.
— Override Network Domain Name: Click this check box and enter a Domain Name in the text field.
— Override Network Broadcast Address: Click this check box and enter a Broadcast Address in the text field.
— Override Routers: Click this check box, enter an IP Address in the text field, and click Add.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
293
Managing DNS Data
— Override Domain Name Servers: Click this check box, enter an IP Address in the text field, and click Add.
— Override Lease Time: Click this check box and specify a new Lease Time in Days, Hours, Minutes, and
Seconds.
— Override PXE Lease Time: Click this check box, then click Enable PXE Lease Time, and specify a new lease
time in Days, Hours, Minutes, and Seconds.
— Override network custom options: Click this check box, click Add Option, click Select Option, select an
option from the list and click OK, enter a value and click OK.
— Override network BOOTP options: Click this check box and specify the following information:
— Boot File name
— Next Server name
— Boot Server name
4. In the Aliases section, click Add, enter a fully qualified domain name (a CNAME record for the host), and then
click OK.
5. Click the Save and Restart Services icons.
Adding a Bulk Host
If you need to add a large number of hosts, you can have the Infoblox device add them as a group and automatically
assign host names based on a range of IP addresses. This group of hosts is referred to as a bulk host, that the device
manages and displays in the Management screen as a single bulk host.
The Infoblox device uses the name space bulk-xx-xx-xx-xx for bulk hosts, so this name should not be used for CNAMEs
and host aliases because doing so will cause conflicts. Before adding a bulk host, make sure that no CNAME or host
alias uses this name.
A bulk host name consists of a prefix, a suffix, and the name of the domain to which the host belongs. The prefix can
be any name. You can specify a format for the suffix, which is composed from an IP address in the bulk host IP address
range. Given the prefix of the bulk host name is Info, the IP address is 213.19.32.133, and the domain name is
infoblox.com, the following are bulk host names with two different suffix formats:
•
Default suffix format: Info-213-19-23-133.infoblox.com
•
Alternate format: Info213019032133.infoblox.com
You specify the format of the suffix, then the device generates the host names based on the format. For information
on specifying the format of the suffix, see Specifying a Bulk Host IP Address Format on page 315.
To add a bulk host:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> Bulk Host.
2. In the Add Bulk Host editor, click Bulk Host Properties.
3. In the Prefix field, enter a name (or series of characters) to insert at the beginning of each host name. You can
enter any printable character in this field, except a period.
The sum of the bulk host prefix length and suffix length must not exceed 63 characters. When you enter a prefix,
the Infoblox device computes the maximum length of the bulk host suffix to verify that the total prefix and suffix
length does not exceed 63 characters. If it does, the device displays an error message indicating the number of
characters that you must remove to make a valid prefix.
4. In the Starting IP Address field, enter the first IP address in the range of addresses for the group.
5. In the Ending IP Address field, enter the last IP address in the range.
6. You can enter a text string in the Comment field to help identify this record.
7. Click Automatically Add Reverse Mapping to have the device automatically add the reverse mapping address.
8. Optional: Click Disable this Bulk Host to disable the host.
294
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding a Host or Bulk Host
9. Click Time to Live Settings to set the time to live (TTL) for this record. The default is Use grid TTL settings. To
specify other settings, click Override grid TTL settings, and enter the settings in Days, Hours, Mins, Secs. For more
information on TTL settings, see Specifying Time To Live Settings on page 310.
10. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
295
Managing DNS Data
Adding Resource Records
After adding zones you can add resource records to those zones and hosts, with the option of disabling any record.
When you disable a record, the Infoblox device does not answer queries for it, nor does it include disabled records in
zone transfers and zone imports. The device still displays disabled records in the GUI, marked with red to indicate a
disabled state.
The Infoblox device allows you to create the following types of records:
•
Address (A)
•
Pointer (PTR)
•
Service location (SRV)
•
Mail exchanger (MX)
•
Text (TXT)
•
Canonical name (CNAME)
•
DNAME
The Infoblox device also allows you to specify time-to-live (TTL) settings for each record. If you do not specify a TTL for
a record, the device applies the default TTL value of the zone to each record. +
This section covers the following topics:
•
•
•
•
•
•
•
•
•
•
Adding an A Record on page 296
Adding an NS(A) Record on page 297
Adding an AAAA Record on page 297
Adding an MX Record on page 300
Adding a PTR Record on page 298
Adding an SRV Record on page 301
Adding a TXT Record on page 302
Adding a CNAME Record on page 303
Adding a DNAME Record on page 305
Specifying Time To Live Settings on page 310
Adding an A Record
An A (address) record maps a domain name to an IPv4 address. To define a specific name-to-address mapping, add
an A record to a previously defined authoritative forward-mapping zone (see Creating an Authoritative
Forward-Mapping Zone on page 265).
To add an A record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> A Record.
A Record Properties
— Domain Name: Enter a host name that you want to map to an IP address. The name you enter is prefixed to
the zone name. For example, if the zone name is corp100.com and you enter www , its full name becomes
www.corp100.com .
Infoblox also supports wildcard A records. A wildcard A record maps all names for which there is no specific
A record in a domain to a single IP address. For example, you can use a wildcard A record to map all names
in the corp100.com domain to the IP address of a public-facing web server. The Infoblox device responds to
queries for names such as www1.corp100.com, ftp.corp100.com, main.corp100.com, and so on to the
same IP address. If there are also A records for specific names in the corp100.com domain, the Infoblox
device first matches queries for those names to their records. However, if a query arrives for a name for
which a specific A record does not exist, the Infoblox device can then use the wildcard card to map the
name to a “default” address. To make a wildcard A record, enter an asterisk ( * ) in the Domain name field.
296
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
Ensure that the domain name you enter complies with the host name restriction policy defined for the zone.
If you create a record name that does not comply with this policy and you try to save it by clicking the Save
icon, a Save Error message appears.
— IP Address: Enter the IPv4 address to which you want the domain name to map. An IPv4 address is a 32-bit
number in dotted decimal notation. It consists of four 8-bit groups of decimal digits separated by decimal
points (example: 192.168.1.2).
— Comment: Enter a descriptive comment for this record.
— Disable this A record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Adding an NS(A) Record
An NS (A) record identifies the authoritative DNS server for a domain. This type of record is similar to a NS record,
although NS(A) records associate with one or more IP addresses used for related A record and PTR record generation.
You can configure NS (A) record for anycast IP addresses on the device. For more information about anycast, see
Anycast Addressing on page 342.
To add an NS(A) record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> NS(A) Record.
NS Record Properties
— Zone: Display the DNS zone name for the NS(A) record.
— Name: Display the name for the NS(A) record.
— View: Display the Infoblox view for the NS(A) record.
— Domain Name: Enter the host name you want to configure as the name server for the zone .
Manual associated IP addresses
— IP addresses associated to NS record: Expand this section to add or modify the IP address to the configured
domain name. The IP Address dialog box appears.
— IP Address: Enter the IP address for the NS(A) record.
— Automatically generate related PTR record: Click the check box to enable autogeneration of PTR records
for the IP address.
2. Click the Save and Restart Services icons.
Adding an AAAA Record
An AAAA (quad A address) record maps a domain name to an IPv6 address. To define a specific name-to-address
mapping, add an AAAA record to a previously defined authoritative forward-mapping zone (see Creating an
Authoritative Forward-Mapping Zone on page 265).
To add an AAAA record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> AAAA Record.
AAAA Record Properties
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
297
Managing DNS Data
— Domain Name: Enter a host name that you want to map to an IP address. The name you enter is prefixed to
the zone name. For example, if the zone name is corp100.com and you enter www , its full name becomes
www.corp100.com .
Infoblox also supports wildcard AAAA records. A wildcard AAAA record maps all names for which there is no
specific AAAA record in a domain to a single IP address. For example, you can use a wildcard AAAA record to
map all names in the int.corp100.com domain to the IPv6 address of an internal web server. The Infoblox
device responds to queries for names such as www1.int.corp100.com, home.int.corp100.com,
main.int.corp100.com, and so on to the same address. If there are also AAAA records for specific names in
the int.corp100.com domain, the Infoblox device first matches queries for those names to their records.
However, if a query arrives for a name for which a specific AAAA record does not exist, the Infoblox device
can then use the wildcard card to map the name to a “default” address. To make a wildcard AAAA record,
enter an asterisk ( * ) in the Domain name field.
Ensure that the host name you enter complies with the host name restriction policy defined for the zone. If
you create a record name that does not comply with this policy and you try to save it by clicking the Save
icon, a Save Error message appears.
— IP Address: Enter the IPv6 address to which you want the domain name to map. An IPv6 address is a 128-bit
number in colon hexadecimal notation. It consists of eight 16-bit groups of hexadecimal digits separated
by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
Note: When you enter an IPv6 address, you can use double colons to compress a contiguous sequence of zeros.
You can also omit any leading zeros in a four-hexadecimal group. For example, the complete IPv6 address
2006:0000:0000:0123:4567:89ab:0000:cdef can be shortened to 2006::123:4567:89ab:0:cdef. Note
that if there are multiple noncontiguous groups of zeros, the double colon can only be used for one group
to avoid ambiguity. The Infoblox device displays an IPv6 address in its shortened form, regardless of its
form when it was entered.
— Comment: Enter a descriptive comment for this record.
— Disable this AAAA record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Adding a PTR Record
A PTR (pointer) record maps an address to a host name, and can only be added for a reverse mapping zone. If you
have not already done so, you must first create a reverse mapping zone before adding an PTR record for that zone.
For more information, see Creating an Authoritative Forward-Mapping Zone on page 265. To create an PTR record, you
need to specify a domain name and host name.
Note: You must configure PTR records manually for IPv6 addresses. Unlike IPv4 PTR records, IPv6 PTR records are not
autogenerated.
To add an IPv4 or IPv6 PTR record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for IPv4
Reverse-Mapping Zones or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Add Resource Records -> PTR Record.
PTR Record Properties
— IP Address: Enter the IPv4 or IPv6 address that you want to map to a domain name.
298
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
An IPv4 address is a 32-bit number in dotted decimal notation. It consists of four 8-bit groups of decimal
digits separated by decimal points (example: 192.168.1.2).
An IPv6 address is a 128-bit number in colon hexadecimal notation. It consists of eight 16-bit groups of
hexadecimal digits separated by colons (example: 12ab:0000:0000:0123:4567:89ab:0000:cdef).
— Host Name: Enter the host name to which you want the PTR record to point (example: www.corp100.com).
— Comment: Enter a descriptive comment for this record.
— Disable this PTR record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
299
Managing DNS Data
Adding an MX Record
An MX (mail exchanger) record maps a domain name to a mail exchanger. A mail exchanger is a server that either
delivers or forwards mail. You can specify one or more mail exchangers for a zone, as well as the priority for using
each mail exchanger. A standard MX record applies to a particular domain or subdomain. A wildcard MX record
applies to a domain and all its subdomains. See Figure 10.15
Figure 10.15 MX Records
The following MX records …
… direct queries for one or more domains …
An MX record for the mail exchanger that answers queries for
just the corp100.com domain (and its corresponding A record):
corp100.com IN MX 0 mail1.corp100.com
mail1.corp100.com IN A 1.2.2.10
… to the same mail exchanger:
Domain
corp100.com
An MX record for just site1.corp100.com, a subdomain of
corp100.com:
site1.corp100.com IN MX 0 mail1.corp100.com
Mail Exchanger
mail1.corp100.com
1.2.2.10
Subdomain
site1.corp100.com
A wildcard MX record for the corp100.com domain,
the site1.corp100.com subdomain, and any other
subdomains of corp100.com:
*.corp100.com IN MX 0 mail1.corp100.com
… other subdomains of
corp100.com …
Note: You must also create an A record for the host defined as a mail exchanger in an MX record.
To add an MX record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> MX Record.
MX Record Properties
— Domain Name: If you want to define an MX record for a domain whose name matches the zone in which you
define the MX record, leave this field empty. The Infoblox device automatically adds the domain name (the
same as the zone name) to the MX record. For example, if you want to create an MX record for a mail
exchanger serving the corp100.com domain and you define the MX record in the corp100.com zone, leave
this field empty.
If you want to define an MX record for a subdomain, enter that subdomain name here. The Infoblox device
prefixes the name you enter to the domain name for the zone in which you define the MX record. For
example, if you want to create an MX record for a mail exchanger serving site1.corp100.com—a subdomain
of corp100.com—and you define the MX record in the corp100.com zone, enter site1 in this field.
If you want to define an MX record for a domain and all its subdomains, enter an asterisk ( * ) here to create
a wildcard MX record.
Ensure that the host name you enter complies with the host name restriction policy defined for the zone. If
you create a record name that does not comply with this policy and you try to save it by clicking the Save
icon, a Save Error message appears.
— Mail Exchanger: Enter the fully qualified domain name of the mail exchanger.
— Priority: Enter an integer between 0-65535. The priority determines the order in which a client attempts to
contact the target mail exchanger. The highest priority is 0 and is queried first.
— Comment: Enter a descriptive comment for this record.
— Disable this MX record: Clear the check box to enable the record. Select the check box to disable it.
300
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Adding an SRV Record
An SRV (service location) record directs queries to hosts that provide specific services. For example, if you have an
FTP server, then you might create an SRV record that specifies the host that provides that service. You can specify
more than one SRV record for a host. To create an SRV record, you need to specify the domain name, priority, weight,
port, and target host. For more information about SRV records, see RFC 2052, A DNS RR for specifying the location of
services (DNS SRV) .
To add a SRV record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> SRV Record.
SRV Record Properties
— Domain Name: Enter a service name and protocol name to complete the domain name for the target host. If
the name of the service is defined in RFC 1700, ASSIGNED NUMBERS , use that name. Otherwise, you can
use a locally-defined name. (Do not use service port and protocol numbers.) To distinguish the service and
protocol name labels from the domain name, prepend an underscore to the service name and protocol
name; for example, _http._tcp.corp100.com or _ftp._tcp.corp100.com
— Priority: Enter an integer between 0-65535. The priority determines the order in which a client attempts to
contact the target host; the domain name host with the lowest number has the highest priority and is
queried first. Target host with the same priority is attempted in the order defined in the Weight field.
— Weight: Enter an integer between 0-65535. Weight allows you to distribute the load between target hosts.
The higher the number, the more that host handles the load (compared to other target hosts). Larger
weights give a target host a proportionately higher probability of being selected.
— Port: Enter the appropriate port number for the service running on the target host. You can use standard or
nonstandard port numbers, depending on the requirements of your network.
— Target: Enter the canonical domain name of the host (not an alias); for example, www2.corp100.com
Note: In addition, you need to define an A record mapping the canonical name of the host to its IP address.
— Comments: Enter a descriptive comment for the record.
— Disable this SRV record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
301
Managing DNS Data
Adding a TXT Record
A TXT (text record) record contains supplemental information for a host. For example, if you have a sales server that
serves only North America, you can create a text record stating this fact. You can create more than one text record for
a domain name.
To add a TXT record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records ->TXT Record.
TXT Record Properties
— Domain Name: If you want to define a TXT record for a domain whose name matches the zone in which you
define the TXT record, leave this field empty. The Infoblox device automatically adds the domain name (the
same as the zone name) to the TXT record. For example, if you want to create a TXT record for the
corp100.com domain and you define the TXT record in the corp100.com zone, leave this field empty.
If you want to define a TXT record for a host or subdomain, enter that name here. The Infoblox device
prefixes the name you enter to the domain name for the zone in which you define the TXT record. For
example, if you want to create a TXT record for a web server whose host name is www2.corp100.com and
you define the TXT record in the corp100.com zone, enter www2 in this field.
— Text: Enter the text that you want to associate with the record. It can contain up to 255 characters.
— Comments: Enter a descriptive comment for this record.
— Disable this TXT record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Using TXT Records for SPF
SPF (Sender Policy Framework) is an anti-forgery mechanism designed to identify spam e-mail. SPF fights e-mail
address forgery and makes it easier to identify spam, worms, and viruses. Domain owners identify sending mail
servers in DNS. SMTP receivers verify the envelope sender address against this information, and can distinguish
legitimate mail from spam before any message data is transmitted.
SPF makes it easy for a domain to say, “I only send mail from these machines. If any other machine claims that I'm
sending mail from there, they're not valid.” For example, when an AOL user sends mail to you, an e-mail server that
belongs to AOL connects to an e-mail server that belongs to you. AOL uses SPF to publish the addresses of its e-mail
servers. When the message comes in, your e-mail servers can tell if the server that sent the e-mail belongs to AOL or
not.
SPF records are actually specialized TXT records that identify what machines send mail from a domain. You can think
of SPF records as being reverse MX records that e-mail servers can use to verify if a machine is a legitimate sender of
an e-mail. Please refer to http://spf.pobox.com/draft-ietf-marid-protocol-00.txt for the current SPF protocol
specification.
SPF Record Examples
corp100.com.
corp100.net.
corp100.net.
corp100.net.
corp100.com.
302
IN
IN
IN
IN
IN
TXT
TXT
TXT
TXT
TXT
“v=spf1
“v=spf1
“v=spf1
“v=spf1
“v=spf1
mx –all”
a:mail.corp100.com –all”
include:corp100.com -all”
mx -all exp=getlost.corp100.com”
include:corp200.com -all”
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
Adding a CNAME Record
A CNAME record maps an alias to a canonical name. You can use CNAME records in both forward- and IPv4
reverse-mapping zones to serve two different purposes. (At this time, you cannot use CNAME records with IPv6
reverse-mapping zones.)
CNAME Records in Forward-Mapping Zones
In a forward-mapping zone, a CNAME record maps an alias to a canonical (or official) name. CNAME records are often
more convenient to use than canonical names because they can be shorter or more descriptive. For example, you can
add a CNAME record that maps the alias qa to the canonical name engr.corp100.com.
Note: A CNAME record does not have to be in the same zone as the canonical name to which it maps.
To add a CNAME record to a forward-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping) -> zone -> Edit -> Add Resource Records -> CNAME Record.
Note: IPv6 reverse-mapping zones support only PTR records at this time.
CNAME Record Properties
— Alias: Enter the alias for the canonical name.
— Canonical Name: Enter the complete canonical (or official) name of the host.
— Comments: Enter a descriptive comment for this record.
— Disable this CNAME record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
303
Managing DNS Data
CNAME Records in IPv4 Reverse-Mapping Zones
You can add CNAME records to an IPv4 reverse-mapping zone to create aliases to addresses maintained by a different
name server when the reverse-mapping zone on that server is a delegated child zone with fewer than 256 addresses.
This technique allows you to delegate responsibility for a reverse-mapping zone with an address space of fewer than
256 addresses to another authoritative name server. See Figure 10.16 and RFC 2317, Classless IN-ADDR.ARPA
delegation .
Figure 10.16 CNAME Records in a Reverse-Mapping Zone
Local DNS Server
Customer1
DNS Server
Customer2
DNS Server
Parent Zone
10.1.1.0/24
Delegated Child Zone
10.1.1.0/25
Delegated Child Zone
10.1.1.128/25
CNAME
PTR
PTR
CNAME
All the PTR records for
Customer1 use the
addresses defined as
canonical names in the
CNAME records on the
local DNS server.
CNAME Records for Customer1
2.1.1.10.in-addr.arpa
2.0/127.1.1.10.in-addr.arpa
Sample PTR records:
...
...
IP Address:
1.0/127.1.1.10.in-addr.arpa
Host Name:
host1.customer1.com
126.1.1.10.in-addr.arpa
126.0/127.1.1.10.in-addr.arpa
IP Address:
2.0/127.1.1.10.in-addr.arpa
Host Name:
host2.customer1.com
...
ALIAS
CANONICAL NAME
1.1.1.10.in-addr.arpa
1.0/127.1.1.10.in-addr.arpa
The PTR records for
Customer2 also use the
addresses defined as
canonical names in the
CNAME records on the
local DNS server.
CNAME Records for Customer2
ALIAS
CANONICAL NAME
129.1.1.10.in-addr.arpa
129.128/255.1.1.10.in-addr.arpa
130.1.1.10.in-addr.arpa
130.128/255.1.1.10.in-addr.arpa
...
...
254.1.1.10.in-addr.arpa
254.128/255.1.1.10.in-addr.arpa
You add CNAME records in the parent zone on your name server. The aliases defined in those CNAME records point
to the addresses in PTR records in the child zone delegated to the other server.
When you define a reverse-mapping zone that has a netmask from /25 (255.255.255.128) to /31
(255.255.255.254), you must include an RFC 2317 prefix. This prefix can be anything such as the address range
(examples: 0-127, 0/127) to descriptions (examples: first-network, customer1). On an Infoblox device, creating such
a reverse-mapping zone automatically generates all the necessary CNAME records. However, if you need to add them
manually to a parent zone that has a child zone with fewer than 256 addresses:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for IPv4
Reverse-Mapping) -> zone -> Edit -> Add Resource Records -> CNAME Record.
CNAME Record Properties
— Alias: Enter the host portion of an IP address. For example, if the full IP address is 10.1.1.1 in a network
with a 25-bit netmask, enter 1. (The 10.1.1.0/25 network contains host addresses from 10.1.1.1 to
10.1.1.126. The network address is 10.1.1.0, and the broadcast address is 10.1.1.127.)
304
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
— Canonical Name: Enter host_ip_addr.prefix.network.in-addr.arpa (host IP address + 2317 prefix + network
IP address + in-addr.arpa). For example, enter 1.0/25.1.1.10.in-addr.arpa. This IP address must match the
address defined in the PTR record in the delegated child zone.
— Comments: Enter a descriptive comment for this record.
— Disable this CNAME record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Adding a DNAME Record
A DNAME record maps all the names in one domain to those in another domain, essentially substituting one domain
name suffix with the other (see RFC 2672, Non-Terminal DNS Name Redirection). For example, adding a DNAME record
to the corp100.com domain mapping “corp100.com” to “corp200.com” maps name-x.corp100.com to
name-x.corp200.com:
Domain Name
Target Domain Name
server1.corp100.com
—>
server1.corp200.com
server2.corp100.com
—>
server2.corp200.com
server3.corp100.com
—>
server3.corp200.com
. . . .corp100.com
—>
. . . .corp200.com
When a request arrives for a domain name to which a DNAME record applies, the Infoblox device responds with a
CNAME record that it dynamically creates based on the DNAME definition. For example, if there is a DNAME record
corp100.com.
DNAME
corp200.com.
and a request arrives for server1.corp100.com, the Infoblox device responds with the following CNAME record:
server1.corp100.com.
CNAME
server1.corp200.com.
If responding to a name server running BIND 9.0.0 or later, the Infoblox device also includes the DNAME record in its
response, so that name server can also create its own CNAME records based on the cached DNAME definition.
The following are two common scenarios for using DNAME records:
•
One company buys another and wants people using both the old and new name spaces to reach the same
hosts.
•
A virtual Web hosting operation offers different “vanity” domain names that point to the same server or servers.
There are some restrictions that apply to the use of DNAME records:
•
You cannot have a CNAME record and a DNAME record for the same subdomain.
•
You cannot use a DNAME record for a domain or subdomain that contains any subdomains. You can only map
the lowest level subdomains; that is, those that do not have any subdomains below them. For an example of
using DNAME records in a multi-tiered domain structure, see Figure 10.17 on page 306.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
305
Managing DNS Data
Figure 10.17 Adding DNAME Records for the Lowest Level Subdomains
Corp200 buys Corp100 and wants to redirect queries for
corp100.com to corp200.com; however, the multitiered
structure of corp100.com prohibits a complete mapping
of all its subdomains. In such a case, DNAME records
provide only a partial solution.
corp200.com
corp100.com
dev.corp100.com
dev100.corp200.com
mktg.corp100.com
DNAME Record
Domain Name:
dev.corp100.com
Target Domain:
dev100.corp200.com
art.mktg.corp100.com
art.mktg100.corp200.com
DNAME Record
Domain Name:
art.mktg.corp100.com
Target Domain:
art.mktg100.corp200.com
In the case of a domain structure consisting of a single domain (that is, there are no subdomains), adding a DNAME
record redirects queries for every name in that domain to the target domain, as shown in Figure 10.18.
Figure 10.18 Adding a DNAME Record for a Single Domain
Corp200 buys Corp100 and wants to redirect
all queries for corp100.com to corp200.com.
To accomplish this, you add a single DNAME
record to corp100.com.
corp200.com
corp100.com
corp100.corp200.com
www1.corp100.com
mail1.corp100.com
www2.corp100.com
ftp1.corp100.com
DNAME Record
Domain Name:
corp100.com
Target Domain:
corp100.corp200.com
www1.corp100.corp200.com
www2.corp100.corp200.com
mail1.corp100.corp200.com
ftp1.corp100.corp200.com
When using a DNAME record, you must copy the resource records for the source domain to the zone containing the
target domain, so that the DNS server providing service for the target domain can respond to the redirected queries.
For the example in Figure 10.18, copy these records:
Copy from corp100.com
to corp100.corp200.com
www1 IN A 10.1.1.10
www1 IN A 10.1.1.10
www2 IN A 10.1.1.11
www2 IN A 10.1.1.11
ftp1 IN A 10.1.1.20
ftp1 IN A 10.1.1.20
mail1 IN A 10.1.1.30
mail1 IN A 10.1.1.30
After copying these records to the zone containing the corp100.corp200.com domain, delete them from the zone
containing the corp100.com domain.
306
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
If DNS service for the source and target domain names is on different name servers, you can import the zone data
from the Infoblox device hosting the source domain to the device hosting the target domain. For information about
this procedure, see Importing Zone Data on page 271.
If DNS service for the source and target domain names is on the same name server and the parent for the target
domain is on a different server, you can delegate DNS services for the target domain name to the name server that
provided—and continues to provide—DNS service for the source domain name (see Figure 10.19 on page 307). By
doing this, you can continue to maintain resource records on the same server, potentially simplifying the
continuation of DNS administration.
Figure 10.19 Making the Target Zone a Delegated Zone
ns1.corp100.com
Primary name server for corp100.com
and authoritative name server for
corp100.corp200.com
On the primary name server for corp200.com
(ns1.corp200.com), specify “corp100.corp200.com” as a
delegated zone and specify “ns1.corp100.com” as the
name server for that zone.
ns1.corp200.com
Primary name server
for corp200.com
corp100.com
corp100.corp200.com
www1.corp100.corp200.com
www2.corp100.corp200.com
Resource Records
corp100.com IN
IN
IN
corp100.com
IN
SOA
NS
NS
DNAME
ns1.corp100.com
ns1.corp100.com
ns2.corp100.com
corp100.corp200.com
corp200.com
Resource Records
corp100.corp200.com
www1
www2
ftp1
mail1
IN
IN
IN
IN
IN
IN
IN
mail1.corp100.corp200.com
ftp1.corp100.corp200.com
SOA
NS
NS
A
A
A
A
ns1.corp200.com
ns1.corp200.com
ns2.corp200.com
10.1.1.10
10.1.1.11
10.1.1.20
10.1.1.30
Note: This is a conceptual representation of domain name mapping and
depicts the resulting hierarchical relationship of corp200.com as the parent
zone for corp100.corp200.com. The hosts are not physically relocated.
The following tasks walk you through configuring the two devices in Figure 10.19 to redirect queries for corp100.com
to corp100.corp200.com using a DNAME record:
On the ns1.corp100.com name server, do the following:
1. Create a new forward-mapping zone called corp100.corp200.com. See Configuring Authoritative Zones on page
265.
2. Copy all the resource records for the domain or subdomain to which the DNAME record is going to apply from
corp100.com to corp100.corp200.com. See Copying Zone Records on page 255.
Note: Because you can only specify the records by type, not individually, you might have to copy some records
that you do not want and then delete them from the corp100.corp200.com zone.
3. In the corp100.com zone, delete all the resource records for the domain or subdomain to which the DNAME
record is going to apply.
4. Add a DNAME record to the corp100.com zone specifying “corp100.com” as the domain and
“corp100.corp200.com” as the target domain. Adding a DNAME record is explained in the next section.
5. On the ns1.corp200.com name server, add corp100.corp200.com as a delegated zone and specify
ns1.corp100.com as the name server for it. See Configuring a Delegated Zone on page 275.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
307
Managing DNS Data
DNAME Records for Forward-Mapping Zones
To add a DNAME record to a forward-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> Edit -> Add Resource Records -> DNAME Record.
DNAME Record Properties
— Domain Name: Enter the name of a subdomain. If you are adding a DNAME record for the entire zone, leave
this field empty. This field is for adding a DNAME record for a subdomain within the selected zone.
— Target Domain: Enter the domain name to which you want to map all the domain names specified in the
Domain Name field.
— Comments: Enter identifying text for this record, such as a meaningful note ore reminder.
— Disable this DNAME record: Clear the check box to enable the record. Select the check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Note: If you specify a subdomain in the Domain Name field when configuring a DNAME record and that
subdomain is also a subzone, the DNAME record appears in the list view for that subzone, not in the list
view for the parent zone selected in the process of adding the record.
DNAME Records for Reverse-Mapping Zones
You can use DNAME records to redirect reverse lookups from one reverse-mapping zone to another. You can use
DNAME records for reverse-mapping zones to simplify the management of subzones for classless address spaces
larger than a class C subnet (that is, a subnet with a 24-bit netmask).
RFC 2672, Non-Terminal DNS Name Redirection, includes an example showing the delegation of a subzone for an
address space with a 22-bit netmask inside a zone for a larger space with a 16-bit netmask:
$ORIGIN 0.192.in-addr.arpa.
8/22
NS
ns.slash-22-holder.example.
8
DNAME
8.8/22
9
DNAME
9.8/22
10
DNAME
10.8/22
11
DNAME
11.8/22
The reverse-mapping zone 0.192.in-addr.arpa. applies to the address space 192.0.0.0/16. Within this zone is a
subzone and subdomain with the abbreviated name 8/22. (Its full name is 8/22.0.192.in-addr.arpa.) This
subdomain contains its own subdomains corresponding to the 1024 addresses in the 192.0.8.0/22 subnet:
•
Subdomain 8/22 (8/22.0.192.in-addr.arpa)
— Subdomain 8.8/22 for addresses 192.0.8.0 – 192.0.8.255 (or 192.0.8.0/24)
— Subdomain 9.8/22 for addresses 192.0.9.0 – 192.0.9.255 (or 192.0.9.0/24)
— Subdomain 10.8/22 for addresses 192.0.10.0 – 192.0.10.255 (or 192.0.10.0/24)
— Subdomain 11.8/22 for addresses 192.0.11.0 – 192.0.11.255 (or 192.0.11.0/24)
The NS record delegates authority for the reverse-mapping subzone 8/22 to the DNS server
ns.slash-22-holder.example.
308
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Adding Resource Records
Finally, the DNAME records provide aliases mapping domain names that correspond to the 192.0.8.0/24,
192.0.9.0/24, 192.0.10.0/24, and 192.0.11.0/24 subnets to the respective subdomains 8.8/22, 9.8/22, 10.8/22,
and 11.8/22 in the 8/22.0.192.in-addr.arpa subzone.
Note: Infoblox devices support DNAME records in reverse-mapping zones that map addresses to target zones with a
classless address space larger than a class C subnet. However, Infoblox devices do not support such target
zones.
You might also use DNAME records if you have a number of multihomed devices whose IP addresses must be mapped
to a single set of domain names. An example of this is shown in Figure 10.20.
Figure 10.20 DNAME Records to Simplify DNS for Multihomed Devices
Instead of maintaining a PTR record for the IP addess of
each interface on every multihomed device, you can store
all the PTR records in one reverse-mapping zone and use
DNAME records in the other zones to point reverse
lookups to the one set of PTR records.
Resource Records
1.1.1.10.in-addr.arpa IN
1.1.1.10.in-addr.arpa IN
1.1.10.in-addr.arpa
IN
NS
ns1.corp100.com
NS
ns2.corp100.com
DNAME 3.1.10.in-addr.arpa
Multihomed
Devices
All PTR records
are here.
Resource Records
3.1.1.10.in-addr.arpa
3.1.1.10.in-addr.arpa
1
2
3
4
IN
IN
IN
IN
IN
IN
NS
NS
PTR
PTR
PTR
PTR
ns1.corp100.com
ns2.corp100.com
www1.corp100.com
www2.corp100.com
ftp1.corp100.com
stor1.corp100.com
1
1.1.10.in-addr.arpa.
3.1.10.in-addr.arpa.
2
All DNAME
records are
here.
Reverse-Mapping
Zones
Reverse-Mapping
Zones
3
4.1.10.in-addr.arpa.
2.1.10.in-addr.arpa.
4
Resource Records
2.1.1.10.in-addr.arpa IN
2.1.1.10.in-addr.arpa IN
2.1.10.in-addr.arpa
IN
NS
ns1.corp100.com
NS
ns2.corp100.com
DNAME 3.1.10.in-addr.arpa
.
.
.
Resource Records
4.1.1.10.in-addr.arpa
4.1.1.10.in-addr.arpa
4.1.10.in-addr.arpa
IN NS
ns1.corp100.com
IN NS
ns2.corp100.com
IN DNAME 3.1.10.in-addr.arpa
Note: If you specify a subdomain in the Domain Name field when configuring a DNAME record, and that subdomain
is also a subzone, the DNAME record appears in the list view for that subzone, not in the list view for the parent
zone that was selected when adding it.
To add a DNAME record to a reverse-mapping zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for IPv4
Reverse-Mapping Zones) -> zone -> Edit -> Add Resource Records -> DNAME Record.
Note: IPv6 reverse-mapping zones support only PTR records at this time.
DNAME Record Properties
— Domain Name: If you are adding a DNAME record for the entire zone that you selected in the tree view (that
is, the zone selected in step 1), leave this field empty. If you are adding a DNAME record for a subdomain
within the selected zone, enter the name of that subdomain name here.
— View: Shows the name of the current view.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
309
Managing DNS Data
— Target Domain: Type the name of the reverse-mapping zone to which you want to map all the addresses
specified in the Domain Name field.
— Comments: Enter text to help identify this record or to provide a meaningful note or reminder about it.
— Disable this DNAME record: Clear check box to apply the DNAME record. Select check box to disable it.
Time to Live Settings
— Use grid TTL settings: Select to apply the TTL settings inherited from the grid or zone (if you previously
configured TTL settings for the zone containing this record). By default, a resource record inherits its TTL
(time to live) settings.
— Override grid TTL settings: Select to override the inherited settings. To configure TTL settings for this record,
enter the settings in the Days, Hours, Mins, Secs fields. For more information on TTL settings, see
Specifying Time To Live Settings on page 310.
2. Click the Save and Restart Services icons.
Specifying Time To Live Settings
You can specify TTL (time to live) settings for Infoblox host records and resource records. TTL settings determine how
long the record will be valid in the cache of a caching DNS server. You can configure TTL settings at the grid, zone, and
record level.
To specify TTL settings for a grid:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click General.
3. In the Default TTL and Negative TTL fields, enter values for Days, Hours, Mins, Secs, as necessary. The default TTL
determines the period for which positive responses to queries remain valid. (You can override this setting for
specific zones and for individual host and resource records.) The negative TTL determines the period for which
negative responses remain valid. (You can override this setting for specific zones.)
4. Click the Save and Restart Services icons.
To configure TTL settings for an individual zone:
•
From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit ->
Authoritative Zone Properties -> Settings , and override the grid-level TTL settings.
To configure TTL settings for an Infoblox host or resource record:
•
310
From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> + (for zone ) ->
View -> Records -> record -> Edit -> Record Properties, and override the grid- or zone-level TTL settings.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Managing Hosts and Resource Records
Managing Hosts and Resource Records
After zones have been created, they need to be managed, which involves modifying, removing, disabling, and
enabling an Infoblox host or DNS resource record.
Modifying, Disabling, or Removing a Host or Record
The Infoblox device allows you to modify or remove an existing host or record. An alternative to changing or deleting
a host or record is to disable it.
To modify or disable a host or record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> View ->
Records.
2. In the Records viewer, double-click the host or record you want to modify. The host_record editor appears.
3. Make the necessary changes in the editor.
4. To disable the host or record, click the Disable this host_record check box.
5. Click the Save and Restart Services icons.
Deleting a Host or Record
You can delete a host or record to permanently remove it from the system. You can delete a single record or host, or
select multiple objects—including a combination of hosts and various resource records—and delete an entire
selected group.
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> View ->
Records.
2. In the Record viewer, click a host or record -> Edit -> Remove host_record.
3. To delete a set of hosts or records, click one object, then hold down the SHIFT key for contiguous objects or CTRL
for non contiguous objects, click the other objects, then click Edit -> Remove.
4. Click the Save and Restart Services icons.
5. Click the Restart Services icon.
Disabling or Enabling a Host or Record
You can disable a host or record instead of removing it. This alleviates having to remove, then re-add a host or a record
when physical repair or relocation of a network device occurs. When the changes to the physical device are complete,
you can simply re-enable the host or record.
To disable a host or record:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> View ->
Records.
2. In the Records viewer, double-click the host or record you want to modify. The host_record editor appears.
3. To disable the host or record, click the Disable this host_record check box.
4. To re-enable a host or record, click the check box again.
5. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
311
Managing DNS Data
Viewing DNS Record Listings
The Infoblox device allows you to easily view record listings and search for specific types of records, sorting this
information, and filtering the search findings.
To view record listings for a zone:
1. In the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones, IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> View ->
Records.
2. In the Records viewer, choose one of the following Filter types from the drop-down list, to sort the records
accordingly:
— All Types
— A Record
— AAAA Records
— Bulkhost Record
—
—
—
—
—
—
—
—
—
—
CNAME Record
DNAME Record
Host Record
HOST ADDRESS Record
HOST ALIAS Record
MX Record
NS Record
PTR Record
SRV Record
TXT Record
3. To go directly to a specific record, enter the record name in the Go to text field.
312
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 11 Configuring DNS Services
The service configurations of a grid are inherited by all members, zones, and networks. For this reason, it is
recommended that you configure services at the grid level before configuring member, zone and network services.
This chapter explains how to configure grid services, and is organized as follows:
•
•
•
•
Configuring DNS Services on page 314
— Changing General DNS Properties for a Grid on page 314
— Enabling Zone Transfers on page 317
— Specifying DNS Queries on page 319
— Specifying Root Name Servers for a Grid on page 321
— Specifying Sortlists on page 321
— Using Forwarders with a Grid on page 322
— Using Forwarders with a Member on page 322
— Specifying Minimal Response Returns on page 323
— Disabling and Enabling DNS Service for a Grid Member on page 323
Configuring DNS Zone Services on page 323
— Disabling Forwarding for a Zone on page 324
— Specifying TTL Settings for a Zone on page 325
— Changing the SOA Name for a Zone on page 325
— Setting the Serial Number in the SOA Record on page 326
— Adding an E-mail Address to the SOA Record on page 326
— Allowing Zone Transfers for a Zone on page 326
— Allowing Query Access for a Zone on page 327
Supporting Active Directory on page 328
— Active Directory and Unauthenticated DDNS Updates on page 329
— Active Directory and GSS-TSIG-Authenticated DDNS Updates on page 331
Viewing DNS Files on page 337
— Viewing DNS Cache Files on page 337
— Viewing a DNS Configuration File on page 337
— Viewing DNS Zone Statistics on page 337
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
313
Configuring DNS Services
Configuring DNS Services
When you configure DNS services at the grid level, all grid members, and zones belonging to those members, inherit
the grid-level configuration settings unless you specifically override them for selected members and zones. You can
configure the following DNS services at the grid level:
•
•
•
•
•
•
•
•
•
•
•
Changing General DNS Properties for a Grid on page 314
Enabling Zone Transfers on page 317
Specifying DNS Queries on page 319
Specifying Root Name Servers for a Grid on page 321
Specifying Sortlists on page 321
Using Forwarders with a Grid on page 322
Using Forwarders with a Member on page 322
Specifying Minimal Response Returns on page 323
Disabling and Enabling DNS Service for a Grid Member on page 323
Configuring Additional IP Addresses for a Grid Member on page 323
Specifying Host Name Restrictions on page 291
Changing General DNS Properties for a Grid
The Grid DNS Properties panel offers the following capabilities:
Specifying TTL Settings on page 314
• Specifying a Bulk Host IP Address Format on page 315
• Specifying Zone Deletion Confirmation on page 315
• Notifying External Secondary Servers on page 316
• Setting Source Port Settings on page 316
From the Grid perspective, click + (for grid ) -> + (for Services) -> DNS -> Edit -> Service Properties.
•
Specifying TTL Settings
TTL (time to live) is the time that a name server is allowed to cache data. After the TTL expires, the name server is
required to update the data. Setting a high TTL reduces network traffic, but also reduces the accuracy of your cached
data. Conversely, setting a low TTL increases the accuracy of cached data, but also increases the traffic on your
network.
Note: If you choose to configure one TTL setting, you must provide values for all of them.
To specify TTL settings for a grid:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the General section of the Grid DNS Properties editor, modify the following values as necessary:
— Refresh Every: This interval tells the secondary how often to send a message to the primary for a zone to
check that its data is current, and retrieve fresh data if it is not. The default is three hours.
— Retry Every: This interval tells the secondary how long to wait before attempting to recontact the primary
after a connection failure between the two occurs. The default is one hour.
— Expire After: If the secondary fails to contact the primary for the specified interval, the secondary stops
giving out answers about the zone because the zone data is too old to be useful. The default is 30 days.
— Default TTL (Time to Live): This interval tells the secondary how long data can be cached.
— Negative TTL (Time to Live): This interval tells the secondary how long data can be cached for Does Not
Respond responses.
314
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Services
3. Click the Save icon.
4. Click the Restart Services icon.
Specifying a Bulk Host IP Address Format
A bulk host name consists of a prefix, a suffix, and the name of the domain to which the host belongs. You enter the
bulk host name in the Bulk Host IP Address Format field of the Grid DNS Properties editor. The prefix can be any name
that consists of any printable character, except a period. The suffix is derived from an IP address in the bulk host IP
address range.
To specify the format for a bulk host IP address:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click General.
3. Enter the bulk host name in the Bulk Host IP Address Format field.
The suffix is a string of ASCII characters where $ and # are used as IP address octet references. Enter either $ to
specify unpadded octets, or # to specify 0 padded octets. For example, the prefix of a bulk host is info, the IP
address is 213.19.32.133, and the domain name is infoblox.com. If you specify the format -$-$-$-$, the bulk
host name is info-213-19-23-133.infoblox.com. If you specify the format *#*#*#*#, the bulk host name is
info*213*019*023*133.infoblox.com.
Following are additional rules for specifying the suffix format:
— The format must contain exactly four octet references.
— You cannot enter a combination of $ and # as octet references.
— If the format uses $ references, you must separate each one with at least one non-digit character. Therefore
each $, except the last one, must be surrounded by non-digit characters.
— The format must not start with the $ character.
— The \ character is the designated “escape” character for the $, # and \ characters. For example, given the IP
address 213.19.32.133, the format \##### expands to #213019032133.
— Note that the sum of the bulk host prefix length and suffix length must not exceed 63 characters. When you
enter a suffix format, the Infoblox device determines the length of the longest bulk host defined, and makes
sure that the sum of the bulk host prefix and suffix length does not exceed 63 characters.
— The Infoblox device computes the maximum length of the bulk host suffix by expanding the bulk host IP
format using 255.255.255.255. For example, given the format string -$-$-$-$, the maximum length of the
suffix is the length of -255-255-255-255, which is 16 characters. Therefore the maximum length of the host
prefix is 47 characters.
4. Click the Save icon.
5. Click the Restart Services icon.
Specifying Zone Deletion Confirmation
To ensure that a zone is not deleted by accident, the Enable double confirm for zone deletion property is enabled by
default.
To disable and re-enable the double confirmation requirement before a zone is deleted:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the General section of the Grid DNS Properties editor, clear the Enable double confirm for zone deletion check
box to disable the double confirmation requirement.
Select the check box again to re-enable the double confirmation requirement.
3. Click the Save icon.
4. Click the Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
315
Configuring DNS Services
Notifying External Secondary Servers
You can specify grid members (that are secondary name servers) to send notify messages to other secondary name
servers outside the grid. Enabling this option increases the number of notify messages; however, it ensures that an
external secondary name server receives notify messages when its master is a secondary name server in a grid. It is
enabled by default.
To disable secondary name servers from sending notify messages to secondary name servers outside the grid and
then and re-enable it:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the General section of the Grid DNS Properties editor, clear the Enable member secondaries to notify external
secondaries check box. To re-enable the functionality, select the check box again.
3. Click the Save icon.
4. Click the Restart Services icon.
All authoritative name servers (all primary and secondary servers) in a grid send notify messages to external
secondary servers by default. Because grid members can use database replication to maintain up-to-date zone data
sets, even if the primary server fails, the secondary servers in the grid can keep their zone data synchronized. Any
external secondary servers can fall out of sync, however, if they rely only on the primary server to send notify
messages when there is new zone data.
For the external secondary servers to accept notify messages from the secondary name servers in the grid and then
request zone transfers from them, you must configure the authoritative name servers in the grid as primary servers
on the external servers. This ensures that the external secondary servers continue to receive notify messages, even
if the primary server is unavailable.
All authoritative name servers in the grid send notify messages to the external secondaries when zone data updates
occur. The external secondary servers then query all the name servers they have configured as primary for that zone.
After this, the external secondary servers request a zone transfer from the name server whose zone has the highest
serial number. If more than one response contains the highest serial number, the external secondary servers transfer
data from the first primary server in their list.
For more information on zone transfers, see Enabling Zone Transfers on page 317.
Setting Source Port Settings
When requesting zone transfers from the primary server, some secondary DNS servers use the source port number
(the primary server used to send the notify message) as the destination port number in the zone transfer request.
To specify source port numbers for notify messages at the grid level:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the General section of the Grid DNS Properties editor, click the Set static source port for notify messages check
box.
3. Optionally, click the Set static source port for queries check box.
4. Click the Save icon.
5. Click the Restart Services icon.
For information on notify messages for zone transfers, see Establishing Zone Transfer Notify Messages on page 319.
316
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Services
Enabling Zone Transfers
A zone transfer is the process of sending zone data across a network from one name server to another. This is the
principle method a primary name server uses to send data to a secondary server. When the primary server detects a
change to its zone data, it notifies the secondary servers. The secondary servers reply by checking to see if the serial
number they have for the zone matches the serial number for the zone on the primary server. If not, the secondary
servers request a zone transfer.
In addition to receiving zone change notifications, a secondary server periodically polls the primary server to see if
their zone data is in sync. In response, the primary server can send a DNS message containing just the new zone data,
or the entire data set. The first type of transfer is known as an incremental zone transfer, or IXFR. The second type of
transfer is known as a full zone transfer, or AXFR.
An Infoblox device, acting as the primary name server for a zone, by default allows zone transfers to its secondary
name servers. This includes all servers listed in the NS records for that zone. You can also specify zone transfers to
other name servers, such as when migrating zone data to a new server or to a management system. You can specify
one or more destinations to which the local device sends zone transfers. You can also specify the security and format
of the transfers.
By default, grid members automatically receive updated zone data via database replication (through an encrypted
VPN tunnel). You can change the default behavior to allow grid members to use zone transfers instead of grid
replication. This is helpful when the primary server is another grid member, as a zone transfer is significantly faster
than database replication.
Keep in mind that a database replication updates zone data for both the active and passive nodes of an HA member.
Therefore, if there is a failover, the new active node (the previous passive node) immediately begins serving zone
data with fresh information. In the case of a zone transfer, the passive node does not receive zone data until after a
failover, when it becomes an HA master. At that time it sends a notify message to the primary server, which then
performs a zone transfer. If there is a lot of zone data, the transfer can take up to several minutes, thereby causing a
break in the availability of the new HA master.
If there are no HA members as secondary servers, zone transfers improve performance without a potential drawback.
If you have HA members as secondary servers, zone transfers can result in service interruption when there is a
failover. Furthermore, if the primary server is down when the HA member fails over, the new active node cannot
receive zone data until the primary server comes back online.
To allow zone transfers at the grid level:
1. Under the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Zone Transfers section of the Grid DNS Properties editor, select the Override Grid Zone Transfer Settings
check box.
3. In Allow zone transfers to section, click Add, specify the following information, and then click OK:
— IP Address: Select, and enter a destination IP address for zone transfers.
— Network: Enter a destination network IP Address for zone transfers, and select a Subnet mask from the
drop-down menu (1-31).
— Any: Select to allow or deny the local device to send zone transfers to any IP address.
— Allow: Select to allow zone transfers to the specified destination.
— Deny: Select to deny zone transfers to the specified destination.
4. Optionally, you can make the following configuration adjustments:
— Modify a zone: Select the zone from the list and click Modify.
— Remove a zone: Select the zone from the list and click Remove.
— Move a zone up the list: Select the zone and click Move up. The zone moves up the list incrementally with
each click of the button.
— Move a zone down the list: Select the zone and click Move down. The zone moves down the list
incrementally with each click of the button.
5. Click the Save icon.
6. Click the Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
317
Configuring DNS Services
Using a TSIG Key for Zone Transfers
You can use TSIG (transaction signature) keys to authenticate zone transfer requests and replies. The same key name
and key value must be on the primary and secondary name servers for TSIG-authenticated zone transfers to occur.
When using TSIG, it is important that both devices involved with the authentication procedure use NTP (Network Time
Protocol) for their time settings (see Using NTP for Time Settings on page 70).
You can use the key generation tool described in this section to create the TSIG key needed to secure transactions
between primary and secondary name servers. You can also enter an existing TSIG key, or click Generate to create
one.
Note: This TSIG function does not use GSS-TSIG (secure updates to Microsoft servers using a key from a Kerberos
server).
To generate a TSIG key at the grid level for a primary server:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Zone Transfers.
3. In the Allow TSIG Transfers for section, click Add, specify the following information, and then click OK:
— Key name: Enter a meaningful name for the key, such as a zone name or the name of the remote name
server with which the local server authenticates zone transfer requests and replies. This name must match
the name of the same TSIG key on other name servers that use it to authenticate zone transfers with the
local server.
— Key: To use an existing TSIG key, type or paste the key in the Key field.
— Generate: Click to create a new key.
— Use DNS One 2.x TSIG: Select check box when the other name server is an Infoblox device running DNS One
2.x code.
4. Optionally, you can:
— Modify a TSIG zone key: Select the member from the list and click Modify.
— Remove a TSIG key: Select the member from the list and click Remove.
— Move a TSIG key up the list: Select the member and click Move up. The member moves up the list
incrementally with each click of the button.
— Move a TSIG key down the list: Select the member and click Move down. The member moves down the list
incrementally with each click of the button.
5. Click the Save icon.
6. Click the Restart Services icon.
Specifying a Zone Transfer Format
The zone transfer format determines the BIND format for a zone transfer. This provides tracking capabilities for single
or multiple transfers and their associated servers.
To specify a zone transfer format:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid Properties editor, click Zone Transfers.
3. In the Allow TSIG Transfers for section, select one of the following options from the Zone Transfer Format
drop-down menu:
— Many Answers (Secondaries run BIND 8/9): includes as many records as the packet size allows
— Many Answers except for these Servers: includes as many records as the packet size allows
— One Answer (Secondaries run BIND 4): includes one record per packet
— One Answer except for these Servers: includes one record per packet
318
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Services
Note: If you select Many-Answers except for these Servers or One-Answer except for these Servers, enter the IP
address for the exception server and click Add.
4. Click the Save icon.
5. Click the Restart Services icon.
Establishing Zone Transfer Notify Messages
When requesting zone transfers from the primary server, some secondary DNS servers use the source port number
(the primary server used to send the notify message) as the destination port number in the zone transfer request. If
the primary server uses a random source port number when sending the notify message—that the secondary server
then uses as the destination port number when requesting a zone transfer—zone transfers can fail if there is an
intervening firewall blocking traffic to the destination port number.
You can specify a source port number for notify messages to ensure the firewall allows the zone transfer request from
the secondary server to the primary server. If you do not specify a source port number, the device sends messages
from a random port number above 1024. For information about specifying source port numbers for notify messages,
see Setting Source Port Settings on page 316.
Specifying DNS Queries
The inheritance feature allows you to specify grid configuration options, individual member options, network level
options, and zone level options. This allows you to specify options at the granular level, and override grid options.
For example, you can configure grid members to perform queries in a different way than the grid. You can configure
queries in the following ways:
•
•
Specifying Queries at the Grid Level
Specifying Recursive Queries for a Grid
Specifying Queries at the Grid Level
By default, queries are allowed from any address. You can specify restrictions on the allowed origins for queries, as
well as how queries are allowed.
If the query is recursive and the recursion option is enabled, the device queries other servers for the DNS data it
needs. A recursive query requires the device to return requested DNS data, or locate the data through queries to other
servers. For information about allowing recursion, refer to Specifying Recursive Queries for a Grid on page 320.
To allow queries at the grid level:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Queries.
3. In the Allow queries from section, click Add, enter the following address information for server from which
queries will be allowed or denied, and then click OK:
— IP Address: Enter an IP address
— Network: Enter a network IP Address, and select a Subnet mask from the drop-down menu (1-31).
— Any: Select to allow or deny queries from any IP address.
— Permission:
•
Allow: Select to allow queries from the specified source.
•
Deny: Select to deny queries from the specified source.
4. Optionally, you can:
— Modify server properties: Select the server from the list and click Modify.
— Remove server: Select the server from the list and click Remove.
— Move server up the list: Select the server and click Move up. The server moves up the list incrementally with
each click of the button.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
319
Configuring DNS Services
— Move a server down the list: Select the server and click Move down. The server moves down the list
incrementally with each click of the button.
5. Click the Save icon.
6. Click the Restart Services icon.
Note: You can also allow queries at the member level.
Specifying Recursive Queries for a Grid
When an Infoblox device receives a query for DNS data it does not have, it first sends a query to any specified
forwarders. If a forwarder does not respond and you have enabled recursive queries (and disabled the Use Forwarders
Only check box under Member DNS Properties -> Forwarders), the Infoblox device sends a recursive query to specified
internal root servers. If an internal root server is not configured, the device then sends a recursive query to the
Internet root servers. For more information on specifying root name servers, see Specifying Root Name Servers for a
Grid on page 321.
To configure recursive queries for a grid:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Queries.
3. Select the Allow recursion check box.
4. In the Allow recursive queries from section, click Add, enter the following address information for server from
which recursive queries will be allowed or denied, and then click OK:
— IP Address: Enter an IP address
— Network: Enter a network IP Address, and select a Subnet mask from the drop down menu (1-31).
— Any: Select to allow or deny recursive queries from any IP address.
— Permission:
•
Allow: Select to allow recursive queries from the specified source.
•
Deny: Select to deny recursive queries from the specified source.
5. Optionally, you can:
— Modify server properties: Select the server from the list and click Modify.
— Remove server: Select the server from the list and click Remove.
— Move server up the list: Select the server and click Move up. The server moves up the list incrementally with
each click of the button.
— Move a server down the list: Select the server and click Move down. The server moves down the list
incrementally with each click of the button.
6. Click the Save icon.
7. Click the Restart Services icon.
Setting the Source Port Number for Queries
Specifying a source port number for recursive queries ensures that a firewall will allow the response. If you do not
specify a source port number, the device sends these messages from a random port number.
When performing recursive queries, by default the Infoblox device uses a random source port number above 1024.
The queried server responds using the source port number in the query as the destination port number in its
response. If there is an intervening firewall that does not perform stateful inspection and blocks incoming traffic to
the destination port number, the recursive query fails.
For information on how to specify source port numbers for queries at the grid level, see Setting Source Port Settings
on page 316.
Note: You can also specify these settings at the member level.
320
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Services
Specifying Root Name Servers for a Grid
You can select to use internet root name servers, or specify custom root name servers by providing a host names and
IP addresses for the custom root servers.
If you enable recursive queries and the Infoblox device receives a recursive query for DNS data it does not have, it can
query internal root servers after querying any specified forwarders. If the Infoblox device does not receive a response
from the forwarders, and the Use Forwarders Only check box (under Forwarders in the Grid DNS Properties panel) is
not selected, the device sends the query to the internal root name servers that you specify. If you do not specify
internal root servers and the device can access the Internet, it queries the Internet root servers.
To assign a custom root name server:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Root Name Servers.
3. Select Use custom root name servers, and click Add.
4. Enter the following address information for the root name server:
— Host Name: Enter a name for the root name server.
— IP Address: Enter an IP address
5. Click OK. The server information appears in the Custom Root Servers field.
6. Optionally, you can:
— Modify server properties: Select the server from the list and click Modify.
— Remove server: Select the server from the list and click Remove.
— Move server up the list: Select the server and click Move up. The server moves up the list incrementally with
each click of the button.
— Move a server down the list: Select the server and click Move down. The server moves down the list
incrementally with each click of the button.
7. Click the Save icon.
8. Click the Restart Services icon.
Specifying Sortlists
A sortlist sorts the order of addresses in responses made to DNS queries. If a DNS lookup produces a response with
multiple addresses, the Infoblox device sorts the addresses, putting the addresses in the address match list first. If
no addresses match a query, the device sorts the addresses according to the address of the querier, putting the
addresses that match the querier first.
To configure a sortlist at the grid level:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Sortlist, and then click Add.
3. In the Sort List Item dialog, choose from the following:
— IP Address: Select radio button and enter the IP address to add to the sortlist. This is a single address with
a 32-bit netmask.
— Network: Enter a network IP Address to add to the sortlist, and select a Subnet mask from the drop-down
menu.
— Any: Select to add any address to the sortlist.
4. Click OK.
5. Optionally, you can:
— Modify the sortlist: Select an item from the list and click Modify.
— Remove an item from the sortlist: Select item from the list and click Remove.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
321
Configuring DNS Services
— Move an item up the list: Select the item and click Move up. The item moves up the list incrementally with
each click of the button.
— Move an item down the list: Select the item and click Move down. The item moves down the list
incrementally with each click of the button.
6. Click the Save icon.
7. Click the Restart Services icon.
Note: You can also define sortlists at the member level.
Using Forwarders with a Grid
A forwarder is essentially a name server that other name servers send all of their off-site queries to first. The forwarder
builds up a cache of information, avoiding the need for the other name servers to send queries off-site. The Infoblox
device can first send a query to a forwarder for DNS data it does not have in its cache and authoritative data, and can
work with one or more forwarders.
You can use forwarders to process all queries for off-site DNS data. This is useful in organizations that need to
minimize off-site traffic, such as a remote office with a slow connection to a company’s network.
If you activate the Use Forwarders Only check box in the Grid DNS Properties panel, the Infoblox device will only send
queries to forwarders, and not to other internal or Internet root servers.
To use a forwarder with a grid:
1. From the DNS perspective, click the DNS Members tab -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Forwarder.
3. Enter an IP Address in the text field, and then click Add. The IP address appears in the Forwarder text field.
4. To remove a forwarder, select the IP address from the Forwarder list, click Delete, and then click Yes.
5. To use only forwarders on your network (and not root servers), select the Use Forwarders Only check box.
6. Click the Save icon.
7. Click the Restart Services icon.
Using Forwarders with a Member
You can use forwarders with a grid member in the same way they are used with a grid.
To use a forwarder for a grid member:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click General.
3. Click the Override Grid Forwarder Settings check box.
4. Enter an IP Address in the text field, and then click Add. The IP address appears in the Forwarder text field.
5. To remove a forwarder, select the IP address from the Forwarder list, click Delete, and then click Yes.
6. Optionally, click the Use Forwarders Only check box to use only the specified forwarders on your network and not
root servers.
7. Click the Save icon.
8. Click the Restart Services icon.
322
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Zone Services
Specifying Minimal Response Returns
The Infoblox device allows you to specify the returning a minimal amount of data in response to a query. This
capability speeds up the DNS services provided by the device. This section covers how to turn this feature off and on.
To return minimal response data:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Grid DNS Properties.
2. In the General section of the Grid DNS Properties editor, select the Return Minimal Response check box.
3. Click the Save icon.
4. Click the Restart Services icon.
Disabling and Enabling DNS Service for a Grid Member
You can disable the DNS service for any grid member. Be aware that disabling DNS service for a member removes the
NS records from it. If you later re-enable DNS service for this member, the NS records are then restored.
To disable DNS service for a grid member:
1. Log in as the device administrator, or as a superuser.
2. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Grid DNS Properties.
3. In the General section of the Grid DNS Properties editor, clear the Enable DNS Server check box.
To re-enable the service, select the check box again.
4. Click the Save icon.
5. Click the Restart Services icon.
Configuring Additional IP Addresses for a Grid Member
The Infoblox device supports multiple IP addresses on the loopback interface. You can enable DNS service on
multiple addresses for any grid member. For more information about configuring multiple IP address and anycast
addressing, see Configuring IP Routing Options on page 339.
To configure DNS service on additional IP addresses for a grid member:
1. Log in as the device administrator, or as a superuser.
2. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> Edit -> Member DNS Properties.
3. In the General section of the Member DNS Properties editor, click Add to open up the Select Additional Listen On
Address dialog box
4. Select the additional IP address you want to DNS services enabled. If there are no additional IP addresses listed,
configure additional addresses as described in Configuring IP Addresses on the Loopback Interface on page 340.
Click OK.
5. Click the Save icon.
6. Click the Restart Services icon.
Configuring DNS Zone Services
You can configure settings for a zone, assign primaries and secondaries, and allow zone transfers. This section
explains how to specify primary and secondary servers, time to live settings, zone transfers, query lists, dynamic
updates, and Active Directory servers, and is organized in the following way:
•
•
•
Disabling Forwarding for a Zone on page 324
Specifying TTL Settings for a Zone on page 325
Changing the SOA Name for a Zone
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
323
Configuring DNS Services
•
•
•
•
Adding an E-mail Address to the SOA Record on page 326
Allowing Zone Transfers for a Zone on page 326
Allowing Query Access for a Zone on page 327
Supporting Active Directory on page 328
Disabling Forwarding for a Zone
You can disable forwarding for a zone, so the Infoblox device does not forward a query to another name server, for
data (it does not have) that is requested in the query. Instead, the device returns an error to the resolver that the
record does not exist.
To disable forwarding for a zone:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, select the Disable Forwarding check box.
3. Click the Save icon.
4. Click the Restart Services icon.
324
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Zone Services
Specifying TTL Settings for a Zone
TTL (time-to-live) is the time that a name server is allowed to cache data. After the TTL expires, the name server is
required to update the data. You can configure the TTL settings for a zone. Setting a high TTL reduces network traffic,
but also reduces the accuracy of your cached data. Conversely, setting a low TTL increases the accuracy of cached
data, but also increase the traffic on your network. There are five TTL settings, however, if you choose to configure one
setting you must also provide values for the other settings.
To specify TTL settings for a zone:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, select the Override Grid Settings radio button.
3. Specify the following values:
— Refresh Every: This interval tells the secondary how often to send a message to the primary for a zone to
check that its data is current, and retrieve fresh data if it is not. The default is three hours.
— Retry Every: This interval tells the secondary how long to wait before attempting to recontact the primary
after a connection failure between the two occurs. The default is one hour.
— Expire After: If the secondary fails to contact the primary for <expire> seconds, the secondary expires the
zone. This TTL setting defines the amount of time after which the secondary stops giving out answers about
the zone because the zone data is too old to be useful. The default is one week.
— Default TTL (Time to Live): This interval tells the secondary how long data can be cached.
— Negative TTL (Time to Live): This interval tells the secondary how long data can be cached for “Does Not
Respond” responses.
4. Click the Save icon.
5. Click the Restart Services icon.
Changing the SOA Name for a Zone
The Infoblox device allows you to change the SOA name that is automatically created when you initially configure a
zone. For example, you may want to hide the primary server for a zone. If your device is named dns1.zone.tld, and
for security reasons, you may want to show a secondary server called dns2.zone.tld as the primary server. To do
so, you would go to dns1.zone.tld zone (being the true primary) and change the SOA to dns2.zone.tld to hide
the true identity of the real primary server.
To change the SOA name for a zone:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, select the Set primary for SOA check box, and
then enter the new SOA name in the text field to its right.
3. Click the Save icon.
4. Click the Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
325
Configuring DNS Services
Setting the Serial Number in the SOA Record
The serial number in the SOA record incrementally changes every time the record is modified. This serial number
plays a key role when and how zone data is updated via zone transfers. For example, if a secondary server has a
higher serial number than the primary server, zone transfers would come from the secondary, not the primary server.
The Infoblox device allows you to change the serial number (in the SOA record) for the primary server so it is higher
than the secondary server, thereby ensuring zone transfers come from the primary server (as they should).
You have the option of using administrative style serial numbers instead of a simple counter. To do this, create a serial
number like: yyyymmddxx (such as 2004101843) where yyyy is the year, mm is the month, dd is the day of the month,
and xx is the edit number (so, in the example, we have made 43 changes on 10/18/2004).
To change the serial number in an SOA record:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, select enter one of the following:
—
Click the Increment serial number by check box, and then enter an increment number in the text field to the
right.
—
Click the Set serial number check box, and then enter a serial number in the text field to the right.
3. Click the Save icon.
4. Click the Restart Services icon.
Adding an E-mail Address to the SOA Record
You can add an administrator e-mail address to the SOA record to help people determine who to contact about this
primary zone.
To add an e-mail address to an SOA record:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Settings section of the Authoritative Zone Properties editor, enter an e-mail address in the E-mail Address
text field.
3. Click the Save icon.
4. Click the Restart Services icon.
Allowing Zone Transfers for a Zone
By default, the Infoblox device automatically performs zone transfers within a grid. However, you can configure the
device to allow zone transfers to an external DNS name server. Zones within a grid automatically receive updated
zone data via database replication that occurs over a secure SSL-based VPN.
Traditional zone transfers are only necessary when deploying devices with standard name servers, or devices that are
outside of the grid, such as an external Primary, or external Secondaries. This section only applies to external DNS
servers that are not grid members.
The Infoblox device allows the use of standards-based TSIG keys, that use the one-way hash function MD5 to secure
transfers between the primary and secondary name servers. Zones can override globally configured TSIG keys.
Note: This TSIG function does not use GSS-TSIG (secure updates to Microsoft® servers using a key from a Kerberos
server).
An NTP server should be used for the time settings on both devices that perform TSIG transfers. Adding a secondary
server creates a new NS record and allows ALL transfers, and therefore you must enable TSIG.
326
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Zone Services
Caution: If only one name server is enabled, it will appear both servers are sending current data, but the server
without TSIG enabled will send non-signed transfers.
To allow zone transfers to a zone:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Authoritative Zone Properties editor, click Transfers.
3. Click the Override Grid zone transfer settings check box.
Note: You can specify whether transfers are sent to a single address or a network. Use an IP address to designate
a single server, or use the network option for a range of addresses on a network.
4. To Allow zone transfers to a specified destination, click Add, do the following, and then click OK:
— Click the IP Address radio button, and enter a system IP address. Or, click the Network radio button, enter a
network address and Select a CIDR value from the drop-down menu for the Subnet Mask.
— Under Permission, click Allow or Deny, to allow or deny zone transfers to the specified destination.
5. To Allow TSIG transfers for a specified destination, click Add, do the following, and then click OK.
— Enter a Key name, such as a zone name or the name of the remote name server with which the local server
authenticates zone transfer requests and replies. This name must match the name of the same TSIG key on
other name servers that use it to authenticate zone transfers with the local server.
— Enter a Key, such as an existing TSIG key by typing or pasting it into the field, or click Generate to create a
new key.
— Click the Use DNS One 2.x TSIG check box when the other name server is an Infoblox device running DNS
One 2.x code.
For more information, refer to Authenticating Updates with TSIG on page 416.
6. Click the Save icon.
7. Click the Restart Services icon.
Allowing Query Access for a Zone
You can configure query properties for a zone, and query access for members and grids. By default, queries are
allowed from any source.
To specify query access for a zone:
1. From the DNS perspective, click + (for Infoblox Views) -> + (for view) -> + (for Forward-Mapping Zones,
IPv4 Reverse-Mapping Zones, or IPv6 Reverse-Mapping Zones) -> zone -> Edit -> Authoritative Zone Properties.
2. In the Authoritative Zone Properties editor, click Queries.
3. Click the Override Grid query zone settings check box.
4. In the Allow queries from field, click Add, and do the following:
Note: You can specify whether queries are allowed from a single address or a network. Use an IP address to
designate a single server, or use the network option for a range of addresses on a network.
— Click the IP Address radio button, and enter a system IP address. Or, click Network, enter a network IP
Address, and select a Subnet mask from the drop-down menu.
— Under Permission, click Allow or Deny to allow or deny zone transfers to the specified destination.
5. Click OK.
6. Click the Save icon.
7. Click the Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
327
Configuring DNS Services
Supporting Active Directory
Active Directory™ is a distributed directory service that authenticates network users and—by working with DHCP and
DNS—provides the location of and authorizes access to services running on devices in a Windows® network.
You can integrate an Infoblox device providing DHCP and DNS services with a Windows 2000 or 2003 server running
AD (Active Directory). Assuming that you already have AD set up and it is currently in use, you can migrate DHCP and
DNS services away from internal operations on the AD server or from other third party DHCP and DNS systems to
Infoblox DHCP and DNS servers. The basic DHCP, AD, and DNS services are shown in Figure 11.1.
Figure 11.1 DHCP, Active Directory, and DNS
Infoblox
DHCP Server
1
TCP/IP Network
Configuration Requests
Note: For clarity, the DHCP
and DNS servers are shown
on separate devices. A
single device can also
provide both services.
AD (Active Directory) Server and
Kerberos Server (for GSS-TSIG*)
2
AD/Kerberos
Connections
Infoblox
DNS Server
Clients
3
DNS Queries
and
DDNS Updates
* Clients can optionally use
GSS-TSIG (Generic Security
Service-Transaction
Signatures) to authenticate
DDNS updates.
Note: There are no special configurations to consider when providing DHCP services for a network using AD.
Consequently, the following content focuses on DNS. For information about configuring DHCP, see Chapter 14,
Configuring DHCP Services, on page 369 .
Clients sending DDNS (dynamic DNS) updates to a DNS server can authenticate the updates using GSS-TSIG (Generic
Security Service-Transaction Signatures). GSS-TSIG is a modified form of TSIG authentication that makes use of a
Kerberos server (running on the AD server) to act as a third-party authenticator. Microsoft® refers to this type of
authenticated DDNS update as a “secure dynamic update”.
When adding an Infoblox DNS server to an AD environment, you must configure the AD/Kerberos server and Infoblox
DNS server as follows—based on whether or not you want the DNS server to support DDNS updates using GSS-TSIG
authentication:
•
AD/Kerberos Server
1. Enable zone transfers to the Infoblox DNS server.
2. (For GSS-TSIG) Create a user account for the Infoblox DNS server that it can use for authentication.
3. (For GSS-TSIG) Export the DNS server keytab file and save it to your management system.
•
Infoblox DNS Server
4. (GSS-TSIG) Enable GSS-TSIG support.
5. (GSS-TSIG) Import the DNS server keytab file from your management system to the Infoblox device.
6. (GSS-TSIG) Enable GSS-TSIG authentication.
328
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Supporting Active Directory
7. Add a forward-mapping zone and give it a name matching the AD DNS zone whose resource records you
want to import.
8. Specify the DC (domain controller) from which you want to import zone data. A domain controller is an AD
server that replicates its data among other DCs within its AD domain and among DCs in other domains.
The Infoblox device automatically transfers zone data for the parent zone and the containers for its
subzones from the specified DC.
9. Enable the acceptance of DDNS updates from the AD server and from the DHCP clients/AD members whose
addresses the DHCP server assigns. You can set this at the grid, member, and zone levels.
10. (For GSS-TSIG) Enable acceptance of GSS-TSIG DDNS updates from the AD server and from the addresses
that the DHCP server assigns. You can set this at the grid, member, and zone levels.
As you can see from the above task list, adding an Infoblox DNS server to an AD environment without GSS-TSIG
support involves four simple steps. To include GSS-TSIG support, there are several additional steps.
Active Directory and Unauthenticated DDNS Updates
You can configure a forward-mapping zone to support AD (Active Directory) and receive unauthenticated DDNS
updates from DHCP clients/AD members.
Note: Before configuring the Infoblox DNS server, enable the AD server to permit zone transfers to the IP address of
the Infoblox device.
To create a forward-mapping zone with AD support:
1. From the DNS perspective, click the Infoblox Views tab > + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
Zones -> Edit -> Add Forward-Mapping Zone -> Authoritative.
2. In the Add Forward Authoritative Zone dialog box, enter the following:
Authoritative Zone Properties:
— Name: Type the name of the forward-mapping zone. This name must match the name in the AD server so
that the zone transfer from the AD server to the Infoblox device can succeed.
— Comment: Type a descriptive note for this zone.
— Disable this zone: (clear)
Primary Server Assignment:
— Select member: Choose the name of the local Infoblox device from the drop-down list, and then click OK.
Secondary Server Assignment:
— If the secondary DNS server is a member of the same grid as the local Infoblox device, click Add, and
choose its name from the drop-down list.
— If the primary and secondary DNS servers are not members of the same grid, click Add, type a resolvable
domain name and IP address in the Name and IP Address fields, and then click OK.
Updates:
— Override member update settings: (select)
— Allow dynamic updates from: Click Add, select IP Address, enter the IP address of the AD server (domain
controller) from which you want the Infoblox device to receive DDNS updates, select Allow, and then click
OK.
(If you want the Infoblox device to receive updates for this zone from multiple AD servers, add the IP
address for each name server individually.)
— Allow dynamic updates from: Click Add, select Network, enter the network address and netmask of the
DHCP clients/AD members from which you want the Infoblox device to receive DDNS updates, select Allow,
and then click OK.
— Allow GSS-TSIG clients to perform dynamic updates: (clear)
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
329
Configuring DNS Services
Zone AD Servers:
— Enable Active Directory support: (select)
— Domain Controllers: Click Add, enter the IP address of the domain controller (AD server) from which you
want to import AD-specific zone data, and then click OK.
Note: You can add IP addresses for multiple domain controllers.
— Automatically create underscore zones: (select)
This option automatically creates the following subzones that the DNS server must have to answer
AD-related DNS queries:
_msdcs.zone
_sites.zone
_tcp.zone
_udp.zone
domaindnszones.zone
forestdnszones.zone
3. Click the Save icon.
4. Click the Restart Services icon .
330
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Supporting Active Directory
Active Directory and GSS-TSIG-Authenticated DDNS Updates
You can configure a zone to support AD (Active Directory) and receive secure DDNS updates from clients using
GSS-TSIG (Generic Security Service-Transaction Signatures). GSS-TSIG involves a set of client–server negotiations to
establish a “security context”. Within this context, the client and server collaboratively create and mutually verify
transaction signatures on messages that they exchange. Windows 2000 systems and later support DDNS updates
using GSS-TSIG.
Note: For information about GSS-TSIG, see RFC 3645, Generic Security Service Algorithm for Secret Key Transaction
Authentication for DNS (GSS-TSIG).
GSS-TSIG makes use of the Kerberos v5 authentication system. Before configuring the Infoblox DNS server to support
GSS-TSIG, you must create a user account on the Kerberos server for the Infoblox device. Then you must export the
corresponding keytab file from the Kerberos server and import it onto the Infoblox device. The initial configuration
tasks are shown in Figure 11.2 on page 331.
Figure 11.2 Adding an Infoblox DNS Server to an AD Environment with GSS-TSIG Support
1
2
Add a user account
for the DNS server.
User Account
Export the keytab file for the DNS
server account from the Kerberos
server to a local directory on your
management system.
Keytab
File
Administrator’s
Management
System
AD (Active Directory)
Kerberos Server
3
4
Import the keytab file
to the DNS server.
Infoblox
DNS Server
Make a forward-mapping
zone and import zone
data from the AD server.
Note: Make sure that
zone transfers from the
AD server to the Infoblox
DNS server are enabled.
AD DNS
Zone
corp100.com
Import Zone Data
5
Optional: Make a
reverse-mapping
zone.
6
corp100.com
ForwardMapping
Zone
1.1.10.in-addr.arpa
ReverseMapping
Zone
Enable GSS-TSIG updates.
On an already functioning AD Server:
1. Add a user account for the Infoblox DNS server to the AD server. A corresponding account on the Kerberos server
is automatically created.
2. Export the keytab file for the Infoblox DNS server account from the Kerberos server to a local directory on your
management system.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
331
Configuring DNS Services
On an Infoblox device:
1. Import the keytab file from your management system to the Infoblox device.
2. Configure a forward-mapping zone with the same name as the AD zone, import the zone data from the AD server,
and enable GSS-TSIG updates at both the grid and member levels.
3. (Optional) Create a reverse-mapping zone for the network address space that corresponds to the domain name
space in the forward-mapping zone.
The process in which a DHCP client dynamically updates its resource records on a DNS server using GSS-TSIG
authentication is shown in Figure 11.3. The illustration also shows the relationship of the clients, the DHCP server,
the DNS server, and the Kerberos server (running on the AD server).
Note: For explanations of the alphanumerically notated steps in Figure 11.3, see the section following the
illustration.
Figure 11.3 Authenticating DDNS Updates with GSS-TSIG
DHCP Server
DNS Server
DHCP Client
AD Member
1
DHCP
AD (Active Directory) Server
Kerberos Server
a
b
Active
Directory
2
DNS
Query
3
Kerberos
4
a
b
a
b
a
b
c
d
a1
Unauthenticated DDNS
Update Attempt (Refused)
a2
DDNS
Update
5
b1
TKEY Negotiations
(GSS Handshake)
b2
c1
c2
c3
GSS-TSIG-Authenticated
DDNS Update (Accepted)
1. DHCP – IP Address and Network Parameters Assignment
a.
The DHCP client requests an IP address.
b. The DHCP server assigns an IP address, subnet mask, gateway address, DNS server address, and a domain
name.
332
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Supporting Active Directory
2. Active Directory – Computer and User Logins
a.
The computer automatically sends a broadcast to find the AD server and logs in.
Note: Computer accounts have passwords that the AD server and computer maintain automatically. There are
two passwords for each computer: a computer account password and a private key password. By default,
both passwords are automatically changed every 30 days.
b. The user manually logs in to a domain.
3. DNS – Query for the Kerberos Server
a.
The computer (or client ) automatically sends a query for _kerberos._udp.dc_msdcs.dom_name to the DNS
server whose IP address it received through DHCP.
b. The Infoblox DNS server replies with the IP address of the Kerberos server.
4. Kerberos – Login, and TGT and Service Ticket Assignments
a.
The client automatically logs in to the Kerberos server.
b. The Kerberos server sends the client a TGT (ticket-granting ticket).
c.
Using the TGT, the AD member requests a service ticket for the DNS server.
d. The Kerberos server replies with a service ticket for that server.
5. DDNS – Dynamic Update of the Client’s Resource Records
a.
Unauthenticated DDNS Update Attempt (Refused)
1. The client sends an unauthenticated DDNS update.
2. The DNS server refuses the update.
b. TKEY negotiations (GSS Handshake):
c.
1. The client sends the DNS server a TKEY (transaction key) request, which includes the service ticket.
The service ticket includes the client’s principal and proposed TSIG (transaction signature) key,
along with other items such as a ticket lifetime and a timestamp.
2. The DNS server responds with a DNS server-signed TSIG. The two participants have established a
security context.
GSS-TSIG-Authenticated DDNS Update (Accepted)
1. The client sends an authenticated DDNS update, which includes the following resource records:
• A – Address record, which maps a domain name to an IP address
or
PTR – Pointer record, which maps an IP address to a domain name
•
TKEY – Transaction Key record, which establishes shared secret keys for use with the TSIG resource
record. For more information, see RFC 2930, Secret Key Establishment for DNS (TKEY RR).
•
TSIG – A “meta-record” that is never cached and never appears in zone data, a TSIG record is a
signature of the update using an HMAC-MD5 hash that provides transaction-level authentication.
For more information, see RFC 2845, Secret Key Transaction Authentication for DNS (TSIG).
2. The DNS server authenticates the DDNS update and allows it to complete.
3. The DNS server sends a GSS-TSIG-authenticated response to the AD member, confirming the
update.
Note: For GSS-TSIG authentication to work properly, the Infoblox device must be set in the same time zone as the AD
server and their system clock times must be synchronized within five minutes of each other. One approach is
to use NTP on the Infoblox device and the AD server and point them both at the same NTP server.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
333
Configuring DNS Services
Enabling GSS-TSIG Support
Before you can see any GSS-TSIG options in the GUI, you must enable GSS-TSIG support by entering the following CLI
command:
Infoblox > set gsstsig
Enable GSS-TSIG option? (y or n): n
GSS-TSIG option enabled: Yes
is this correct? (y or n): y
You can access the Infoblox CLI by making a console connection or a remote SSH connection to the device. After
entering this command, you can see GSS-TSIG options in the GUI the next time you log in. If you are logged in to the
GUI at the same time that you enter the command, you must log out and then back in to cause the options to appear.
Creating an AD User Account
To create a user account for the Infoblox DNS server on the AD server, which automatically creates a corresponding
user account on the Kerberos server:
1. Connect to the AD server and make a user account for the Infoblox DNS server.
Note: The name you enter in the User logon name is the name that you later use when exporting the keytab file.
This is also the principal name. The text in the First name, Initials, Last name, and Full name fields is
irrelevant to this task.
2. The AD server automatically creates a Kerberos account for this user with an accompanying keytab.
If you define an expiration date for the user account and you later create a new account when the first one
expires, the keytab for the corresponding Kerberos account changes. At that point, you must update the keytab
file on the Infoblox device (see Exporting the Keytab File and Importing the Keytab File on page 335).
Optionally, if your security policy allows it, you can set the user account for the Infoblox DNS server so that it
never expires.
Exporting the Keytab File
To export the keytab file for the Kerberos account, use the Ktpass utility that is included in the Microsoft Windows
2000 Resource Kit:
•
Start a command prompt, and enter the following command to export the keytab file for the Infoblox DNS server
user account:
C:> Ktpass -princ service_name/FQDN_instance@REALM -mapuser AD_username -pass password
-out filename.keytab
For example:
C:> Ktpass -princ DNS/[email protected] -mapuser [email protected] -pass 37Le37
-out ns1.keytab
-princ = Kerberos principal
— DNS = service name in uppercase format
— ns1.corp100.com = instance in FQDN (fully-qualified domain name) format; this is the same as the DNS
name of the Infoblox device
— CORP100.COM = the Kerberos realm in uppercase format; this must be the same as the AD domain
name
-mapuser = Link between the Kerberos principal name to AD user name
— [email protected] = the AD user name for the Infoblox device
-pass = AD account password
— 37Le37 = the password of the user account for the Infoblox device
-out = exportation of the keytab file
— ns1.keytab = the name of the keytab file
334
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Supporting Active Directory
Note: The keytab file contains highly sensitive data for the Infoblox DNS server account. Store and transport its
contents securely.
Importing the Keytab File
To import the keytab file to the Infoblox device:
1. Log in to the Infoblox device.
2. From the DNS perspective, click DNS Members -> + (for grid ) -> member -> Edit -> Import GSS-TSIG Keytab File.
3. Navigate to the keytab file, select it, and then click OK.
Each time you export a keytab file from a Kerberos server running on Windows 2003, the version number
increases incrementally. Because the version number on the keytab file you import to the Infoblox device must
match the version in use on the Kerberos server, if you have exported multiple keytab files, select the last
keytab file exported from the Kerberos server. (A Kerberos server running on Windows 2000 does not increase
the version number of keytab files with each export.)
Modifying an AD User Account
To change any AD user account information (login, password, etc):
1. Remove the previous user account from AD.
2. Create a new user for GSS-TSIG mapping.
3. Generate a new keytab file.
4. Import the keytab file to the DNS server.
Enabling GSS-TSIG Authentication
Before you can enable GSS-TSIG authentication, make sure that the keytab file from the Kerberos account for the
Infoblox DNS server is loaded on the Infoblox device.
1. From the DNS perspective, click DNS Members -> + (for grid) -> member -> Edit -> Member DNS Properties.
2. Check the GSS-TSIG section of the Edit Member DNS Properties editor. If a principal name and version number
are listed, there is a keytab file loaded on the Infoblox device. Compare this information with that for the Infoblox
DNS server account on the Kerberos server to make sure that they match. If there is no keytab file on the Infoblox
device or if the loaded keytab file does not match that on the Kerberos server, you must load the correct keytab
file as explained in Exporting the Keytab File on page 334 and Importing the Keytab File.
To enable GSS-TSIG authentication at the grid and member levels:
1. From the DNS perspective, click DNS Members -> grid -> Edit -> Grid DNS Properties.
2. In the Updates section of the Edit Grid DNS Properties editor, select Allow GSS-TSIG clients to perform dynamic
updates .
3. Click the Save icon.
4. From the DNS perspective, click DNS Members -> + (for grid ) -> member -> Edit -> Member DNS Properties.
5. In the GSS-TSIG section of the Edit Member DNS Properties editor, select Enable GSS-TSIG authentication of
clients.
6. Click the Save icon.
7. Click the Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
335
Configuring DNS Services
Creating a Zone with AD and GSS-TSIG Support
To create a forward-mapping zone with AD and GSS-TSIG support:
1. From the DNS perspective, click the Infoblox Views tab > + (for Infoblox Views) -> + (for view ) -> Forward-Mapping
Zones -> Edit -> Add Forward-Mapping Zone -> Authoritative.
2. In the Add Forward Authoritative Zone dialog box, enter the following:
Authoritative Zone Properties:
— Name: Type the name of the forward-mapping zone. This name must match the name in the AD server so
that the zone transfer from the AD server to the Infoblox device can succeed.
— Comment: Type a descriptive note for this zone.
— Disable this zone: (clear)
Primary Server Assignment:
— Select member: Choose the name of the local Infoblox device from the drop-down list, and then click OK.
Secondary Server Assignment:
— If the secondary DNS server is a member of the same grid as the local Infoblox device, click Add, and
choose its name from the drop-down list.
— If the primary and secondary DNS servers are not members of the same grid, click Add, type a resolvable
domain name and IP address in the Name and IP Address fields, and then click OK.
Updates:
— Override member update settings: (select)
— Allow dynamic updates from: Click Add, select IP Address, enter the IP address of the AD server (domain
controller) from which you want the Infoblox device to receive DDNS updates, select Allow, and then click
OK.
(If you want the Infoblox device to receive updates for this zone from multiple AD servers, add the IP
address for each name server individually.)
— Allow dynamic updates from: Click Add, select Network, enter the network address and netmask of the
DHCP clients/AD members from which you want the Infoblox device to receive DDNS updates, select Allow,
and then click OK.
— Allow GSS-TSIG clients to perform dynamic updates: (select)
Zone AD Servers:
— Enable Active Directory support: (select)
— Domain Controllers: Click Add, enter the IP address of the domain controller (AD server) from which you
want to import AD-specific zone data, and then click OK.
Note: You can add IP addresses for multiple domain controllers.
— Automatically create underscore zones: (select)
This option automatically creates the following subzones that the DNS server must have to answer
AD-related DNS queries:
_msdcs.zone
_sites.zone
_tcp.zone
_udp.zone
domaindnszones.zone
forestdnszones.zone
3. Click the Save icon.
4. Click the Restart Services icon .
336
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Viewing DNS Files
Viewing DNS Files
There are three types of DNS files:
•
•
•
Viewing DNS Cache Files
Viewing a DNS Configuration File
Viewing DNS Zone Statistics
Viewing DNS Cache Files
You can view a DNS cache file for a grid and its member.
To view DNS cache files:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> View -> DNS Cache.
The cache file contents appears in the DNS Cache File viewer. Use the scroll bar to scroll through the contents of
a large cache file.
2. To clear the display, click the X on the DNS Cache File tab.
3. To refresh the cache file, click View -> Refresh.
4. To search within the cache file, click the magnifying glass icon, enter a search string in the dialog text field, and
then click Search.
5. To save a copy of the cache file for troubleshooting purposes, click the download icon, enter a file name, and then
click Save.
Viewing a DNS Configuration File
To view a DNS configuration file:
1. From the DNS perspective, click the DNS Members tab -> + (for grid ) -> member -> View -> DNS Configuration.
The configuration file contents appears in the DNS Config File viewer. Use the scroll bar to scroll through the
contents of the config file.
2. To clear the display, click the X on the DNS Config File tab.
3. To refresh the config file, select View -> Refresh.
4. To search within the file, click the magnifying glass icon, enter a search string in the dialog text field, and then
click Search.
5. To save a copy of the config file for troubleshooting purposes, click the download icon, enter a file name, and
then click Save.
Viewing DNS Zone Statistics
A zone statistics file provides BIND 9 statistics collected by the DNS Server. You can see grid counters and counters
per zone.
To view DNS statistics:
1. From the DNS perspective, click the Infoblox Views tab -> + (for Infoblox Views) -> + (for view ) -> + (for
Forward-Mapping Zones) -> zone -> View -> Zone Statistics.
2. To clear the display, click the X on the DNS Config File tab.
3. To refresh the config file, select View -> Refresh.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
337
Configuring DNS Services
338
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 12 Configuring IP Routing Options
You can enable and configure anycast addressing as well as configure multiple IP address on loopback interfaces on
the Infoblox device, allowing the device to function in different network deployments.
Configuring anycast on the device and within your network allows you to add redundancy and improve reliability for
DNS server queries. Configuring multiple IP addresses on the loopback interface assists in server migration, server
consolidation, or network address change.
You can also enable DNS services after configuring multiple IP addresses on a loopback interface on the device. For
more information about enabling DNS services on an interface, see Configuring Additional IP Addresses for a Grid
Member on page 323.
This chapter contains the following sections:
•
•
Multiple IP Addresses on an Interface on page 340
Anycast Addressing on page 342
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
339
Configuring IP Routing Options
Multiple IP Addresses on an Interface
You can configure one or more IP addresses on the loopback interface on the Infoblox device. This section discusses
the following topics:
•
•
•
•
IP Addressing on an Interface on page 340
Configuring IP Addresses on the Loopback Interface on page 340
Advertising Loopback IP Addresses to the Network on page 341
Configuration Example: Configuring IP Addresses on the Loopback Interface on page 341
IP Addressing on an Interface
You can configure multiple IP addresses on the loopback interface on the Infoblox device. Enabling multiple IP
addresses allows you to configure the loopback interface as the destination for DNS queries. Configuring multiple IP
addresses on the loopback interface is helpful in different scenarios, such as DNS server migration.
Consider the following scenarios where configuring multiple IP addresses on the loopback interface is beneficial:
•
Consolidation of DNS servers to a smaller number of servers: You can configure these different IP addresses for
multiple servers onto a single interface of an Infoblox device during migration to minimize any downtime for
users.
•
Change in the network addresses of DNS servers: You can configure the device interface with both the current
server IP address and the new IP address, minimizing any downtime during the migration to the new IP address.
•
Migration of DNS servers.
All three of the scenarios listed require a way to provide uninterrupted services during any change in the network.
Configuring multiple IP addresses to the loopback interface provides the administrator tools to provide continuous
service during server migration.
Configuring IP Addresses on the Loopback Interface
You can configure one or more IP addresses on the loopback interface of the device.
To configure an IP address on the loopback interface, perform the following tasks:
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties.
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section.
3. In the Advanced IP configuration section, click Add to open the Advanced IP Configuration dialog box and to
configure a new IP address onto the interface.
4. In the Advanced IP Configuration dialog box, enter the following information:
— Network Address: Enter the IP address you want to configure on the interface.
— Anycast: Select this check box to configure the IP address as an anycast address on the interface. If you do
not click this check box, the interface is configured as a non-anycast IP address. For more information on
configuring anycast addressing, see Configure an Anycast Address on an Interface on page 346.
— Bound Interface: Select which physical interface you want associated with the configured IP address.
Currently, the Infoblox device supports the loopback interface as the bound interface.
— Netmask: Use the drop-down list to specify the netmask for the interface. When you click the drop-down
list, the dialog box displays the choice of netmasks. The choices appear as Classless Inter-Domain Routing
(CIDR) notation of netmasks with the actual netmask bit representation appearing to the right of the
drop-down list once the choice is selected. You cannot change the netmask for a loopback interface. The
netmask is set to /32 by default.
— Comments: Enter a text string to help identify this interface and IP address.
340
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Multiple IP Addresses on an Interface
5. Click OK.
6. Click the Save icon.
To configure multiple IP addresses on the loopback interface, repeat the previous steps for each IP address you want
to add.
Note: If you are configuring the interface on a grid master, the grid will temporarily be disrupted upon saving the
configuration and restarting services on the device. The grid will reconnect and the device will regain the role
as grid master after this short delay automatically.
Advertising Loopback IP Addresses to the Network
Configuring multiple IP addresses on the loopback interface relies on the upstream router to populate routes to the
loopback interface.
If you are configuring non-anycast addresses on the loopback interface, or you are not running OSPF within your
network, you must configure the upstream router to reach the Infoblox device through a static route. Consult with your
network administrator for more information about configuring static routes from the router to the additional IP
addresses on the loopback interface.
Configuration Example: Configuring IP Addresses on the Loopback Interface
You can configure one or more IP addresses on the device interface. In this example, configure the following IP
addresses of the loopback interface on the device: 10.1.10.1/24, 10.1.10.2/24, and 10.16.1.1/24. The process
follows these steps:
Figure 12.1 Configuring an IP Address on an Interface
Query to 10.1.10.1/32
Query to 10.1.10.2/32
Infoblox device
Query to 10.16.1.1/32
Configure the device with the following IP
addresses on the loopback interface:
10.1.10.1/32
10.1.10.2/32
10.16.1.1/32
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties. The Edit Grid
Member editor appears in the GUI.
2. In the Edit Grid Member editor, click Advanced IP configuration to expand that section.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
341
Configuring IP Routing Options
3. In the Advanced IP configuration section, click Add. The Advanced IP Configuration dialog box appears in the GUI.
In the Advanced IP Configuration dialog box, enter the following settings:
— In the Network Address field, enter 10.1.10.1 as the IP address.
— In the Bound Interface field, the available section is the loopback interface. This option selects the interface
to configure.
— In the Netmask field, select the /32 from the drop-down list. This configures the address as 10.1.10.1/32.
— In the Comment field, enter Interface-1 as a description for this IP address.
4. Click OK.
5. Repeat steps 3-9 to configure 10.1.10.2/32 and 10.16.1.1/32 on the loopback interface of the Infoblox device.
6. Click the Save icon.
7. Enable DNS services for the additional IP addresses. For more information about enabling DNS services on an
interface, see Configuring Additional IP Addresses for a Grid Member on page 323.
Anycast Addressing
The infoblox device supports DNS services for anycast addresses on the loopback interface. This section provides
information on the following topics:
•
•
•
•
•
Network Communication Types on page 342
OSPF on page 344
Configure OSPF on an Interface on page 344
Configure an Anycast Address on an Interface on page 346
Configuration Example: Configuring Anycast Addressing on the Device on page 346
Network Communication Types
There are primarily four types of communication utilized within a network: unicast, broadcast, multicast, and anycast.
Each of the types of network communication are described in the following section, and focuses on anycast
addressing:
•
Unicast describes a one-to-one network communication between a single sender and a single recipient. The
routing protocol determines the path through the network from the sender to the recipient based on the specific
protocol or routing scheme. Unicast also describes the address type assigned to the recipient, used by the
routing protocol to determine the path to the recipient.
•
Multicast describes a one-to-many network communication between a single sender and a specific group of
recipients. All members within the group are intended recipients and each member receives a copy of the data
from the sender. Multicast also describes the address type assigned to the group of recipients, used by the
routing protocol to determine the path to the group.
•
Broadcast is similar to multicast, the exception being that data is sent to every possible destination regardless
of the groups or subnetwork. There is no specific group of recipients.
•
Anycast describes a one-to-nearest communication between a single sender and the nearest recipient within a
group. The routing protocol chooses one recipient within a target group based on the routing algorithm for the
specific protocol, and sends data to that recipient only.
342
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Anycast Addressing
Network routers use routing protocols such as the (OSPF) Open Shortest Path First to determine the best path to the
nearest server. The Infoblox device advertises the route information to the upstream router, a router that forwards
data on the network link and determines the forwarding path to destinations. To enable anycast for DNS queries, you
configure two or more DNS servers with the same anycast address on the loopback interfaces. When a DNS query is
sent to this IP address, the nearest server within the group of servers configured with the IP address responds to the
DNS query. In the case where the nearest server becomes unavailable, the next nearest server responds to the query.
From the client perspective, anycasting is transparent and the group of DNS servers with the anycast address appears
to be a single server.
Figure 12.2 Anycast Addressing
DNS Server
europe.corp100.com
10.128.1.12
A routing protocol usually determines
the nearest server.
In this example, the nearest DNS
server is the Europe server, since the
client is located in Europe.
DNS Query
DNS Server
america.corp100.com
DNS Query (example:
nslookup)
10.128.1.12
Internet
Client
europe.corp100.com
DNS Server
asia.corp100.com
10.128.1.12
Anycast:In this example, the desktop sends a DNS query
to 10.128.1.12, the anycast address. Many servers
possess the anycast address. The routing protocol
selects the nearest server and the desktop queries that
server. The nearest server sends back a response after
receiving the query.
DNS Server
australia.corp100.com
10.128.1.12
Anycasting for DNS provides the following benefits:
•
Improved Reliability: Anycast provides improved reliability because DNS queries are sent to an anycast IP
address configured on multiple DNS servers. If the nearest server is offline, then the next DNS server with the
anycast IP address responds to the query.
•
Load Balancing: Anycast provides load balancing for DNS queries and responses across multiple DNS servers.
•
Improved Performance: Infoblox device uses routing protocol algorithms (such as OSPF) to advertise anycast
routing information to the upstream router. Upstream router determine the best route to the nearest DNS
server. Anycast enables the queries to reach the nearest server faster, as well as providing faster responses to
queries.
The Infoblox device provides the following support for DNS anycast:
•
You can configure up to ten anycast IP addresses for each grid member.
•
The device advertises routing information through OSPF. OSPF determines the nearest server to send DNS
queries.
•
The device advertises and withdraws route information based on reachability information to DNS servers sent
by OSPF route advertisements. OSPF uses routing algorithms to determine the best path to servers.
For more information about anycast addressing, see RFC 1546 “Host Anycasting Service”.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
343
Configuring IP Routing Options
OSPF
The OSPF routing protocol is a link-state protocol based on the Dijkstra algorithm used to calculate the shortest path
to a destination address. This protocol uses a link-state database created using routing information advertised from
neighbors and peers, each with costs based on the state of that link to the destination.
The Infoblox device uses the OSPF routing protocol to advertise routes for an anycast address on the device to the
upstream router. The upstream router uses the OSPF advertisements to determine the nearest server from a group
of servers. The upstream router then can forward the query to the chosen DNS server.
Routers uses this OSPF route advertisement to determine which of a group of DNS server is the nearest server. The
sender queries the chosen DNS server only. In practicality, the Infoblox device relies upon OSPF to determine the best
route for DNS queries to take to the nearest DNS server.
OSPF network topologies consist of administrative domains called OSPF areas. An area is a logical collection of OSPF
routers, servers and other network devices that have the same area identifier. A router within an area keeps an OSPF
database for its OSPF area only, reducing the size of the database that is maintained.
You can configure authentication for OSPF advertisements to ensure that the routing information received from a
neighbor is authentic and the reachability information is accurate.
To enable the device to support OSPF and advertising anycast addresses, you must configure the LAN(HA) interface
as an OSPF advertising interface.
Note: If the device is part of an HA pair, the HA interface is chosen. If the device is not part of an HA pair, the LAN
interface is chosen.
For more information about the OSPF routing protocol, see RFC 2328 “ OSPFv2”.
Configure OSPF on an Interface
You can configure the LAN(HA) interface on the device as an OSPF advertising interface. The interface advertises the
OSPF routing information out to the network so that routers can determine the best server to query. For the Infoblox
device, you must configure the LAN(HA) interface as an OSPF advertising interface, and assign an area ID on the
interface to associate it with a specific area. The advertising interface sends out routing advertisements about the
anycast address into the network out to upstream routers.
Note: You must configure an OSPF advertising interface on the device to support anycast addressing.
To configure an interface to be an OSPF advertising interface, perform the following tasks:
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties.
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section. All of the
addresses configured on interfaces are displayed the Advanced IP configuration section.
3. In the OSPF Area Configuration section, click Add to open the OSPF Area Configuration dialog box.
344
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Anycast Addressing
4. In the OSPF Area Configuration dialog box, enter the following information to configure the LAN(HA) interface as
the OSPF advertising interface:
— Advertising Interface: Select the interface that sends out OSPF routing advertisements from the drop-down
list. OSPF advertisements are supported on the LAN(HA) interface only.
— Area ID: Enter the OSPF area identifier of the network containing the upstream routers, in either an IP
address format or a decimal format. All network devices configured with the same OSPF area ID belong to
the same OSPF area. The area ID configured on the grid member must match the area ID of the upstream
router configuration.
— Area Type: Select the type of OSPF area to associate with the advertising interface from the drop-down list.
The area type configured on the grid member must match the area type of the upstream router
configuration. The supported area types are described as follows:
— Standard: A standard area has no restrictions on routing advertisements, and connects to the
backbone area (area 0) and accepts both internal and external link-state advertisements.
— Stub: A stub area is an area that does not receive external routes.
— Not-so-stubby: A not-so-stubby area (NSSA) imports autonomous system (AS) external routes and
sends them to the backbone, but cannot receive AS external routes from the backbone or other areas.
— Authentication Type: Select the authentication method to use to verify OSPF routing advertisements on the
interface. The authentication type configured on the grid member must match the authentication type of
the upstream router configuration. The supported authentication types are described as follows:
— None: No authentication for OSPF advertisement.
— Simple: A simple password for OSPF advertisement authentication, in clear text.
— Message-Digest: An MD5 hash algorithm to authenticate OSPF advertisements. This is the most secure
option.
— Authentication Key ID: Enter the key identifier to use to specify the correct hash algorithm after you select
Message-Digest as your OSPF authentication type. The authentication key ID configured on the grid
member must match the authentication key ID of the upstream router configuration.
— Authentication Key: Enter the authentication password to use to verify OSPF advertisements after you select
Simple or Message-Digest as your OSPF authentication type. Specify a key string between 1 to 8 characters
for Simple authentication, and a string between 1 to 16 characters for MD5 authentication. The
authentication key configured on the grid member must match the authentication key of the upstream
router configuration.
— Retype Authentication Key: Reenter your authentication password for verification.
— Automatically Calculate Cost: Select this check box to auto generate the cost to associate with the
advertising OSPF interface to the device. If this check box is not selected, then you specify the cost value
explicitly. Calculate the cost as 100,000,000 (reference bandwidth) divided by the interface bandwidth. For
example, a 100Mb interface has a cost of 1, and a 10Mb interface has a cost of 10.
— Cost: Enter the cost to associate with the advertising OSPF interface to the device.
— Hello Interval: Specify how often to send OSPF hello advertisements out from the device interface, in
seconds. Specify any number from 1 through 65,535. The default value is 10 seconds. The hello interval
configured on the grid member must match the hello interval of the upstream router configuration.
— Dead Interval: Specify how long to wait before declaring that the device is unavailable and down, in
seconds. Specify any number from 1 through 65,535. The default value is 40 seconds. The dead interval
configured on the grid member must match the dead interval of the upstream router configuration.
— Retransmit Interval: Specify how long to wait before retransmitting OSPF advertisements from the interface,
in seconds. Specify any number from 1 through 65,535. The default value is 5 seconds. The retransmit
interval configured on the grid member must match the retransmit interval of the upstream router
configuration.
— Transmit Delay: Specify how long to wait before sending an advertisement from the interface, in seconds.
Specify any number from 1 through 65,535. The default value is 1 second. The transmit interval configured
on the grid member must match the transmit interval of the upstream router configuration.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
345
Configuring IP Routing Options
5. Click OK.
6. Click the Save icon.
From the Grid perspective, click grid -> Members -> grid_member. You can view the OSPF service status in the Detailed
Status dialog box.
Configure an Anycast Address on an Interface
You can configure anycast addressing on the loopback interface of the device by doing the following tasks:
•
Configure an IP address on the loopback interface
•
Specify the address as an anycast address.
Note: Anycast addressing is supported on the loopback interface only. All other interfaces are greyed out under the
Bound Interface drop-down list when you select the Anycast check box.
To enable and configure anycast addressing on the loopback interface, perform the following tasks:
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties.
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section. All of the
additional IP addresses configured on interfaces are displayed the Advanced IP configuration section. If you do
not see any entries, there is no configured IP addresses on the device.
3. In the Advanced IP Configuration dialog box, enter the following information:
— Network Address: Enter the IP address you want to assign as the anycast address on the loopback interface.
Specify a 32-bit IPv4 address.
— Anycast: You must select this check box to configure the IP address as an anycast address on the interface.
— Bound Interface: Anycast addressing is supported on the loopback interface only. All other interfaces
greyed out under the Bound Interface drop-down list when you select the Anycast check box.
— Netmask: You cannot change the netmask for a loopback interface. The netmask is set to /32 by default.
— Comments: Enter a text string to help identify this interface and IP address.
4. Click OK.
5. Click the Save icon.
Configuration Example: Configuring Anycast Addressing on the Device
The Infoblox device supports anycast addressing on the loopback interface. Configure the anycast IP address
(10.1.100.10O) on the loopback interfaces on both of the Infoblox devices.
The process follows these steps:
•
•
•
•
346
Configuring the LAN(HA) interface as an OSPF Advertising Interface on page 347
Configuring the Anycast Address on the Loopback Interface on page 347
Configuring DNS services on the Anycast Address on the Loopback Interface on page 347
Configuring Anycast Addressing on the Upstream Router on page 348
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Anycast Addressing
Configuring the LAN(HA) interface as an OSPF Advertising Interface
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties.
2. In the Edit Grid Member editor, click Advanced IP configuration to open the configuration section.
3. In the OSPF Area Configuration section, click Add. The OSPF Area Configuration dialog box appears in the GUI.
4. In the OSPF Area Configuration dialog box, enter the following information:
— Advertising Interface: Select LAN(HA) from the drop-down list.
— Area ID: Enter 1 as the OSPF area ID. Make sure you configure the same ID on the LAN(HA) interface of the
second Infoblox device.
— Area Type: Select Standard from the drop-down list to configure the LAN(HA) interface as part of a standard
OSPF area.
— Authentication Type: Select Simple from the drop-down list to enable simple keyword authentication for
OSPF advertisements.
— Authentication Key: Enter your simple password to use for OSPF authentication. For this example, enter
“0123456’ as your simple password.
— Retype Authentication Key: Reenter your authentication password for verification.
— Automatically Calculate Cost: Select this check box to auto generate the cost to associate with the
advertising OSPF interface to the device.
— Hello Interval: Specify 10 seconds.
— Dead Interval: Specify 40 seconds.
— Retransmit Interval: Specify 5 seconds.
— Transmit Delay: Specify 1 second.
5. Click OK.
6. Click the Save icon.
Configuring the Anycast Address on the Loopback Interface
1. From the Grid perspective, click grid -> Members -> grid_member -> Edit -> Member Properties. The Edit Grid
Member editor appears in the GUI.
2. In the Edit Grid Member editor, click Advanced IP configuration to expand that section.
3. In the Advanced IP configuration section, click Add. The Advanced IP Configuration dialog box appears in the GUI.
4. In the Network Address field, enter 10.1.100.100 as the anycast IP address.
5. Select the Anycast check box to specify the IP address as an anycast address. After selecting the check box, all
other configurable options become inaccessible. Anycast is supported on the loopback bound interface only.
6. Click OK.
7. Repeat steps 3-6 to configure the anycast address on the other Infoblox device.
8. Click the Save icon.
Configuring DNS services on the Anycast Address on the Loopback Interface
Enable DNS service for the anycast address by specifying it as part of the grid member configuration. This allows the
anycast address to participate in DNS service. For information about DNS services on additional IP addresses for a
grid member, seeConfiguring Additional IP Addresses for a Grid Member on page 323.
Note: You must enable the DNS service to listen to the configured anycast address for anycast to function properly.
Without doing this, you will not see OSPF advertising routes to the DNS server.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
347
Configuring IP Routing Options
Configuring Anycast Addressing on the Upstream Router
You can configure the upstream router to accommodate the anycast configuration on the Infoblox device. The router
configuration must specify the same values as the anycast configuration of the Infoblox device for the following
options in order for the upstream router to advertise routes to the anycast address:
•
Hello interval
•
Dead interval
•
Authentication Type
•
MD5 authentication key and key ID (if MD5 authentication is used)
•
Area ID
•
Area Type
For example, the hello interval in the router configuration must match the hello interval value in the device
configuration.
The following shows a compatible vendor router configuration to accommodate our anycast configuration example:
interface Ethernet0/0
ip address 192.168.1.131 255.255.255.0
ip ospf message-digest-key 1 md5 keyabcde
ip ospf hello-interval 10
ip ospf dead-interval 40
!
router ospf 151
network 192.168.1.0 0.0.0.255 area 0.0.0.0
area 0.0.0.0 authentication message-digest
!
348
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 13 Managing DHCP Data
This chapter contains the following topics that explain how to configure DHCP data:
— Configuring a DHCP Network on page 350
— Adding a Network on page 350
— Splitting a Network into Subnets on page 351
— Expanding/Joining a Network on page 353
— Adding a Shared Network on page 355
— Modifying a Network on page 355
— Removing a Network on page 355
— Enabling and Disabling a Network on page 356
— Configuring IP Addresses and Address Ranges on page 356
— Adding a Fixed Address on page 356
— Adding a DHCP Range on page 357
— Using Templates on page 358
— Using the Recycle Bin on page 366
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
349
Managing DHCP Data
Configuring a DHCP Network
When you configure an Infoblox device to provide DHCP services, you must define the network that it serves. After
you create a network, you can then create all the subnetworks individually or you can create a parent network that
encompasses all the subnetworks, and then use the Infoblox split network feature to create the individual
subnetworks automatically. In addition to splitting a network, you can also create a shared network for subnets that
are on the same network segment. This section explains how to first create a network and split it into subnetworks,
and then how to create a shared network, in the following subsections:
•
•
•
•
•
•
•
Adding a Network or Splitting a Network into Subnets on page 351
Splitting a Network into Subnets on page 351
Expanding/Joining a Network on page 353
Adding a Shared Network on page 355
Modifying a Network on page 355
Removing a Network on page 355
Enabling and Disabling a Network on page 356
Adding a Network
You can add a network using the following procedure or using a network template (see Adding a Network Using
Templates on page 363).
You must define the network of the DHCP server. You must also assign at least one device to a network. If devices are
in a grid, you must specify at least one grid member that serves DHCP for the network. Multiple grid members can
serve a network. If the server is an independent device, you must specify this device as the member that serves the
network.
To add a network:
1. From the DHCP and IPAM Perspective, select Networks -> Networks -> Edit -> Add Network -> Network.
2. In the Add Configure Networks editor, enter the following the Network Properties section:
— Address: Enter the IP address of the network.
— Netmask: Select the appropriate subnet mask for the network.
— Comment: You can enter useful information about the network, such as the name of the organization it
serves.
— Disable this network: Select this check box if you do not want the DHCP server to serve DHCP for this
network. This is useful when you are in the process of setting up the DHCP server. Clear this check box after
you have configured the server and are ready to have it serve DHCP for this network.
— Automatically create a reverse-mapping zone: Select this check box if you want the device to automatically
create the corresponding reverse-mapping zone for the network.
3. Click Member Assignment to expand the Member Assignment section.
4. Click Add.
5. Choose the grid member(s) that should serve DHCP for this network from the Select Grid Members dialog box.
Keep in mind, DHCP properties are inherited from this member. The network can be served by multiple members.
6. Click OK to close the Select Grid Members dialog box.
350
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring a DHCP Network
7. You can then override settings at the grid and member levels and enter unique settings for the network, as
described in each of the following sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
— Setting Watermark Properties on page 426
8. Click the Save icon.
9. Click the Restart Services icon.
Splitting a Network into Subnets
Once you have created a network for DHCP, you can configure smaller subnetworks with larger netmasks. A larger
netmask defines a larger number of network addresses and a smaller number of host addresses. You can split the
parent network into multiple smaller networks, without configuring each of the newly-created networks.
These subnetworks inherit the addressing properties of the parent network, such as member assignments. The
exceptions are the default router and broadcast address configuration. The default router and broadcast address
configuration for address ranges and fixed address are disabled by default after splitting a network. You can enable
these properties explicitly for each subnetwork after splitting the parent network.
To split a single network into multiple smaller subnets with larger netmasks:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks ) -> network -> Edit -> Split Network.
2. In the Split Network dialog box, enter the following:
— Use the subnet mask slider to specify the appropriate subnet masks for each subnet. When you move the
slider, the device displays the number of subnets and IP addresses within that subnet.
— Immediately add: Select either Only networks with fixed address and ranges or All possible subnetworks.
Note that when you add a large number of networks, the device could take a little longer to display the
networks.
— Select the Automatically create reverse-mapping zones check box to enable reverse-mapping zones for the
subnets. A reverse-mapping zone is an area of network space for which one or more name servers have the
responsibility for responding to address-to-name queries.
3. Click OK to close the Split Network dialog box.
4. Click the Save and Restart Services icon.
After you split the parent network, you can select each one and configure parameters for each subnetwork.
Note: The default router and broadcast address configurations are invalid after splitting a network. These
configurations are disabled by default.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
351
Managing DHCP Data
Configuration Example: Splitting a Network
In Figure 13.1, The administrator of a corporate network, Sales-group1 10.0.0.0/16, plans to split the domain into
smaller subnetworks. Creating multiple subnetworks allow the administrator to plan for expansion and growing traffic
for the company. The administrator wants to split the parent network into smaller separate networks for the different
regional sales offices within the company. The parent network is a /16 network with up to 65,536 possible addresses.
After the split, the administrator has up to 256 subnetworks, each with 256 possible addresses available.
The NIOS configuration follows these steps:
Figure 13.1 Splitting a Network
Subnetworks
(each with 256 possible addresses)
Europe-sales
10.0.0.0/24
Not Inherited:
- Default Router
- Broadcast Address
Parent Network
(with 65,536 possible addresses)
Inherited:
S-America-sales
10.0.0.0/24
Parent Network parameters:
- Lease time settings
- Member assignments
- BOOTP configuration of the
Parent Network
- Lease time settings
- Member assignmentsk
- DNS Server configuration of the Parent
Network
Sales-group1
10.0.0.0/16
- BOOTP configuration of the Parent
Network
Split into 256 Subnetworks
- Email Server configuration of the
Parent Network
...
- DNS Server configuration of the
Parent Network
All other parameters including:
- Email Server configuration of the Parent
Network
- Default Router
- Broadcast Address
Asia-sales
10.0.0.0/24
N-America-sales
10.0.0.0/24
Each of the subnetworks inherit the
parameters of the 10.0.0.0/16 Parent Network
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks ) -> 10.0.0.0/16 -> Edit -> Split Network.
2. In the Split Network dialog box, confirm that the Network field displays the 10.0.0.0 network. This is the network
you are splitting into smaller subnetworks. Enter the following:
— Use the Subnetworks mask slider to select the /24 subnet mask, configuring each of the newly-created
subnetworks with a /24 netmask. When you move the slider, the device displays the number of subnets
and IP addresses within that subnet. Confirm that there are up to 256 subnetworks possible, each with up
to 256 addresses.
— Immediately add: Select Only networks with fixed address and ranges. Only networks with fixed addresses
configured are split.
— Select the Automatically create reverse-mapping zones check box. This enables reverse-mapping zones for
the subnets.
3. Click OK to close the Split Network dialog box.
352
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring a DHCP Network
4. Click the Save and Restart Services icon.
5. From the DHCP and IPAM Perspective, select Networks -> + (for Networks ) -> 10.0.0.0/16 to verify that the
newly-created subnetworks are created.
6. Select any of the newly-created subnetworks-> Edit -> Network properties to view the properties for that particular
subnetwork. The properties are identical to the parent network (10.0.0.0/16) configuration except for broadcast
address and default router, which are disabled by default.
Expanding/Joining a Network
Expanding/joining multiple networks into a larger network is the opposite of splitting a network. You can select a
network and expand it into a larger network with a smaller netmask. A smaller netmask defines a smaller number of
network addresses while accommodating a larger number of host addresses. Expanding a network allows you to
consolidate all of the adjacent networks into the expanded network. Adjacent networks are all networks falling under
the netmask of the newly-expanded network. Each of the adjacent networks join the expanded network and inherit
the DHCP member configuration options of the selected network.
Note: The expanded network does not inherit the default router and broadcast address configurations of the
adjacent networks. Those configurations are disabled by default.
Note: The member assignment for the expanded network combines all member assignments of the joining
networks.
To expand/join a network:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks ) -> network -> Edit -> Expand/Join
Network. The Expand/Join Network dialog box appears with network address and netmask fields populated with
the current settings based on the smaller adjacent network’s configuration. The new expanded network inherits
the DHCP settings of the network selected in this step.
2. In the Expand/Join Network dialog box, select the following:
— Use the netmask drop-down list to specify the available subnet masks for the new expanded network.
Select a smaller netmask value based on your requirements of the new expanded network. When you click
the drop-down list, the dialog box displays the choice of subnet masks for the new expanded network. The
choices appear as Classless Inter-Domain Routing (CIDR) notation of netmasks with the actual netmask bit
representation appearing to the right of the drop-down list once the choice is selected.
— Immediately add: Select Automatically create reverse-mapping zones if you want to configure the expanded
network to support reverse-mapping zones. A reverse-mapping zone is an area of network space for which
one or more name servers have the responsibility for responding to address-to-name queries. For more
information about reverse-mapping zones, see Creating an Authoritative Reverse-Mapping Zone on page
266.
Note: You can configure a reverse-mapping zone only if the selected network is a classful network. A classful
network is a network configured with a /8, /16/or /24 netmask.
3. Click OK to close the Expand/Join Network dialog box.
4. Click the Save and Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
353
Managing DHCP Data
Note: Expanding a network removes the network from the list of shared networks.
Configuration Example: Expanding/Joining Networks
In Figure 13.2, The administrator of a network wants to consolidate all of the /24 engineering department networks
within the company into a single larger network. The administrator is planning a migration to another server and
wants to consolidate for help with the migration. There are four adjacent networks to consolidate, all falling under the
larger planned /16 network: QA1-company1 10.10.0.0/24, Dev-company1 10.11.0.0/24, Syst-company1
10.12.0.0/24, and QA2-company1 10.13.0.0/24. The resulting expanded network will be a /16 network with up to
65,536 possible addresses, inheriting the network properties of the Dev-company1 10.11.0.0/24 network.
The NIOS configuration follows these steps:
Figure 13.2 Expanding/Joining a Network
Subnetworks
(each with 256 possible addresses)
QA1-company1
10.10.0.0/24
Expanded Network
(with 65,536 possible addresses)
Join
Subnetwork parameters:
Not Inherited:
- Lease time settings
- Default Router
- Member assignments
- DNS Server configuration of
the Parent Network
- BOOTP configuration of the
Parent Network
- Email Server configuration of
the Parent Network
- Broadcast Address
Dev-company1
10.11.0.0/24
Inherited:
Expand
Eng-company1
10.0.0.0/16
Subnetwork selected
to expand
All other parameters including:
- Lease time settings
- Member assignments
- Default Router
All of the subnetworks join the
expanded address space
- Broadcast Address
- DNS Server configuration of the
Parent Network
- BOOTP configuration of the
Parent Network
- Email Server configuration of
the Parent Network
Join
Syst-company1
10.12.0.0/24
Join
The Expanded Network inherits the
parameters of the selected 10.11.0.0/24
Subnetwork
QA2-company1
10.13.0.0/24
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks ) -> 10.11.0.0/24 -> Edit -> Expand/Join
Network.
2. In the Expand/Join Network dialog box, confirm that the Network field displays the 10.11.0.0 network. This is the
network you are expanding. Enter the following:
— Use the Netmask slider to select the /16 subnet mask, configuring the newly-expanded network with a /16
netmask. When you move the slider, the device displays the netmask for the selected subnet. Confirm that
the netmask for /16 shows 255.255.0.0. All networks falling under the /16 netmask joins the
newly-expanded network.
354
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring a DHCP Network
— Select the Automatically create reverse-mapping zones check box. This enables reverse-mapping zones for
the subnets.
3. Click OK to close the Expand/Join Network dialog box.
4. Click the Save and Restart Services icon.
5. From the DHCP and IPAM Perspective, select Networks -> + (for Networks ) -> 10.0.0.0/16 -> Edit -> Network
properties to view the properties for the newly-expanded network. All of the properties are identical to the
network selected (10.11.0.0/24), except for the broadcast address and default router.
Adding a Shared Network
You can create a shared network when two subnets share a particular network segment. Before creating a shared
networks, you must first create the subnetworks. For example, you must first create the networks 10.32.1.0 and
10.30.0.0 before designating them as a shared network.
To add a shared network:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Shared Networks ) -> Edit -> Add Network -> Shared
Network.
— Shared Network Name: Enter a name for the shared network.
2. Click Add to open the Select Networks dialog box.
3. Select one of the networks, and then click OK to close this dialog box.
4. Repeat the preceding steps to add the second network.
5. You can then override settings at the grid and member levels and enter unique settings for the network, as
described in each of the following sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
6. Click the Save icon.
7. Click the Restart Services icon.
Modifying a Network
You can modify existing network settings, with the exception of the network address and subnet mask. To modify a
network, shared network, or subnet, select the item you want to modify and click Edit -> Network Properties. Click the
Save icon and the Restart Services icon after you make a change.
Removing a Network
When you remove a network, its data—including all of its DHCP records, subnetworks, and records in its
subnetworks—is erased from the database. Because of the potentially large loss of data that can occur when you
remove a network, the Infoblox device requires a double confirmation of its removal. Instead of removing a network,
you can disable it.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
355
Managing DHCP Data
Enabling and Disabling a Network
The Infoblox device allows you to disable and enable currently existing networks instead of removing them from the
database. This feature is especially helpful when you have to move or repair the server for a particular network.
To disable a network or subnetwork:
1. Select the network you want to disable.
2. Click Edit -> Network Properties.
3. In the Network Properties section of the Network editor, select the Disable this network check box.
4. Click the Save and Restart Services icons.
Configuring IP Addresses and Address Ranges
Once you have created the networks for your organization, you are ready to define either fixed address or address
ranges in those networks. Address ranges specify which IP addresses clients can lease. You can configure fixed
addresses for network resources, such as servers and printers.
For additional information about these tasks, see the following sections:
•
•
•
Adding a Fixed Address
Adding a DHCP Range on page 357
Excluding Addresses from an Address Range on page 357
Adding a Fixed Address
After you define your networks, you can assign fixed addresses to certain resources, such as printers and faxes.
To assign a fixed address:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> Edit -> Add Fixed Address.
2. Enter the following:
— IP Address: Enter the IP address you are assigning to the host.
— Allocate address dynamically: Select this option if you want to assign DHCP options to a device with a
dynamically assigned IP address. If you select this option, do not enter an IP address, but enter a MAC
address, so you specify DHCP options for a specific MAC address, while allowing the device to receive a
dynamic IP address.
— MAC Address: Enter the MAC address of the host.
— Comment: You can enter useful information about the host, such as the type of resource.
— Disable this fixed address: Select this check box if you do not want the DHCP server to allocate this IP
address.
3. You can then override settings at the network level and enter unique settings for the IP address, as described in
each of the following sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
— Applying Device Classifications on page 422
4. Click the Save icon.
5. Click the Restart Services icon.
356
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring IP Addresses and Address Ranges
Adding a DHCP Range
You must add a DHCP range for your network so the Infoblox device can assign IP addresses within that specified
range to DHCP clients. If the client is on a network that is assigned a DHCP range, the device distributes an available
IP address from that range to the DHCP client, or to a DHCP relay agent if the request came through an agent. You must
also assign a device to a DHCP range. If devices are in a grid, you must specify which member serves DHCP for the
DHCP range. If the server is an independent device, you must specify this device as the member that serves the DHCP
range.
To add a DHCP range to a network:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> Edit -> Add DHCP Range.
2. Enter the following:
— Start Address: Enter the first IP address in the range available for the clients.
— End Address: Enter the last IP address in the range available for the clients.
— Comment: Enter a text string to help identify this address range.
— Disable this DHCP range: Select this check box if you do not want the DHCP server to allocate IP addresses
from this DHCP range. This is useful when you are in the process of setting up the DHCP server. Clear this
check box after you have configured the server and are ready to have it serve DHCP for this network.
3. Click Member Assignment and select one of the following:
— Grid Member: Select the member that serves DHCP for this IP address range. The Infoblox device populates
the drop-down list with the local appliance and—if the device is part of a grid—any other grid members.
or
— Or enable failover: Select this check box and click Select Association. In the Select DHCP Failover
Association dialog box, choose a failover association. If no failover peer associations are available in the
drop-down menu, see Configuring DHCP Failover on page 397.
Note: If you do not make a selection between one of these two options, DHCP is not served for this range.
4. Click OK to close the dialog box.
5. You can then override settings at the network level and enter unique settings for the DHCP range, as described
in each of the following sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
— Setting Watermark Properties on page 426
— Defining Filters on page 383
— Applying Device Classifications on page 422
6. Click the Save icon.
7. Click the Restart Services icon.
Excluding Addresses from an Address Range
Some network devices need to use statically assigned IP addresses rather than addresses dynamically assigned
through DHCP. For example, DHCP servers must have statically configured IP addresses. Also, some devices (such as
legacy network printers) do not support DHCP.
Creating an exclusion range prevents the DHCP server from assigning the addresses in the exclusion range to a client.
You can use these addresses as static IP addresses. This prevents address conflicts between statically configured
devices and dynamically configured devices.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
357
Managing DHCP Data
To exclude addresses from an address range:
1. From the DHCP and IPAM Perspective, select Networks -> + (for Networks) -> network -> addr_range -> Edit -> DHCP
Range Properties.
2. In the Configure DHCP Range editor, click Exclusion Ranges.
3. In the Exclusion Ranges section, click Add.
4. In the Exclusion Range dialog box, enter the following information:
— Start Address: Enter the first IP address to exclude from the range.
— End Address: Enter the last IP address to exclude from the range.
— Comment: Enter comments such as the reason for excluding the IP addresses.
5. Click OK to close the Exclusion Range dialog box.
6. Click the Save and Restart Services icons.
Using Templates
A template is a set of rules that determine how to create an entity or object such as a network or a zone. It enables
administrators to create networks and zones in a quick and consistent way. A template is metadata that you can
modify and reuse. For example, you can create a template that determines a network’s address space layout. You can
create, modify, and delete a template. Changing or deleting a template does not affect existing objects created based
on the template.
You must be a superuser to create, edit, or delete a network template, range template, and fixed address template.
A superuser can set other admin group’s privileges on these templates in the Administrator perspective. See Creating
a Limited-Access Admin Group on page 53. You can create templates for DHCP ranges, excluded DHCP ranges, and
fixed address ranges.
Creating and Managing Network Templates
A network template is similar to a real network, except:
•
It is uniquely identified by a name
•
It does not have a network container. Hierarchy such as network and subnets (split networks) do not apply to
network templates.
•
It does not have a network address. You enter the network address when you create an actual network from the
template.
•
It does not have a disabled status.
•
In the General DHCP Options of a DHCP range template, the broadcast address is an address offset number
rather than a broadcast IP address; the network router addresses are offset numbers as well.
•
When you create a network from a template, it automatically creates a network reverse zone.
•
When you create a network from a template, you can enable a netmask to override the template’s netmask.
The network template contains a range template list and a fixed address template list. You can select from an existing
range or fixed address template and add it to the list. See Creating and Managing DHCP Range Templates on page
360 and Creating and Managing Fixed Address Templates on page 362 for instructions on how to create these
templates.
Before Creating Network Templates
Before you create a network template, ensure that you create a DHCP range template as described in Creating and
Managing DHCP Range Templates on page 360 and a fixed address template as described in Creating and Managing
Fixed Address Templates on page 362. When you create a network template, you can add the DHCP range template
and the fixed address template into the network template.
358
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Templates
Creating Network Templates
To create a network template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> Edit -> Add Templates -> Network Templates
2. In the Add Network Template editor, enter the following in the Network Template Properties section:
— Name: Enter a name for the network template such as ClassC.
— Netmask: Either select a subnet mask for the network using the dropdown menu or click Allow any
netmask. For example, select the /24 (255.255.255.0) netmask to create a /24 network template.
— Allow any netmask: Select this check box to let the subnet mask have any value. If you check this box, you
must specify the subnet mask when you create a network using this template.
— Comment: You can enter useful information about the network, such as the name of the organization it
serves.
— Automatically create a reverse-mapping zone: Select this check box if you want the device to automatically
create the corresponding reverse-mapping zone for the network.
3. In the Range Templates section, click Add, choose a DHCP range template for this network template in the Select
DHCP Range dialog and click OK. The DHCP range template properties are inherited from this selection. You can
select multiple DHCP range templates by Shift-clicking or Ctrl-clicking the range templates in the Select DHCP
Range Template dialog.
4. In the Fixed Address Templates section, click Add, choose a fixed address template for this network template in
the Select Fixed Address Template dialog box, and click OK. You can select multiple fixed address templates by
Shift-clicking or Ctrl-clicking the fixed address templates in the Select Fixed Address Template dialog.
5. Click Member Assignment to expand the Member Assignment section.
6. Click Add.
7. Choose the grid member(s) that should serve DHCP for this network from the Select Grid Members dialog box.
The DHCP properties are inherited from this member. The network can be served by multiple members.
Ensure that you include the DHCP range template’s member in the Member Assignment section. Otherwise, an
error message appears.
8. Click OK to close the Select Grid Members dialog box.
9. You can then override settings at the grid and member levels and enter unique settings for the network, as
described in the sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
— Setting Watermark Properties on page 426
10. Click the Save icon.
Modifying Network Templates
To edit a network template:
1. Select Templates -> + (for Network Templates) -> network_template -> Edit -> Network Template Properties.
2. Enter your changes.
3. Click the Save icon.admin
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
359
Managing DHCP Data
Deleting Network Templates
To delete a network template:
1. Select Templates -> + (for Network Templates) -> network_template -> Edit -> Remove network_template.
2. Click the Save icon.
Assigning Permissions to Network Templates
When you create a limited-access admin group, you determine the resources—grid members, zones, networks,
shared networks, and templates—that administrators in that group can access with read-only or read/write
privileges.
The superuser for a group can set read-only, read/write, or deny permissions for other administrators in the group to
access the network template. For more information on assigning permissions, see Creating a Limited-Access Admin
Group on page 53.
Creating and Managing DHCP Range Templates
A DHCP range template has properties similar to those of a real DHCP range, except:
•
It is uniquely identified by a name.
•
It can be defined independently and can be referred by multiple network templates.
•
The start address and end address fields are replaced by numbers of offset from the network start address and
the number of IP addresses in the range.
•
It does not have a disabled status.
•
For the exclusion range in the template, the start address and end address are replaced by the number of
offsets in the parent range's start address and the number of IP addresses in the exclusion range.
•
It does not have any grid member assignment option.
•
In the General DHCP Options of a DHCP range template, the broadcast address is an address offset number
rather than a broadcast IP address; network router addresses are offset numbers as well.
•
The exclude ranges are templates with offset and number of address properties rather than start and end
addresses
To create a DHCP range template:
1. From the DHCP and IPAM Perspective, select + (for Templates)-> + (for Range Templates) -> Edit -> Add Templates
-> DHCP Range Template.
2. Enter the following in the Add DHCP Range Template dialog box:
— Name: Enter a name for the DHCP range template (for example, Region1 IT).
— Offset: Enter the value for the offset from the parent network’s start address.
— Number of Addresses: Enter the number of IP addresses (can be one or more). You can use this template to
populate one or more fixed addresses.
— Comment: Enter a text string to help identify this address range.
3. Click Member Assignment, select the Enable failover check box, and click Select Association. In the Select DHCP
Failover Association dialog box, choose a failover association. If there are no failover peer associations in the
drop-down menu, see Configuring DHCP Failover on page 397.
4. Click Member Assignment and select one of the following:
— Grid Member: Select the member that serves DHCP for this IP address range template. The Infoblox device
populates the drop-down list with the local appliance and—if the device is part of a grid—any other grid
members.
or
— Enable DHCP failover: Select this check box and click Select Association. In the Select DHCP Failover
Association dialog box, choose a failover association. If no failover peer associations are available in the
drop-down menu, see Configuring DHCP Failover on page 397.
360
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Templates
Note: If you do not make a selection between one of these two options, DHCP is not served for this range
template.
5. Click OK to close the dialog box.
6. You can then override settings at the network level and enter unique settings for the DHCP range template, as
described in each of the following sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
— Setting Watermark Properties on page 426
— Defining Filters on page 383
— Applying Device Classifications on page 422
7. Click the Save icon.
Excluding Addresses From DHCP Range Templates
Some network devices need to use statically assigned IP addresses rather than addresses dynamically assigned
through DHCP. For example, DHCP servers must have statically configured IP addresses. Also, some devices (such as
legacy network printers) do not support DHCP.
Creating an exclusion range template prevents the DHCP server from assigning the addresses in the exclusion range
template to a client. You can use these addresses as static IP addresses. This prevents address conflicts between
statically configured devices and dynamically configured devices.
To exclude addresses from a DHCP range template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> + (for Range Templates) -> Edit -> Add Templates
-> DHCP Range Template.
2. Click Exclusion Range Templates in the AddDHCP Range Template editor.
3. Click Add in the Exclusion Range Templates section and enter the following information:
— Offset: Enter the value for the offset from the parent network’s start address.
— Number of Addresses: Enter the number of IP addresses (can be one or more) that you want to exclude in
the DHCP range template.
— Comment: Enter comments such as the reason for excluding the IP addresses.
4. Click OK to close the Exclusion Range dialog box.
5. Click the Save icon.
Modifying DHCP Range Templates
To edit a DHCP range template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> + (for Range Templates) -> range_template -> Edit
-> Properties.
2. Enter the changes in the Add DHCP Range Template editor.
3. Click the Save icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
361
Managing DHCP Data
Deleting DHCP Range Templates
To delete a DHCP range template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> + (for Range Templates) -> range_template -> Edit
Remove range_template.
2. Click the Save con.
Creating and Managing Fixed Address Templates
A fixed address template also has properties similar to a fixed address, except:
•
It is uniquely identified by a name.
•
It can be defined to populate one or multiple fixed address templates.
•
It has the default, uneditable MAC address 00:00:00:00:00:00. All fixed address(es) created from the template
has this default MAC address. You must update it to an actual MAC address.
To create a fixed address template:
1. From the DHCP and IPAM Perspective, select Templates -> + (for Fixed Address Templates) -> Fixed Address
Templates -> Edit -> Add Templates -> Fixed Address Template.
2. Enter the following:
— Name: Enter a name for the fixed address template (for example, HP Printers).
— Offset: Enter the value for the offset from the parent network’s start address.
— Number of Addresses: Enter the number of IP addresses (can be one or more) to use as fixed addresses.
You can use this template to populate one or more fixed addresses.
— Allocate address dynamically: Select this option if you want to assign DHCP options to a device with a
dynamically assigned IP address. This enables you to reserve an IP address spot but not for particular IP
address.
— MAC Address: The default, uneditable MAC address 00:00:00:00:00:00. All fixed addresses created from
the template have this default MAC address. You must update it to an actual MAC address when you create
a fixed address object using the template. For example, if you select the Allocate address dynamically
option in the template and use the template to create a fixed address object, then, you must update the
MAC address to an actual value. The device assigns a dynamically allocated IP address to this MAC address.
— Comment: You can enter useful information about the host, such as the type of resource.
3. You can then override settings at the network level and enter unique settings for the fixed address template and
range template, as described in each of the following sections:
— Configuring DHCP Properties on page 373
— Specifying DHCP Lease Times on page 376
— Specifying BOOTP Properties on page 377
— Specifying Custom DHCP Options on page 378
— Configuring DDNS on the DHCP Server on page 407
— Applying Device Classifications on page 422
4. Click the Save icon.
Modifying Fixed Address Templates
To edit a fixed address template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> + (for Fixed Address Templates) ->
fixed_address_template -> Edit -> Properties.
2. Click the Save icon.
362
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Templates
Deleting Fixed Address Templates
To delete a fixed address template:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> + (for Fixed Address Templates) ->
fixed_address_template -> Edit -> Remove fixed_address_template.
2. Click the Save icon.
Viewing Network Templates
To get a list of the DHCP range templates and fixed address templates, in the DHCP and IPAM perspective, select +
(for Templates) -> + (for Network Templates) -> network_template -> View -> Range and Fixed Address Templates.
The Range and Fixed Address Templates panel appears. It displays the DHCP range templates and fixed address
templates in the network template. You can filter the list to view specific types of templates (such as only fixed
address templates or only DHCP range templates).
Adding a Network Using Templates
To add a network using templates:
1. From the DHCP and IPAM Perspective, click Networks -> Edit -> Add Network -> Using Template.
2. In the Create Network and Children Using Template dialog box, enter the following:
— Select Network template: Click this button to select a network template to create this network. The network
uses the properties defined in the template. See Using Templates on page 358 for information on how to a
create network template.
— Network Address: Enter the IP address of the network that should use the template.
— Netmask: This menu is enabled only if you selected the Allow any netmask option in the network template.
Select the appropriate subnet mask for the network using the dropdown menu. This menu is disabled if you
specified the netmask in the network template instead of clicking the Allow any netmask option.
3. Click OK to close the Create Network and Children dialog box.
You can also add a network using templates by selecting the network template as follows:
1. From the DHCP and IPAM Perspective, select + (for Templates) -> + (for Network Templates) -> network_template
-> right-click -> Using This Template.
2. In the Create Network and Children Using Template dialog box, enter the following:
— Network Address: Enter the IP address of the network that should use the template.
— Netmask: This menu is enabled only if you selected the Allow any netmask option in the network template.
Select the appropriate subnet mask for the network using the dropdown menu. This menu is disabled if you
specified the netmask in the network template instead of clicking the Allow any netmask option.
3. Click OK to close the Create Network and Children Using Template dialog box.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
363
Managing DHCP Data
Network Templates Configuration Example
Figure 13.3 illustrates how to create and use a /24 network template with the following ranges and configuration:
•
First address 192.168.2.1 reserved for the router
•
Next 10 addresses (192.168.2.2 to 192.168.2.11) reserved for servers
•
Next 10 addresses (192.168.2.12 to 192.168.2.21) reserved for printers
•
Next 10 addresses (192.168.2.22 to 192.168.2.31) assigned as fixed addresses
•
Next 10 addresses (192.168.2.42 to 192.168.2.51) are in an exclusion range. If you assigned static addresses
to certain hosts in the middle of an address range template, you can exclude the addresses from the address
range template so the device does not assign the IP addresses to clients.
•
100 addresses (192.168.2.32 to 192.168.2.131) reserved for workstations. The device assigns these
dynamically.
Figure 13.3 Creating a Network Using Template
192.168.2.0 /24
network
192.132.7.9
Router
Servers
192.168.2.1
Printers
192.168.2.2 to
192.168.2.11
192.168.2.12 to
192.168.2.21
Workstations
Fixed
address
192.168.2.22 to
192.168.2.31
Exclusion
range
192.168.2.32 to 192.168.2.42 to
192.168.2.131 192.168.2.51
Use the following steps to configure the sample network template (shown in Figure 13.3). After you create the
templates, you can create a network using the templates.
1. Create the following DHCP range templates:
•
Server templates with the following values:
— Name: Servers
— Offset: 2
— Number of Addresses: 10
— Comment: Address range 2 to 11 for Servers
•
Printer template with the following values:
— Name: Printers
— Offset: 12
— Number of Addresses: 20
— Comment: Address range 12 to 21 for printers and 22 to 31 in the exclusion range
•
Exclusion range template with the following values:
— Offset: 22
364
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Templates
— Number of Addresses: 10
— Comment: Excluding addresses 22 to 31 from the DHCP range 12 to 31.
•
Template for workstations with the following values:
— Name: Workstations
— Offset: 42
— Number of Addresses: 100
— Comment: Address range 42 to 141 for DHCP on workstations
2. Create a fixed address template with the following values:
— Name: myFixedAddress
— Offset: 32
— Number of Addresses: 10
— Allocate address dynamically: Select this option if you want to assign DHCP options to a device with a
dynamically assigned IP address.
— MAC Address: The default, uneditable MAC address 00:00:00:00:00:00. All fixed addresses created from
the template have this default MAC address. You must update it to an actual MAC address when you create
a fixed address object using the template.
— Comment: Fixed address template
3. Add the network template with the following values:
— Name: myNetworkTemplate
— Netmask: Select /24 as the subnet mask for the network using the dropdown menu
— Comment: Network template for /24 network
— Automatically create a reverse-mapping zone: Select this check box so that the device automatically creates
the corresponding reverse-mapping zone for the network.
4. Add the DHCP range templates Servers, Printers, and Workstations into the network template.
5. Add the fixed address template myFixedAddress into the network template.
6. Create a network using the network template myNetworkTemplate with the following values:
— Select Network template: Click this button and select the network template myNetworkTemplate.
— Network Address: Enter the IP address 192.168.2.0 of the network that you want to create using the
template.
7. Verify your configuration by selecting + (for Templates) -> + (for Network Templates) -> myNetworkTemplate -> View
-> Range and Fixed Address Templates from the DHCP and IPAM perspective.
The Range and Fixed Address Templates panel appears. It displays the DHCP range templates and fixed address
templates in the network template. You can filter the list to view specific types of templates (such as only fixed
address templates or only DHCP range templates).
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
365
Managing DHCP Data
Using the Recycle Bin
You can use the recycle bin feature on the Infoblox device to store deleted DHCP configurations. Items contained in
the recycle bin can be restored to active configuration at a later time, or can be permanently removed from the device
database. If you do not use the recycle bin, the device deletes items permanently from the database. The recycle bin
is enabled by default on the Infoblox device.
You can use the recycle bin to restore the following DHCP networks, network containers, shared networks, DHCP
ranges, fixed addresses, MAC filters, and option 82 filters. NIOS does not support restoring deleted DHCP option
filters.
This section discusses the following topics:
•
•
•
•
•
Disabling the Recycle Bin on page 366
Re-enabling the Recycle Bin on page 366
Viewing the Recycle Bin on page 366
Restoring Items in the Recycle Bin on page 367
Emptying the Recycle Bin on page 367
Disabling the Recycle Bin
You can disable the recycle bin feature globally in the Grid perspective. If you disable the recycle bin, you cannot
restore nor empty the recycle bin. The recycle bin feature is enabled by default on the Infoblox device. If you do not
have superuser privileges, a warning appears prompting you to log in again as superuser before disabling the recycle
bin.
To disable the recycle bin feature:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Enable Recycle Bin: Deselect the check box to turn off the recycle bin feature. If you do disable the recycle
bin feature, deleted items from the GUI are permanently removed and unrecoverable.
3. Click OK to save your changes.
Re-enabling the Recycle Bin
You must first enable the recycle bin globally in the Grid perspective. If you do not have superuser privileges, a
warning appears prompting you to re-login as superuser before enabling the recycle bin.
To enable the recycle bin feature for DHCP configuration items:
1. From the Grid perspective, click id_grid -> Edit -> Grid Properties.
2. In the Grid editor, click Grid Properties, and then enter the following:
— Enable Recycle Bin: Select the check box to enable the recycle bin feature. When you delete DHCP
configuration items in the GUI for the grid member, the recycle bin stores the deleted items. Enabling the
recycle bin allows you to undo the deletions and to restore the deleted items on the device at a later time. If
you do not enable the recycle bin feature, deleted items from the GUI are permanently removed and
unrecoverable.
3. Click OK to save your changes.
Viewing the Recycle Bin
You can display the Recycle Bin panel and view all deleted items stored in the recycle bin. From the DHCP perspective,
all deleted DHCP items are shown if you have superuser privilege. If you are not a superuser, only the items deleted
by you specifically are displayed. By default, records are sorted by Name. To display the Recycle Bin panel and to view
the deleted configuration items for DHCP stored in the recycle bin:
1. From the DHCP perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
366
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Using Templates
2. Scroll through the Recycle Bin panel pages using the page arrows located on the lower-left corner of the Recycle
Bin panel. The panel page length is set by the administrator as discussed in Creating an Admin Account on page
56. The panel displays each item with the following information:
— Name: Name of the configuration item deleted.
— Object Type: Type of configuration deleted.
— Parent/Container: Where the item was deleted.
— Admin: Who deleted the item.
— Time: When the item was deleted.
Restoring Items in the Recycle Bin
You can restore any configuration items in the recycle bin displayed in the Recycle Bin panel. The restore functionality
is available only if the recycle bin is enabled, and if an item is selected in the panel. Deleted items are stored in the
recycle bin until the recycle bin is emptied.
To restore items from the Recycle Bin panel:
1. From the DHCP perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
2. Select the configuration item you want to restore.
3. Click Edit -> Restore Selected Object. A warning message appears prompting you to confirm that you wish to
continue with the restore.
4. Confirm that the item was restored into the GUI by viewing the configuration where the item was originally
removed, and by confirming that the item does not appear in the Recycle Bin panel any longer.
Emptying the Recycle Bin
You can empty the recycle bin, permanently removing all of the items displayed in the Recycle Bin panel from the
device database. The empty functionality is available only if the recycle bin is enabled, and only to superusers. To
empty the recycle bin:
1. From the DHCP perspective, click View -> Recycle Bin. The Recycle Bin panel appears.
2. Click Edit -> Empty Recycle Bin. A warning message appears prompting you to confirm that you wish to empty the
recycle bin.
3. Confirm that all items were removed from the Recycle Bin panel.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
367
Managing DHCP Data
368
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 14 Configuring DHCP Services
You can configure the Infoblox device as a full-featured DHCP server. When you configure an Infoblox device to
function as a DHCP server, you can set operational parameters at the grid, member, network, DHCP range and
individual IP address levels. The device applies these parameters hierarchically. When you set parameters at the grid
level, the members, networks, DHCP ranges and IP addresses inherit these parameters, unless you override them at
a more specific level. Parameters set at the member level override grid-level settings and apply to the networks, DHCP
ranges and IP addresses that the member serves. Parameters set at the network level, override member-level settings
and apply to DHCP ranges and IP addresses within the network. Parameters set for a DHCP range override those set
at higher levels. You can also set specific parameters that apply only to a fixed addresses.
This chapter explains how to configure DHCP services in the following sections:
•
•
•
•
•
•
•
•
•
•
Configuring DHCP Overview on page 370
— DHCP Configuration Checklist on page 372
Configuring DHCP Properties on page 373
— Enabling DHCP and Setting Member Properties on page 374
Specifying Ping Settings on page 375
Specifying DHCP Lease Times on page 376
Specifying BOOTP Properties on page 377
Specifying Custom DHCP Options on page 378
Enabling DHCP Logging on page 381
Defining Filters on page 383
— Configuring a MAC Address Filter on page 387
— Configuring User Class Filters on page 392
— Configuring a Relay Agent Filter on page 394
— Managing DHCP Filters on page 396
Configuring DHCP Failover on page 397
— DHCP Failover Tasks on page 397
— Creating a Failover Association on page 398
— Monitoring the Failover Association on page 399
— Failover Association Operations on page 399
Viewing DHCP Files on page 400
— Viewing a DHCP Configuration File on page 400
— Viewing DHCP Statistics on page 400
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
369
Configuring DHCP Services
Configuring DHCP Overview
An overview of the complete DHCP configuration process is provided in the diagram below (and continued on the next
page), illustrating the main steps you will follow as you prepare your Infoblox device for use:
Begin initial configuration of DHCP for an Infoblox device.
Do you want to configure
grid-level DHCP properties?
Yes
No
Configure the grid-level DHCP
properties (for example, the
DHCP options).
Will DHCP failover
be used?
Yes
No
Enable the DHCP service on
an individual member.*
* Leave DHCP disabled
when configuring
members before
deployment so DHCP
services do not start
until the configuration is
complete.
- Create failover associations
- Enable DHCP service
Do you want to
configure member-level
DHCP properties?
Yes
No
Configure the member-level
DHCP properties.
Do you want to
enable DHCP service
on another member?
2
Yes
No
DHCP is now configured on (to be) enabled DHCP members.
Decide how the
network will be
used.
Unmapped
Specify the network address and netmask.
1
Mapped
- Select the member(s) to provide DHCP
service for this network.
- Specify the network address and netmask.
Continue on next page …
370
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP Overview
… continued from previous page.
Do you want to
define network-level
DHCP properties?
Yes
No
Configure the network-level
DHCP properties.
Do you want to define fixed
addresses for this network?
Yes
No
Specify the IP address and MAC
address for each fixed address.
Do you want to define
DHCP address ranges
for this network?
Decide how the address
range will be allocated.
Yes
No
Unmapped range
Failover range
Specify the starting and ending
IP addresses.
- Specify the starting and ending
IP addresses
Mapped
ranges
- Choose the failover association
- Specify the starting and ending IP addresses.
- Choose the member to serve this address range.
Do you want to add
more ranges?
Yes
No
See 1 in the previous diagram
to repeat the process of adding
more networks on additional
members.
Yes
Do you want to add
more networks?
No
See 2 in the previous diagram to
repeat the process of enabling
the DHCP service on additional
members.
NIOS 4.1r3
Yes
Do you have
additional members to
configure for DHCP?
No
Initial configuration of DHCP
networks is complete.
Infoblox Administrator Guide (Rev. A)
371
Configuring DHCP Services
DHCP Configuration Checklist
Each step in the flowchart above is included in the following checklist of steps:
Table 14.1 DNS Configuration Checklist
Step
For more information
Complete creating configuration.
Managing Device Operations on page 67
Decide if you want to configure DHCP properties.
•
•
•
•
•
Configuring DHCP Properties on page 373
Specifying Ping Settings on page 375
Specifying DHCP Lease Times on page 376
Enabling DHCP Logging on page 381
Defining Filters on page 383
Decide if failover will be used.
Configuring DHCP Failover on page 397
Decide how the network will be used and
configure the network.
Configuring a DHCP Network on page 350
Decide if you want to configure fixed addresses
for the network.
Configuring IP Addresses and Address Ranges on page 356
Decide if you want to define an address range for
the network.
Configuring IP Addresses and Address Ranges on page 356
Enable the DHCP service on the member.
Enabling DHCP and Setting Member Properties on page 374
372
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP Properties
Configuring DHCP Properties
When you configure an Infoblox device to function as a DHCP server, you can set certain properties that control how
the server operates. You can also specify the configuration information the server includes in its DHCP messages.
When a DHCP server assigns an IP address to a client, it can include configuration information the client needs to
connect to the network and communicate with other hosts and devices in the network.
You can set these properties at the grid level, and override them at the member, network, IP address range and fixed
address levels.
Grid Level
To configure general DHCP properties for a grid or for an independent device:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click General Properties.
3. Enter the following:
— Authoritative: Select this check box if the DHCP server is authoritative for the domain. Only authoritative
DHCP servers can send clients DHCPNACK messages when they request invalid IP addresses. For example,
a client moves to a new subnet and broadcasts a DHCPREQUEST message for its old IP address. An
authoritative DHCP server responds with a DHCPNACK, causing the client to move to the INIT state and to
send a DHCPDISCOVER message for a new IP address. Authoritative servers also respond to DHCPINFORM
messages from clients that do not receive IP addresses from the DHCP server, but need configuration
information.
— Domain Name: Enter the name of the domain for which the grid serves DHCP data. The DHCP server
includes this domain name in Option 15 when it responds with a DHCPOFFER packet to a DHCP DISCOVER
packet from a client. If DDNS is enabled on the DHCP server, it combines the host name from the client and
this domain name to create the FQDN that is uses to update DNS. For information about DDNS, see Chapter
15, Configuring DDNS Updates from DHCP, on page 401.
— Broadcast Address: Enter the broadcast IP address of the network to which the DHCP server is attached.
— Routers: Enter the IP address of at least one router connected to the same network as the client. The DHCP
server includes this information in its DHCPOFFER messages.
— DNS Servers: Enter the IP address of the DNS server(s) to which the client can send name resolution
requests. The DHCP server includes this information in its DHCPOFFER messages.
— Number of Pings: Enter the number of pings that the Infoblox device sends to an IP address to verify that it
is not in use. The range is 0 to 10, inclusive. Enter 0 to disable DHCP pings.
— Ping Timeout: Enter the ping timeout value. The range is 1 to 5, inclusive.
— Keep leases from deleted ranges until one week after expiration: If you select this check box, and then
delete a DHCP range, the device stores active leases from this range up to one week after the leases
expires. Therefore if you add a new DHCP range that includes the IP addresses of these active leases or
assign the DHCP range to another member within the grid, the device restores the active leases.
4. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
373
Configuring DHCP Services
Enabling DHCP and Setting Member Properties
Though you can set general DHCP properties at the grid level, you enable DHCP services at the member level only.
Infoblox recommends that you configure the DHCP parameters before you enable DHCP on the Infoblox device.
To configure general DHCP properties for a grid member:
1. From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties.
2. In the Member DHCP Properties editor, click General Properties.
3. Enter the following:
— Enable DHCP Server: Select this check box to enable the grid member to serve DHCP.
— You can override the settings you defined at the grid level:
— Authoritative setting
— Domain name
— Broadcast address
— Router IP address
— DNS server IP address
— Ping settings
4. Click the Save and Restart Services icons.
Network Level
To configure general DHCP properties for a network or shared network, follow the navigational path below and
override the member-level settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> Network Properties.
Address Range Level
To configure general DHCP properties for a DHCP address range, follow the navigational path below and override the
network-level settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> General DHCP Options.
Fixed Address Level
To configure general DHCP properties for a fixed address, follow the navigational path below and override the address
range settings. Restart services after you save the settings.
•
374
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
ip_addr -> Edit -> Fixed Address Properties -> General Properties.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Specifying Ping Settings
Specifying Ping Settings
When a DHCP client first tries to connect to a network, it broadcasts its request for an IP address. When the Infoblox
device receives such a request, it checks its record of assigned IP addresses and leases. Because there are a limited
number of IP addresses available, the device reassigns IP addresses whose leases might have expired. Therefore,
once the device selects a candidate IP address for lease, it sends an ICMP echo request (or ping) to the IP address to
verify that it is not in use.
If the Infoblox device receives a response, this indicates that the IP address is still in use. The appliance then selects
another candidate IP address and sends it a ping. The appliance continues this process until it finds an IP address
that does not respond to the ping. The appliance then sends a DHCPOFFER message with the unused IP address to
the DHCP client.
Figure 14.1 Ping Overview
1 Client broadcasts a
DHCPDISCOVER
message.
2 When the Infoblox device
receives the DHCPDISCOVER
message, it checks its record
of IP addresses and selects an
IP address for lease.
3 The appliance sends the
configured number of pings
to the selected IP address.
The appliance receives a
reply, indicating that the IP
address is in use.
4 The appliance selects another
IP address and sends it the
configured number of pings.
The appliance does not receive
a response within the specified
timeout, and assumes the
address is not in use.
IP Addresses
ICMP Echo
Requests
ICMP Echo
Replies
IP Addresses
ICMP Echo
Requests
5 The appliance sends the client
a DHCPOFFER message with
the selected IP address.
By default, the Infoblox device pings the candidate IP address once and waits one second for the response. You can
change these default settings to better suit your environment. You can increase the number of pings and increase the
timeout value. For example, you can increase the timeout value to two seconds to accommodate delays caused by
problems in the network. Note that increasing any of the ping values increases the delay experienced by a client
before acquiring a lease. You can also disable the device from sending pings by changing the number of pings to 0.
You can change the default ping settings at the member level and at the grid level. You can define ping settings for
an entire grid, and when necessary, define different ping settings for a member. Settings at the member level override
settings at the grid level. For information about changing the default ping settings, seeConfiguring DHCP Properties
on page 373.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
375
Configuring DHCP Services
Specifying DHCP Lease Times
You can specify the length of time the DHCP server leases an IP address to a client. The default on the Infoblox device
is 12 hours, and you can change this default according to your network requirements. There are a number of factors
to consider when setting the lease time for IP addresses, such as the types of resources and clients on the network,
and impact to traffic and performance. With Infoblox devices, you can set lease times at different levels, based on
these factors. You can set a default lease time at the grid level and then override this setting for specific members,
subnets, IP address ranges or fixed addresses when appropriate.
Some hosts use PXE (Preboot Execution Environment) to boot remotely from a server. When such a host starts up, it
first requests an IP address so it can connect to a server on the network and download the file it needs to boot. After
it downloads the file, the host reboots and sends another IP address request. To better manage your IP resources, set
a different lease time for PXE boot requests. You can configure the DHCP server to allocate an IP address with a shorter
lease time to hosts that send PXE boot requests, so IP addresses are not leased longer than necessary.
The following sections describe how to set lease times at the grid level and override these settings for a member,
network, address range, and fixed address.
Grid Level
To specify lease times for a grid:
1. From the DHCP and IPAM Perspective, click DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click Lease Times.
3. Enter the following:
— Lease Time: Enter the appropriate values in the Days, Hours, Mins and Secs fields.
— Enable PXE Lease Time: Select this check box to enable the DHCP server to send a different lease time to
hosts that send PXE boot requests.
— PXE Lease Time: Enter appropriate values in the Days, Hours, Mins and Secs fields. You can specify the
duration of time it takes a host to connect to a boot server, such as a TFTP server, and download the file it
needs to boot. For example, set a longer lease time if the client downloads an OS (operating system) or
configuration file, or set a shorter lease time if the client downloads only configuration changes.
4. Click the Save and Restart Services icons.
Member Level
To set lease times for a grid member, follow the navigational path below and override the grid-level settings. Restart
services after you save the settings.
•
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> Lease Times.
Network Level
To override lease times for a network, follow the navigational path below and override the member-level settings.
Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> Lease Times.
Address Range Level
To set lease times for an address range, follow the navigational path below and override the network-level settings.
Restart services after you save the settings.
•
376
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> Lease Times.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Specifying BOOTP Properties
Fixed Address Level
Give fixed addresses longer lease times since the IP address does not change. To set lease times for a fixed address,
follow the navigational path below and override the address range settings. Restart services after you save the
settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
ip_addr -> Edit -> Fixed Address Properties -> Lease Times.
Specifying BOOTP Properties
You can configure the DHCP server to support clients that use BOOTP (bootstrap protocol) or that include the TFTP
server name option and boot file name option in their DHCPREQUEST messages. You can specify the name and/or IP
address of the boot server and name of the file the host needs to boot.
You can specify these properties at the grid, member, network, IP address range, and fixed address levels.
Grid Level
To configure support for BOOTP boot requests on a grid:
1. From the DHCP and IPAM Perspective, click DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click BOOTP.
3. Enter the following:
— Boot Server Name: Enter the name of the server on which the boot file is stored. Clients can request for
either the boot server name or IP address. Complete this field if the hosts in your network send requests for
the boot server name. If the TFTP server is the Infoblox device that is also serving DHCP, enter the name of
the Infoblox device.
— Next Server IP: Enter the IP address of the boot file server on which the boot file is stored. Complete this
field if the hosts in your network send requests for the IP address of the boot server. If the TFTP server is the
Infoblox device that is also serving DHCP, enter the IP address of the Infoblox device.
Note that you can complete both the Boot Server Name and Next Server IP fields, if some hosts on your
network require the boot server name and others require the boot server IP address.
— Boot File Name: The name of the file the client must download.
4. Click the Save and Restart Services icons.
Member Level
To configure BOOTP properties for a DHCP member, follow the navigational path below and override the grid-level
settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> BOOTP.
Network Level
To configure BOOTP properties for a network or shared network, follow the navigational path below and override the
member-level settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> BOOTP.
Address Range Level
To override BOOTP properties set at the network level, follow the navigational path below and override the
network-level settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks ) -> network ->
addr_range -> Edit -> DHCP Range Properties -> BOOTP.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
377
Configuring DHCP Services
Fixed Address
To configure BOOTP properties for a host with a fixed address, follow the navigational path below and override the
address range-level settings. Restart services after you save the settings::
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks ) -> network ->
ip_addr -> Edit -> Fixed Address Properties -> BOOTP.
Specifying Custom DHCP Options
DHCP options describe network configuration settings and various services available on the network. These options
occur as variable-length fields at the end of DHCP messages. Each option is identified by an option code number. The
Infoblox DHCP server supports up to 254 custom DHCP options, from option 1: subnet-mask to option 254:
option-254.
You can use option spaces to define a new location in which you can store options. ISC DHCP has five predefined
option spaces: dhcp, agent, server, nwip, and fqdn. The DHCP option space has two types of options:
•
Predefined Options—These are the DHCP option codes from 1 to 254 that are allocated by the IANA and defined
by IETF standards. Examples of such options are: option 17 root-path text, option 19 ip-forwarding Boolean, and
option 13 boot-size uint16. The DHCP server knows these standard options and they are predefined on the
server. The administrator cannot redefine these options. Infoblox appliances contain the Standard-DHCP option
space and its options as factory defaults.
•
Custom Options—These are the DHCP option codes from 1 to 254 that are not defined by IETF standards and are
available for private use. The administrator can enter a name when defining custom options.
The data type for some options is predefined. For example, the data type for option 1: subnet-mask is an IP address.
You cannot change the data type for this option. The data type for some other options is user-defined (at the grid
level) and can be in one of the following formats:
Table 14.2 DHCP Option Data Types
This data type
Specifies the following content format
String
an ASCII text string (the same as the text data type) or a list of
hexadecimal characters separated by colons
Formatting to distinguish an ASCII text string from a hexadecimal string
is important. For details, see the following section.
Boolean
a flag with a value of either true or false (or on or off )
IP address
a single IP address
Array of IP addresses
a series of IP addresses, separated by commas
You can optionally include a space after each comma.
Text
an ASCII text string
8-, 16-, or 32-bit unsigned integer
a numeric range of the following possible values
8-bit unsigned integer: from 0 to 255
16-bit unsigned integer: from 0 to 65,535
32-bit unsigned integer: from 0 to 4,294,967,295
8-, 16-, or 32-bit signed integer
a numeric range of the following possible values
8-bit signed integer: from -128 to 127
16-bit signed integer: from -32,768 to 32,767
32-bit signed integer: from -2,147,483,648 to 2,147,483,647
378
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Specifying Custom DHCP Options
Option-254, for example, is undefined. You can associate that code number with a definition that provides some type
of information that none of the other options provides, using one of the preceding data types.
When defining a hexadecimal string for a custom DHCP option (such as option 43, vendor encapsulated options), use
only hexadecimal characters (0-9, a-f, or A-F) without spaces and separated by colons. The accepted form for a
hexadecimal string, as presented in a regular expression, is [0-9a-fA-F]{1,2}(:[0-9a-fA-F]{1,2})*
Two examples of correctly written hexadecimal strings:
•
aa:de:89:1b:34
•
1C:8:22:A3 (Note that the DHCP module treats a single hexadecimal character, such as “8” as “08”.)
A few examples of incorrectly written hexadecimal strings:
•
:bb:45:d2:1f – Problem: The string erroneously begins with a colon.
•
bb:45:d2:1f: – Problem: The string erroneously ends with a colon.
•
bb:4 5:d2:1f – Problem: The string erroneously includes a space between two characters (“4” and “5”).
•
bb:45:d2:1g – Problem: The string erroneously includes a nonhexadecimal character (“g”).
The DHCP module treats incorrectly written hexadecimal strings as simple text strings, not hexadecimal strings. If the
string appears in quotes, it is a text string.
Grid Level
To specify custom options for a grid:
1. From the DHCP and IPAM Perspective, click DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2.
In the Grid DHCP Properties editor, click Add to open the Option dialog box.
3. Click Select Option to open the Select Option dialog box that contains a list of option spaces, their names, option
codes, and data types.
a.
Select an option and click OK. You can select from the DHCP or user-defined option spaces.
b. Enter a value for the option in the Value field following this criteria:
— Enter false or true for a Boolean Flag type value.
— Enter an ASCII text string, or enter a series of octets specified in hex, separated by colons.
— Separate multiple values by commas. For example, to enter multiple IP addresses for netbios-name-servers,
enter a comma between each IP address.
Here are some examples of option names and correctly formatted values:
Option name
Value
Comment
dhcp-client-identifier
MyPC
Double quotes are no longer needed for string type
values
dhcp-client-identifier
43:4c:49:45:54:2d:46:4f:4f
Series of octets specified in hex, separated by colons
for a Data-string type value
netbios-name-servers
10.1.1.5,10.1.1.10
Multiple IP addresses separated by commas
option-80
ABC123
Custom option number 80 set to the string ABC123.
4. Click OK to close the Option dialog box.
5. Repeat this process for all desired options.
6. Click the Save and Restart Services icons.
Member Level
To configure custom options for a DHCP member, follow the navigational path below and override the grid-level
settings. Restart services after you save the settings.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
379
Configuring DHCP Services
•
From the DHCP and IPAM Perspective, click DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> Custom Options.
Network Level
To specify custom options for a network or shared network, follow the navigational path below and override the
member-level settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks ) -> network -> Edit ->
Network Properties -> Custom Options.
Address Range Level
To configure custom options for an address range, follow the navigational path below and override the network-level
settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks ) -> network ->
addr_range -> Edit -> DHCP Range Properties -> Custom Options.
Fixed Address Level
To specify custom options for a fixed address, follow the navigational path below and override the address
range-level settings. Restart services after you save the settings.
•
From the DHCP and IPAM Perspective, click Network -> + (for Networks or Shared Networks) -> network -> padre ->
Edit -> Fixed Address Properties -> Custom Options.
Configuring Advanced DHCP Options
The Advanced DHCP Options Configuration feature enables you to configure a variety of predefined and custom DHCP
options through the Infoblox GUI. It supports vendor option spaces, vendor options, filtering based on any
predefined DHCP option, and applying conditional OR logic in filters. This provides an easy and graphical way to
create complex DHCP server configurations.
The DHCP options configuration conforms to the following RFCs:
•
•
RFC 2132, DHCP Options and BOOTP Vendor Extension
RFC 3046, DHCP Relay Agent Information Option. The supported options include option 60 (Client Identifier), 21
(Policy Filter), 22 (Maximum Datagram Reassembly Size), 23 (Default IP Time-to-Live), and 82 (Support for
Routed Bridge Encapsulation).
•
•
RFC 3925, Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
RFC 2939, Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
When you configure DHCP options, you can also check for errors to ensure that you configure the option correctly.
When it detects an error, the Infoblox GUI displays an error message and what you should do to correct it.
The GUI also displays an informational message if the option configuration takes more than three seconds.
If you configure a DHCP option using this feature, you can upgrade to newer software releases of the Infoblox NIOS
without reconfiguring the option.
DHCP offers up to 256 special option sets to customize the delivery of IP addresses to users and various devices such
as printers and IP phones.
Configuring the DHCP Option Space
The DHCP option space contains the predefined DHCP option spaces. You can also define custom options in the DHCP
option space as follows:
1. From the DHCP and IPAM Perspective, select Option Spaces -> right-click DHCP and select Edit Properties.
380
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS Updates
The DHCP Option Space editor appears. It lists the predefined option name, option number, and data type. It
has a Custom Options section in which you can define your own custom options and add them to the DHCP
Option Space.
2. In the Custom Options section, click Add.
The Custom Options dialog box appears. Enter the name of the option, select the option code, select the option
type, and click OK.
3. Click the Save and Restart Services icons.
Adding Vendor Option Spaces
Apart from using the DHCP option space, you can also define your own option spaces and include options such as
vendor-specific options in them. You can define option spaces for devices such as VoIP phone or wireless access
points. The Infoblox device can filter address requests by the vendor options of a requesting host. The filter instructs
the Infoblox device either to grant or deny an address request if the requesting host matches the filter.
To add a vendor option space and include options in it:
1. From the DHCP and IPAM Perspective, select Option Spaces -> Edit -> Add Vendor Option Space.
The Vendor Option Space editor appears. In the Option Space Name field, enter an appropriate name for the
option space (such as SUNW).
2. In the Options section, click Add.
The Option dialog box appears. Enter the name of the option, select an option code from 1 to 254, select the
option type (such as ip-address, text, Boolean, and string as described in Table 14.2) and click OK. For example,
to create an option that defines the IP address of the Solaris root servers, enter the name SrootIP4, select
option code 1, and select the type as ip-address.
The option added appears in the Options list for the Option Space.
3. Click the Save and Restart Services icons.
After you define an option space and add options to it, you can create option filters so that the Infoblox device can
filter address requests using the DHCP options of the requesting host. The Infoblox device grants or denies an
address based on whether the requesting host matches the filter. See Configuring Option Filters on page 389 to set
up and use option filters.
Configuring DNS Updates
See Chapter 15, Configuring DDNS Updates from DHCP, on page 401 for information on how to configure DNS
updates in the DHCP properties editor.
Enabling DHCP Logging
If you have a syslog server operating on your network, you can specify in which facility you want the server to display
the DHCP logging messages. You can also select the grid member on which you want to store the DHCP lease history log.
Grid Level
To specify DHCP logging options for a grid:
1. From the DHCP and IPAM Perspective, click DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click Logging.
— Syslogging Facility: Select where you want the syslog server to display DHCP logging messages.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
381
Configuring DHCP Services
— Store Leases on: Click Select member, and then select the grid member on which you want to store the
DHCP lease history log. Infoblox recommends that you dedicate a member other than the master as a
logging member. If possible, use this member solely for storing the DHCP lease history log. If you do not
select a member, no logging can occur.
— Log lease events from all DHCP servers: To enable DHCP lease logging for the entire grid, select check box.
To disable DHCP lease logging for the grid, clear check box. (You can set member overrides if you want to
enable or disable lease logging per member. For additional information on these functions, see Logging
Member and Selective Logging on page 433.
3. Click the Save and Restart Services icons.
Member Level
To specify logging options for a member, follow the navigational path below and override the grid-level settings.
Restart services after you save the settings.
•
382
From the DHCP and IPAM Perspective, click DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> Logging.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Defining Filters
Defining Filters
When a host requests an IP address, the Infoblox device draws an address from an address range associated with the
network segment for that host. Because you define that range, you can thereby control the IP address (within the
defined range) and the associated TCP/IP settings that the host receives.
In Figure 14.2, three hosts—each in a different subnet—request an IP address. Each one broadcasts a DHCPDISCOVER
message, which includes its MAC address. When the router, which also functions as a DHCP relay agent, receives the
message, it adds the IP address of the interface on which the message arrives and forwards the message to the DHCP
server—or servers—previously configured on the router. When the Infoblox device receives the message, it uses the
ingress interface IP address of the router to determine the network segment to which the host belongs and associates
the MAC address of the requesting host with an IP address from an address range for that network.
Figure 14.2 Requesting Addresses – DHCPDISCOVER Messages
1 When each host
broadcasts a
DHCPDISCOVER
message, it includes
its MAC address.
Hosts requesting
IP addresses
2 When the relay agent
receives the
DHCPDISCOVER message,
it adds the IP address of the
ingress interface to the
message. It then forwards
the message using IP
unicast to the DHCP server.
DHCPDISCOVER
3
When the Infoblox device
receives the DHCPDISCOVER
message, it uses the ingress
interface IP address on the relay
agent to determine the network
segment to which the host belongs.
It then assigns an address to that
host from the address range
belonging to that subnet.
Furthermore, it associates the IP
address with the source MAC
address of the host.
10.1.1.1
10.2.1.1
DHCPDISCOVER
10.4.1.1
Router
(Relay Agent)
10.3.1.1
Infoblox Device
Networks
10.1.1.0/24
Address Range
10.1.1.20 10.1.1.200
10.2.1.0/24
Address Range
10.2.1.20 10.2.1.200
DHCPDISCOVER
10.3.1.0/24
Address Range
10.3.1.20 10.3.1.200
The Infoblox device replies to DHCPREQUEST messages by sending DHCPOFFER messages through the relay agent to
the requesting hosts, as shown in Figure 14.3 on page 384.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
383
Configuring DHCP Services
Figure 14.3 Requesting Addresses – DHCPOFFER Messages
1 The Infoblox device associates the
2 When the relay agent receives
Hosts requesting
IP addresses
the DHCPOFFER messages, it
broadcasts each one from the
interface on which it originally
received the corresponding
DHCPDISCOVER message (if
the broadcast flag is set to 1).
MAC address of each requesting
host with an IP address from an
address range in the same network
segment as the ingress interface of
the relay agent.
The device then sends unicast
DHCPOFFER messages to the
ingress interface IP addresses of the
relay agent to return to each host.
DHCP OFFER
10.1.1.1
10.2.1.1
10.4.1.1
Router
(Relay Agent)
DHCP OFFER
10.3.1.1
Infoblox Device
Networks
10.1.1.0/24
Address Range
10.1.1.20 10.1.1.200
10.2.1.0/24
Address Range
10.2.1.20 10.2.1.200
DHCP OFFER
10.3.1.0/24
Address Range
10.3.1.20 10.3.1.200
The addressing scheme depicted in Figure 14.2 on page 383 and Figure 14.3 is fairly simple: each network has a
single address range. Consequently, address assignments are fairly straight forward. However, if you have multiple
address ranges in the same network and you want to assign addresses from specific address ranges to specific hosts,
you must screen the address assignments through the use of filters. If you do not apply a filter, the Infoblox device
assigns addresses from the highest address range to the lowest range and within each range from the highest
address to the lowest address. That is, the device chooses the range with the highest addresses first (that is, closest
to 255) and begins assigning addresses exclusively from that range, starting with the highest address and finishing
with the lowest (closest to 0). When all the addresses from that range are in use, it then begins assigning addresses
from the next highest range, and so on, finishing with the range with the lowest addresses. This is shown in Figure
14.4 on page 385.
Note: After the DHCP server runs for a while, it assigns leases based on when it last used addresses, and not just on
their positions in the range.
384
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Defining Filters
Figure 14.4 Multiple Address Ranges without Filters
The Infoblox device assigns
addresses to both hosts from the
same address range—first to Host
A, and then to Host B.
1
Infoblox Device
Host A receives 10.1.1.120
2
Host B receives 10.1.1.119
Host A
Network
Host B
If more hosts requests addresses,
the device continues to assign them
from address range 2— the next
address being 10.1.1.118,
then 10.1.1.117, and so on—until
all the addresses in that range are
in use.
10.1.1.0/24
Address Range 1
10.1.1.20 10.1.1.80
Address Range 2
10.3.1.81 10.3.1.200
Then the device starts assigning
addresses from address range 1,
starting at 10.1.1.80, and stopping
at 10.1.1.20.
To control the assignment of addresses from specific address ranges to specific hosts, the Infoblox device provides
the following three filters:
•
MAC address or vendor prefix of the requesting host
•
User class, as specified in the network adapter of the requesting host (DHCP option 77)
•
Circuit ID and remote ID as specified by the relay agent (suboptions of DHCP option 82)
One benefit of more precise address assignments is that you can then exercise more granular access control policies
based on these assignments.
When the Infoblox device receives an address request, it checks if the request matches a filter. If it does not, the
device assigns an address from the address range with the highest available IP address. If the request matches one
or more filters for a range, the device applies the following rules:
•
If there are Grant filters applied to that range, the request must match one of the filters or the Infoblox device
does not grant an address from that range.
•
If there are Deny filters applied to that range, the request must not match any of the filters. If the request
matches a Deny filter, the Infoblox device does not grant an address from that range.
•
If an address range has a combination of Grant and Deny filters, the request must:
— Match a Grant filter
— Not match a Deny filter
Note: Be careful to avoid contradictory filter combinations such as denying vendor prefixes 11:22:33 and allowing
the MAC address 11:22:33:44:55:66. The machine with MAC address 11:22:33:44:55:66 cannot get an
address from this range.
Two rules govern the behavior of the Infoblox device in relation to DHCP filters:
1. The device checks if any data in an address request (the MAC address or vendor prefix of the client, or DHCP
options 77 and 82) matches any filter applied to an address range.
2. The device checks for available addresses in address ranges containing the highest addresses first. (“Highest”
here means closest to 255.255.255.255, and lowest means closest to 0.0.0.0.)
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
385
Configuring DHCP Services
These two rules can work in coordination. For example, when the Infoblox device receives an address request, it first
checks if the request matches any filters. If it matches more than one filter assigned to different address ranges, the
device first applies the filter belonging to the range with the higher IP addresses. If that address does not grant an
address lease (because the filter action is Deny or all address leases in that range are already in use), the device then
applies the matching filter for the range with the next higher set of IP addresses. If the device still has not granted a
lease from either of the address ranges whose filters match data in the request and there are unfiltered address
ranges, the device attempts to assign an address from one of these ranges, again beginning with the range having
the highest IP addresses. Figure 14.5 presents an example illustrating the sequence in which the Infoblox device
assigns addresses when a request matches a vendor prefix filter. (For information about vendor prefix filters, see
Configuring a MAC Address Filter on page 387.)
Figure 14.5 DHCP Address Assignment with Multiple Filters
Infoblox Device
Four Address Ranges
3
Address
Request
1
DHCP Client
Vendor Prefix:
11:22:33
Address
Offer
386
2
4
No filter, but the Infoblox
device cannot grant
lease because all
addresses are in use.
Unfiltered
10.4.4.10—
10.4.4.20
Vendor prefix matches a
filter with action Grant,
but the device cannot
grant lease because all
addresses are in use.
Filter—If vendor
prefix = 11:22:33,
grant lease
10.3.3.10—
10.3.3.20
Vendor prefix matches
filter, but the filter action
is Deny.
Filter—If vendor
prefix = 11:22:33,
deny lease
10.2.2.10—
10.2.2.20
No filter and at least one
address is available, so
the device grants an
address from this range.
Infoblox Administrator Guide (Rev. A)
Unfiltered
10.1.1.10—
10.1.1.20
NIOS 4.1r3
Defining Filters
The following explains how the Infoblox device applies filters to DHCP address requests:
If
then
the device receives a request that
matches a filter for one address range,
it applies the action specified in the filter for that address range. If it
does not assign an address from that range (the action is deny or the
action is grant but all addresses in that range are in use), the device
then checks if it can assign an address from an unfiltered address
range (if there are any), starting with the range with the highest
addresses first, as shown in Figure 14.4 on page 385.
the same filter applies to multiple
address ranges and the Infoblox device
receives an address request matching
that filter,
it checks the address range with the highest IP addresses matching
that filter. If the device does not assign an address from that range, it
checks the filtered address range with the next highest IP addresses,
and so on. If it still has not assigned an address, the device starts
checking unfiltered address ranges (if there are any), again beginning
with the range with the highest address first.
multiple filters for the same address
range conflict with each other (one filter
grants a lease and another denies it) and
a requesting client matches both filters,
the filter denying the lease takes precedence. For example, if a
requesting client matches both a MAC address filter (granting a lease)
and a user class filter (denying a lease) for the same address range,
the device denies the lease. When faced with a choice to either allow
or deny a lease based on equal but contradictory filters, the device
takes the more secure stance of denying it.
Configuring a MAC Address Filter
The Infoblox device can filter address requests by the MAC address or vendor prefix (that is, the first six hexadecimal
characters in a MAC address) of a requesting host. The filter instructs the Infoblox device either to grant or deny an
address request if the requesting host matches the filter.
You can also configure the filter or specific MAC addresses within a filter to expire after a certain amount of time has
passed. Filter expiration is useful in situations where you want to keep filters running against updated MAC
addresses. MAC addresses may become invalid after a certain period of time has passed. You can avoid removing
invalid addresses from address filters manually by configuring the Infoblox appliance to expire filters or specific
addresses within filters.
Applying a MAC address filter involves the following three steps:
1. Define a filter based on either MAC addresses or vendor prefix.
2. Add the MAC addresses or vendor prefixes to the filter.
3. Apply the filter to a DHCP address range, and specify that if the MAC address or vendor prefix of the network
adapter of a requesting host matches the filter definition, the Infoblox device either grants or denies the address
assignment.
Defining a MAC Address Filter
To define a MAC address filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> Edit -> Add FIlter -> MAC
Address Filter.
2. To define a MAC address filter, type a meaningful name for the filter. If you want to filter by department, you might
name one filter “Marketing”, another “Finance”, another “Engineering”, and so on.
3. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
387
Configuring DHCP Services
MAC filters are valid until you explicitly configure the filter to expire. You can configure expiration when you create a
new MAC filter. This configures the entire MAC address to expire at a certain time.
To configure expiration for a MAC address filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> Edit -> Add FIlter -> MAC
Address Filter.
2. To configure when the filter must expire, type the expiration date and time in the Default MAC Address Expiration
-> Automatically Expires field. You can specify the Days, Hours, Minutes, and Seconds value to configure the
expiration time frame. If you want the MAC filter to never expire, select the Never Expire check box. By default,
the Never Expire check box is selected.
3. To enable expiration, select the Enforce Expiration Times check box.
4. To add user comments for each expiration configuration, type your comments in the Comment field.
5. Click the Save and Restart Services icons.
Adding a MAC Address or Vendor Prefix to the Filter
To add a MAC address or prefix to an existing address filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> + (for MAC Address
Filters) -> filter_name -> Edit -> Add FIlter -> Add MAC Address.
2. To add a MAC address to the selected filter, enter the hexadecimal string in the MAC Address field.
or
To add a vendor prefix, enter the first six hexadecimal characters in the MAC Address field.
Note: You can format the hexadecimal strings for MAC addresses and vendor prefixes with colons or dashes.
Both of the following formats are acceptable: 11:11:11:11:11:11 and 11-11-11-11-11-11.
3. Click the Save and Restart Services icons.
MAC filters are valid until you explicitly configure the filter to expire. You can enable expiration for specific MAC
addresses added to an existing filter.
To enable expiration for specific MAC addresses within a filter:
1. From the DHCP and IPAM Perspective, click Filters -> + (for Filters) -> MAC Address Filters -> + (for MAC Address
Filters) -> filter_name -> Edit -> Add FIlter -> Add MAC Address.
2. To add a MAC address to the selected filter, enter the hexadecimal string in the MAC Address field.
3. To enable expiration, click the Expiration Time -> Automatically Expires check box. By default, the Never Expires
check box is selected.
4. Click the Save and Restart Services icons.
Applying a MAC Address Filter to an Address Range
1. From the DHCP and IPAM Perspective, click Network -> + (for Networks or Shared Networks ) -> network ->
addr_range -> Edit -> DHCP Range Properties.
2. In the Configure DHCP Range editor, click Filter Rules.
3. Click Add beside MAC Address Filter Rule.
4. In the MAC Address Filter Rule dialog box, click Select Filter.
5.
In the Select MAC Address Filter dialog box, select the MAC address filter that you previously defined and click
OK.
6. In the MAC Address Filter Rule dialog box, select either Grant lease or Deny lease.
To assign addresses from the address range to requesting hosts whose MAC address (or the vendor prefix of
their MAC address) matches an entry in the MAC address filter, select Grant lease.
To refuse an address request from a host whose MAC address (or the vendor prefix of their MAC address)
matches an entry in the MAC address filter, select Deny lease.
388
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Defining Filters
7. Click OK.
8. Click the Save and Restart Services icons.
Note: You can add other filters in combination for the same address range. See Configuring User Class Filters on
page 392 and Configuring a Relay Agent Filter on page 394.
Configuring Option Filters
The Infoblox device can filter address requests by the vendor options (such as root-server-ip-address or
boot-file-pathname) of a requesting host. The filter instructs the Infoblox device either to grant or deny an address
request if the requesting host matches the filter.
To apply an option filter:
1. Define an option filter based on either the DHCP or user-defined options.
2. Add match rules to the filter so that it filters specific predefined options.
3. Apply the filter to a DHCP address range, and specify that if the DHCP or vendor options of a requesting host
matches the filter definition, the Infoblox device either grants or denies the address assignment.
After you define an option space and add options to it, you can set up option filters to define values for the option.
For example, to handle two different client classes such as SUNW.Ultra-5_10 and SUNW.i86pc, you can define two
option filters (vendor-class_1 and vendor-class_2) and send different option values to different clients based on the
vendor-class-identifier option that you obtain from the clients.
To add an option filter:
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> Option Filters -> Edit -> Add Filter -> Option
Filter.
2. Click Option Filter Properties in the Option Filter editor.
3. Enter the following:
— Filter Name: Enter an appropriate name for the option filter such as Sun-Blade-1000.
— Option Space: Select the option space that you want to filter. All of the option spaces defined appear in the
dropdown menu. In this example, select SUNW.
4. Click Filter Options.
5. Click Add.
The Option dialog box appears Click Select Option. The Select Option dialog box appears. It lists the option
space, option name code, and option type.
6. Select an option, enter a value, and click OK. For example, select the SUNW.SrootIP4 option and enter the value
172.124.3.0 for it.
7. Click BOOTP. Specify BOOTP properties as described in Specifying BOOTP Properties on page 377.
8. Click the Save and Restart Services icons.
Adding Match Rules
After you add an option filter, you can add match rules to this filter. Each match rule can filter a specific predefined
DHCP option. When the DHCP server receives a client packet that contains the option and the matching option value,
it returns the options in the class to the client.
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> + (for Option Filters) -> OptionFilter -> Edit->
Add Filter -> Add Match Rule.
2. In the Match Rule editor that appears:
Click Match Rule Properties.
— Match Option: Select an option from the dropdown menu. In this example, select Option 60:
vendor-class-identifier.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
389
Configuring DHCP Services
— Match Value: Enter a value for the match option (such as SUNW) you selected.
— Click the Value is a Substring checkbox and enter:
— Substring Offset: Enter the value of the offset at which the substring starts in the option data received from
the client. For example, enter 0.
— Substring Length: Enter the length of the match value. For example, if the match value is SUNW, enter 4.
3. Click the Save and Restart Services icons.
When the DHCP server receives a client packet that contains the option and the matching option value, it returns the
options in the option filter to the client.
In the following example, the match if statement is generated from data in the Match rule object. In the match
statement:
Match option is "vendor-class-identifier".
Match value is "SUNW".
Substring offset is "0" (the match value starts at the beginning of the option data received from the client).
Substring length is "4", the length of the match value "SUNW".
class "solaris-other" {
match if substring (option vendor-class-identifier,
0, 4) = "SUNW";
vendor-option-space SUNW;
}
Match option
Match value
Length of the match value
Substring offset
Applying an Option Filter to an Address Range
1. From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties.
2. In the Configure DHCP Range editor, click Filter Rules.
3. In the Option Filter Rules section, click Add. The Option Filter Rule dialog box appears.
4. In the Option Filter Rule dialog box, click Select Filter.
5.
In the Select Option Filter dialog box, select the option filter that you previously defined and click OK.
6. Select either Grant lease or Deny lease.
To assign addresses from the address range to requesting hosts whose options match the filter, select
Grant lease.
To refuse an address request from a host whose options match the filter, select Deny lease.
7. Click OK.
8. Click the Save and Restart Services icons.
Note: You can add other filter types in combination for the same address range. See Configuring a MAC Address
Filter on page 387 and Configuring a Relay Agent Filter on page 394.
Viewing Option Filters
To display the filter items of an option filter:
1. From the DHCP and IPAM perspective, select View -> + (for Networks) -> + (for Option Filters) -> OptionFilterName.
2. Select View -> Ranges, Fixed Addresses and Filters.
390
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example
3. Select the Match Rule from the Filter dropdown menu.
The match rule that you defined, its Type, and Comment fields appear. Double-click a match rule to edit it.
Configuration Example
The following example shows you how to create an option space, add custom options to it, create an option filter, and
a match rule to filter the options so that the Infoblox device can filter address requests by the vendor options of the
requesting host. It can grant or deny an address request if the requesting host matches the filter.
1. Add an option space called SUNW.
Add the following options to the SUNW option space:
Option name
Code
Type
root-mount-options
1
Text
root-server-ip-address
2
IP address
root-server-host-name
3
Text
root-server-path-name
4
Text
swap-server-ip-address
5
IP address
swap-file-path-name
6
Text
boot-file-path-name
7
Text
posix-timezone-string
8
String
boot-read-size
9
16-Bit unsigned integer
2. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> Option Filters -> Edit -> Add Filter -> Option
Filter.
3. In the Option Filter editor, enter the filter name as i86pc and select the Option Space SUNW from the dropdown
menu.
4. Select an option, specify a value for it, and add it to the i86pc option filter. You can select multiple options. Add
the following options to the i86pc option filter:
Option name
Code
Type
root-server-ip-address
2
IP address
root-server-host-name
3
Text
root-server-path-name
4
Text
boot-file-path-name
7
Text
5. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> + (for Option Filters) -> i86pc -> Edit -> Add
Filter -> Add Match Rule.
6. In the Match Rule editor that appears:
•
Click Match Rule Properties.
— Match Option: Select option 60: vendor-class-identifier from the dropdown menu.
— Match Value: Enter SUNW.
•
Click the Value is a Substring checkbox and enter the following:
— Substring Offset: Enter 0
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
391
Configuring DHCP Services
— Substring Length: Enter 4.
7. Apply the option filter i86pc to a DHCP address range. From the DHCP and IPAM perspective, Select Networks ->
Edit > Add Network -> Network. See Configuring a DHCP Network on page 350 for instructions on how to add a
network.
8. Add a DHCP range to the network. See Adding a DHCP Range on page 357.
9. In the DHCP Range editor, click Filter Rules and under Option Filter Rules, click Add.
10. The Option Filter Rule dialog box appears. Click Select Filter and select the i86pc option filter from the list. Under
If client matches this filter, select Grant lease, and click OK. The option filter appears in the Option Filter Rules list.
11. Click the Save and Restart Services icons.
When the DHCP server receives a client packet that contains the option and the matching option value, it
returns the options in the option filter to the client.
Example DHCP Configuration File
The following example shows the DHCP configuration file (dhcp.conf) after you add an option space and option filters
and match lists. See Configuring Advanced DHCP Options on page 380.
option space SUNW;
option SUNW.server-address code 2 = ip-address;
option SUNW.server-name code 3 = text;
option SUNW.root-path code 4 = text;
After you define an option space and the format of some options, you can set up classes (option filters) to define
values for the options. For example, to handle two different client classes, you can define two classes and send
different option values to different clients based on the vendor-class-identifier option that the clients send as
follows:
class "vendor-class_1" {
match if substring (option vendor-class-identifier, 0, 15) = "SUNW.Ultra-5_10";
vendor-option-space SUNW;
option SUNW.root-path "/export/root/sparc";
option SUNW.server-address 172.17.65.1;
option SUNW.server-name "sundhcp-server17-1";
}
class "vendor-class_2" {
match if substring (option vendor-class-identifier, 0, 10) = "SUNW.i86pc";
vendor-option-space SUNW;
option SUNW.root-path "/export/root/i86pc";
option SUNW.server-address 172.17.65.1;
option SUNW.server-name "sundhcp-server17-1";
}
When the DHCP server receives a client packet that contains the option and the matching option value, it returns the
options in the class to the client.
Configuring User Class Filters
The Infoblox device can filter DHCP address requests by user class filters. A user class indicates a category of user,
application, or device of which the DHCP client is a member. User class identifiers are configured on DHCP clients and
are sent during a DHCP address request operation. The client includes the user class identifier in DHCP option 77
when sending DHCPDISCOVER and DHCPREQUEST messages.
392
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example
By using user class identifiers, a DHCP server can screen address requests and assign addresses from select address
ranges based on the different user class IDs it receives. For example, if you assign a user class filter named mobile to
a range of addresses from 10.1.1.31–10.1.1.80, the Infoblox device selects an address from that range if it receives
an address request that includes the user class name mobile and there are still addresses available in that range.
You might want mobile users to receive these addresses because you have given them shorter lease times than other,
more stationary DHCP clients. See Figure 14.6.
Figure 14.6 Applying User Class Filtering
The user class for laptop A is mobile. When it
sends DHCPDISCOVER and DHCPREQUEST
messages, it includes its user class in the
DHCP option 77 field.
The Infoblox device has a filter that screens
address requests by user class. If the user class
for a DHCP client is mobile, the device assigns it
an address from address range 2.
Laptop A receives 10.1.1.80
from address range 2.
Infoblox Device
Laptop A
User Class = mobile
Network
Note: The leases for addresses in
address range 2 are shorter than
those for more stationary
computers. The intended use for
address range 2 is to provide IP
addresses for mobile users who log
in to the network for relatively short
periods of time and, therefore, do
not require longer leases.
10.1.1.0/24
Address Range 1
10.1.1.20 10.1.1.30
Address Range 2
10.3.1.31 10.3.1.80
Address Range 3
10.3.1.81 10.3.1.160
If the Infoblox device receives address requests with the user class mobile and there are no available addresses in
address range 2 but there are available addresses in ranges 1 and 3, the device begins assigning addresses from
address range 3 (because its addresses are higher than those in range 1). Then, if all addresses in range 3 are in use,
the device begins assigning addresses from address range 1. If you want the device to assign addresses to mobile
users (that is, those identified with the user class mobile ) exclusively from address range 2, then you must apply user
class filters for mobile to address ranges 1 and 3 that deny lease requests matching that user class.
Defining a User Class Filter
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) ->+ (for Option Filters) -> OptionFilter -> Edit
-> Add Filter -> Add Match Rule.
Click Match Rule Properties.
— Match Option: Select Option 77: user-class from the dropdown menu.
— Match Value: Enter a value for the match option (such as SUNW) you selected.
— Click the Value is a Substring checkbox and enter:
— Substring Offset: Enter the value of the offset at which the substring starts in the option data received from
the client. For example, enter 0.
— Substring Length: Enter the length of the match value. For example, if the match value is SUNW, enter 4.
2. Click the Save and Restart Services icons.
To apply a user class filter to an address range, see Applying an Option Filter to an Address Range on page 390.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
393
Configuring DHCP Services
Configuring a Relay Agent Filter
The typical relationship between a DHCP client, relay agent, and server (that is, the Infoblox device) on a network is
as follows:
1. A DHCP client broadcasts a DHCPDISCOVER message on its network segment.
2. A DHCP relay agent on that segment receives the message and forwards it as a unicast message to one or
more DHCP servers (such as Infoblox devices).
3. If the Infoblox device accepts the address request, it responds to the relay agent with a DHCPOFFER
message. (If the device denies the request, it does not send any response in case other DHCP servers that
might be involved respond instead.)
4. The relay agent forwards the response to the client, usually as a broadcast message.
The situation is different for individual hosts connecting to the Internet through an ISP, usually over a circuit-switched
data network.
1. A host connects to its ISP’s circuit access concentration point, authenticates itself, and requests an IP
address.
2. The circuit access unit relays the address request to a DHCP server, which responds with a DHCPOFFER
message.
3. To avoid broadcasting the DHCPOFFER over the network segment on which the host made the request, the
relay agent sends the response directly to the host over the established circuit.
The Infoblox device can screen address requests through relay agent filters (DHCP option 82) that assist the agents
in forwarding address assignments across the proper circuit. When a relay agent receives the DHCPDISCOVER
message, it can add one or two agent IDs in the DHCP option 82 suboption fields to the message. If the agent ID
strings match those defined in a relay agent filter applied to a DHCP address range, the Infoblox device either assigns
addresses from that range or denies the request (based on previously configured parameters; that is, the Grant lease
and Deny lease parameters).
The two relay agent filters are as follows:
— Agent circuit ID: This filter identities the circuit between the remote host and the relay agent. For example,
the identifier can be the ingress interface number of the circuit access unit, perhaps concatenated with the
unit ID number and slot number). The circuit ID can also be an ATM virtual circuit ID or cable data virtual
circuit ID.
— Agent remote ID: This filter identifies the remote host. The ID can be the caller ID telephone number for a
dial-up connection, a user name for logging in to the ISP, a modem ID, and so on. Because the remote ID is
defined on the relay agent, which is presumed to have a trusted relationship with the DHCP server, and not
on the untrusted DHCP client, the remote ID is also presumably a trusted identifier.
Note: For information about the relay agent options, see RFC 3046, DHCP Relay Agent Information Option.
394
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuration Example
Figure 14.7 Relay Agent Filtering
Sample client ID types:
Sample remote ID types:
• Unit-slot-port number of network
access server
• User name (as prompted by
network access server)
• ATM virtual circuit number
• Remote caller ATM address
• Cable data virtual circuit number
• Modem ID for a cable data modem
The Remote ID is
set on the relay
agent to identify
the remote host.
Remote Host
DHCP Client
Circuit ID
Remote ID
Switched Circuit
Network Access
Point
Relay Agent
Internet
DHCPDISCOVER
DHCPDISCOVER +
Option 82 Data
• Remote ID
• Circuit ID
The relay agent adds option 82 data to
DHCPDISCOVER and DHCPREQUEST
messages that it receives from the DHCP client.
DHCP Option 82 suboptions can specify a
remote ID for the DHCP client and a circuit ID
for the connection between the client and the
access point.
Infoblox Device
DHCP Server
The Infoblox device checks for a
match between the remote and
circuit identifiers in the address
request and its filters for address
ranges. When it finds a match, it
assigns the DHCP client an
address from that address range.
Defining a Relay Agent Filter
You can enable and define either or both of the relay agent ID types. If you apply both ID types, then a relay agent
must provide both identifiers when submitting a DHCP address request.
1. From the DHCP and IPAM Perspective, click Networks -> + (for Filters) -> Relay Agent Filters -> Edit -> Add Filter ->
Relay Agent Filter.
2. To define a relay agent filter, enter the following:
— Filter Name: Type a meaningful name for the filter, such as the IP address or name of the router acting as
relay agent.
— Agent Circuit ID: Select this check box and enter the ID.
— Agent Remote ID: Select this check box and enter the ID.
You can enter the agent circuit ID and remote ID as an ASCII string. Alternatively, to enter binary data, you
can enter hexadecimal values in the format \xnn, where nn is any positive hexadecimal number less than or
equal to 0xff. The following examples shows an ID represented in a 17 byte text string and 6 byte binary
string:
Text String: 001122334455
Binary String: \x00\x11\x22\x33\x44\x55
3. Click the Save and Restart Services icons.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
395
Configuring DHCP Services
Applying a Relay Agent Filter to an Address Range
1. From the DHCP and IPAM Perspective, click Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties.
2. In the Configure DHCP Range editor, click Filter Rules.
3. Click Add beside Relay Agent Filter Rule.
4. In the Relay Agent Filter Rule dialog box, click Select Filter.
5.
In the Select Relay Agent Filter dialog box, select the relay agent filter that you previously defined and click OK.
6. Select either Grant lease or Deny lease.
— To assign addresses from the address range when one or both of the relay agent ID definitions matches an
entry in the relay agent filter, select Grant lease.
— To refuse an address request when one or both relay agent ID definitions matches an entry in the relay
agent filter, select Deny lease.
7. Click the Save and Restart Services icons.
Note: You can add other filters in combination for the same address range. See Configuring a MAC Address Filter
on page 387 and Configuring User Class Filters on page 392.
Managing DHCP Filters
After you apply filters to an IP Address range, you can navigate to the Filter Rules section of the Configure DHCP Range
editor and use Modify to change their setting to deny or grant leases. You can also use Remove to remove a filter from
the filter list applied to the address range. You can then delete the filter if it is not applied to an address range. To
delete a filter, select it and click Edit -> Remove.
Make sure that none of the filters that you want to delete is still in use. If it is, remove the filter from any address
ranges to which it is applied.
Instead of deleting DHCP filters individually, you can select multiple filters and then delete the entire selected group.
To select a contiguous set of filters between filter-1 and filter-n :
— Press and hold down the SHIFT key and click filter-n.
or
— Continue pressing the left mouse button and drag the mouse from filter-1 and filter-n .
You must restart services on the grid after you remove filters.
396
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP Failover
Configuring DHCP Failover
You can configure two Infoblox devices in a DHCP failover association for service redundancy. This pairing of a primary
and secondary server is called a peer association. The peers establish a TCP connection for their communications.
They share a pool of IP addresses which they allocate to hosts on their network. The pool of available addresses is
divided evenly between the servers. DHCP failover allows either the primary or secondary DHCP server to assume
control of DHCP services in case either of the two servers fails.
DHCP Failover Tasks
Following are the tasks and guidelines for configuring DHCP failover on two DHCP servers:
1. Configure the primary and secondary DHCP servers, as described in the preceding sections in this chapter.
— You can configure a failover association with two Infoblox devices, or with an Infoblox device and an ISC
DHCP compliant server.
— Configure the same operational parameters on both servers. Both servers must be able to receive
DHCPDISCOVER messages that hosts broadcast on the network.
— The servers do not have to be in the same geographic location.
— A device can participate in more than one failover association, as long as it is with a different device. Each
peer association must be unique.
— Do not enable DHCP until after you complete the DHCP failover configuration.
2. Create the failover association, as described in Creating a Failover Association on page 398.
— Identify the primary and secondary peer.
— Specify a unique name for the failover association. Enter the same DHCP failover peer association name on
both the primary and secondary DHCP servers. The failover association name is case sensitive. The names
must be exactly the same on both servers.
— If you change any of the DHCP failover parameters for a peer association definition, you must make the
changes on both the primary and secondary servers.
3. Configure the network for the failover association on both the primary and secondary servers, as described in
Configuring a DHCP Network on page 350.
— Assign the primary and secondary servers in the failover association to the network. You can assign other
members to the network as well.
— You can configure multiple failover associations in a network.
— If you configured a shared network, and the subnets in the shared network contain ranges served by a
DHCP failover association, both the primary and secondary DHCP server should have the same shared
networks defined, containing the same networks, and DHCP ranges.
WARNING: If you have multiple networks/subnets that are contained in a shared network, and plan to use
DHCP failover, you must do the following:
•
Use failover on all of the networks in a shared network.
•
Specify the same peer for all the networks in your shared network.
4. Define the IP address range for the failover association on both the primary and secondary servers, as described
in Adding a DHCP Range on page 357.
— Assign the failover association to the address range. Do not assign grid members to the address range.
5. Enable DHCP on the primary and secondary servers.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
397
Configuring DHCP Services
Creating a Failover Association
To create the DHCP failover association, perform the following steps on the primary and secondary servers:
1. From the DHCP and IPAM perspective, click Edit -> Add Failover Association.
2. Enter the following information:
— Peer Association Name: Enter a name for the peer association.
— DHCP Failover Primary
— Grid Primary Server: Click Select member and select the primary peer from the drop-down menu.
— Use External Primary: Select this check box to use a primary server that is not part of the grid.
— External Primary IP: Enter the IP address of the primary server.
— DHCP Failover Secondary
— Grid Secondary Server: Click Select member and select a secondary peer from the drop-down menu.
— Use External Secondary: Select this check box to use a secondary server that is not part of the grid.
— External Secondary IP: Enter the IP address of the secondary server.
— Max Response Delay Before Failover: Specifies how many seconds can transpire before the primary server
assumes its peer (the secondary server) is not sending messages due to failure. The default is 60 seconds.
— Max Number of Unacked Updates: Specifies how many update messages the server can send before it
should receive an ACK from the failover peer. If no ACK is received after these messages are sent, failover
occurs. The default is 10 messages.
— Max Client Lead Time (MCLT): Specifies the length of time that a failover peer can renew a lease without
contacting the other peer. The larger the number, the longer it takes for the peer server to recover IP
addresses after moving to the Partner Down mode. The smaller the number, the more load your servers
experience when they are not communicating. This is specified on the primary server only. The default is
3600.
— Max Load Balancing Delay: Specifies the cutoff after which load balancing is disabled. The cutoff is based
on the number of seconds since the client sent its first DHCPDISCOVER or DHCPREQUEST message. For
instance, if one of the failover peers gets into a state where it is responding to failover messages, but not
responding to some client requests, the other failover peer will take over its client load automatically as the
clients retry. The default value is 3.
— Load Balancing Split: Determines which server handles IP address requests. You must specify a value from
0 through 255 on the primary server only. If you specify 0, then the secondary server responds to all IP
address requests. If you specify 255, then the primary server responds to all IP address requests. Infoblox
highly recommends that you use 128, which is the default value, to enable the primary and secondary
servers to respond to IP address requests on an equal basis.
— Override lease deletion setting: Select this check box to override settings at the grid and member levels.
— Keep leases from deleted ranges until one week after expiration: If you select this check box and delete
a DHCP range with active leases, the device stores these leases up to one week after they expire. When
you add a new DHCP range that includes the IP addresses of these active leases, the device
automatically restores these leases.
3. Click the Save and Restart Services icons.
398
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP Failover
Monitoring the Failover Association
After you configure the failover association, the peers establish a TCP connection between themselves for their
communications. They send keepalive messages and database updates every time they grant a lease. You can view
the following to monitor the failover association:
•
DHCP Failover Status: Click View -> DHCP Failover Status to verify that the devices are operating and
communicating as failover peers. For each failover association, it displays the name, the host name or IP
address of the primary and secondary servers, and the operational status of each server.
•
IP Address Management: Click View -> IP Address Management to view the allocation status of IP addresses. The
primary server allocates IP addresses with a status “Free” and the secondary server allocates IP addresses with
a status of “Backup”. The servers always try to maintain a 50-50 split of the available addresses. Their
individual pools adjust so they each have half of the available addresses.
Failover Association Operations
When a host broadcasts a DHCPDISCOVER message, it includes its MAC address. Both the primary and secondary
peers receive this message. To determine which server allocates an IP address to the host, they each extract the MAC
address from the DHCPDISCOVER message and perform a hash operation. Each server then compares the result of its
hash operation with the configured load balancing split. This is typically set to 128, to ensure an even split between
the two servers. If the load balancing split is 128, the primary server allocates the IP address if the hash result is
between 1 and 127, and the secondary server allocates the IP address if the hash result is between 128 and 255. As
a server allocates an IP address, it updates its peer to so their databases remain synchronized.
As shown in Figure 14.8, when a host broadcasts a DHCPDISCOVER message, both the primary and secondary servers
receive the message. They perform a hash operation on the MAC address in the DHCPDISCOVER message, and the
result is 250. The load balancing split is 128. Because the hash result is 250, the secondary server responds to the
host with a DHCPOFFER message. The secondary peer allocates an IP address from its assigned pool of IP addresses.
Figure 14.8 Allocating IP Addresses
2 Both servers receive the DHCP
1 When a host broadcasts a
DISCOVER message. Each
server performs a hash on the
MAC address, and the result is
250.
DHCPDISCOVER message, it
includes its MAC address.
Primary Server
= 250
Secondary Server
3 The load balancing split is 128,
Therefore, since the hash result
is between 128 and 255, the
secondary server responds to
the host and allocates the IP
address to the host.
A failover occurs when any of the timers you configured expires. (See Creating a Failover Association on page 398.)
The secondary server takes over and assigns all IP addresses with the lease time set in the MCLT field. When the
primary server comes back online, it synchronizes its database with its peer before it starts allocating IP addresses.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
399
Configuring DHCP Services
Viewing DHCP Files
This section describes some of the DHCP files and logs that you can view. For additional information about monitoring
DHCP, see Chapter 16, Managing IP Data – IPAM, on page 419.
Viewing a DHCP Configuration File
To view a DHCP configuration file, from the DHCP and IPAM Perspective, click DHCP Members -> grid -> member -> View
-> DHCP Configuration.
Viewing DHCP Statistics
To view information about a network, from the DHCP and IPAM Perspective, click Networks -> + (for Networks) ->
network -> View -> Network Statistics. This panel displays the following information about the selected network:
•
Node IP: The IP address of the grid member serving DHCP in the network.
•
Static Hosts: The number of hosts with fixed addresses.
•
Dynamic Hosts: The number of hosts that were assigned dynamic IP addresses.
•
Available Hosts: The number of available IP addresses.
•
Usage: The percent of addresses in use.
400
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Chapter 15 Configuring DDNS Updates
from DHCP
DDNS (Dynamic DNS) is a method to update DNS data (A, TXT, and PTR records) from sources such as DHCP servers
and other systems that support DDNS updates (for example, Windows 2000, 2003, and XP). This chapter provides
conceptual information about DDNS and explains how to configure Infoblox devices running DHCP and DNS to
support DDNS updates. It contains the following main sections:
•
•
•
•
Understanding DDNS Updates from DHCP on page 402
Configuring DHCP for DDNS on page 405
— Specifying a Domain Name for DHCP Clients on page 406
— Configuring DDNS on the DHCP Server on page 407
— Sending Updates to DNS Servers on page 408
— Client FQDN Option (Option 81) on page 409
— Generating Host Names for DNS Updates on page 411
— Updating DNS for Clients with Fixed Addresses on page 412
— Resending DNS Updates
Configuring DNS for DDNS on page 413
— Enabling the DNS Server to Receive Updates on page 413
— Forwarding Updates on page 415
Authenticating Updates with TSIG on page 416
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
401
Configuring DDNS Updates from DHCP
Understanding DDNS Updates from DHCP
DHCP supports several DNS-related options (such as options 12, 15, and 81). With DDNS (Dynamic DNS) updates, a
DHCP server or client can use the information in these options to inform a DNS server of dynamic domain name-to-IP
address assignments.
To set up one or more Infoblox devices for DDNS updates originating from DHCP, you must configure at least one DHCP
server and one DNS server. These servers might be on the same device or on separate devices. Three possible
arrangements for a DHCP server to update a DNS server are shown in Figure 15.1.
Figure 15.1 Relationship of DHCP and DNS Servers for DDNS Updates
DDNS when the DHCP server and primary DNS server
are on the same Infoblox device.
1
DDNS Update
Router
Secondary DNS
Server
DHCP Server and
Primary DNS Server
2
Zone Transfer
DDNS when the DHCP server and primary DNS server are on the different
Infoblox devices and the DHCP server updates the primary DNS server.
DDNS Update
1
Router
Router
Secondary DNS
Server
DHCP
Server
Primary DNS
Server
Zone Transfer
2
DDNS when the DHCP server and primary DNS server are on the different
devices and the DHCP server updates a secondary DNS server.
DDNS Update
1
Forwarded DDNS Update
2
Router
DHCP
Server
Router
Secondary DNS
Server
Primary DNS
Server
Zone Transfer
402
Infoblox Administrator Guide (Rev. A)
3
NIOS 4.1r3
Understanding DDNS Updates from DHCP
Here is a closer look at one setup for performing DDNS updates from a DHCP server (the steps relate to Figure 15.2):
1. When a DHCP client requests an IP address, the client sends its host name (DHCP option 12). The client also
includes its MAC address in the ethernet frame header.
2. When the DHCP server responds with an IP address, it also provides a domain name (DHCP option 15).
3. The combined host name (from the client) and domain name (from the server) form an FQDN (fully qualified
domain name), which the Infoblox device associated with the IP address in the DHCP lease.
4. The DHCP server sends the A, TXT, and PTR records to the primary DNS server to update its resource records with
the dynamically associated FQDN + IP address.
5. The primary DNS server notifies its secondary server or servers of a change. After confirming the need for a zone
transfer, the primary server sends the updated zone data to the secondary server, completing the update.
Note: For information about zone transfers, see Allowing Zone Transfers for a Zone on page 326.
Figure 15.2 DDNS Update from a DHCP Server
Update for forward-mapping zone corp100.com
A record: jsmith-xp - 10.1.2.90
Ethernet
Frame
Source MAC
11:11:11:11:11:11
Destination MAC
ff:ff:ff:ff:ff:ff (broadcast)
TXT record: jsmith-xp “31995a5ea0681ee5d2f6e06ad0d0477e84”
DHCP OFFER
Updatefor
forreverse-mapping
reverse-mappingzone
zone
Update
2.1.10-in-addr.arpa
2.1.10.in-addr.arpa
Option:12, host name = jsmith-xp
PTRrecord:
record:90
90-–jsmith-xp.corp100.c0m
jsmith-xp.corp100.com
PTR
1
DHCP
Client
3
Router
Switch
DHCP
Server
2
DHCP OFFER
IP Address: 10.1.2.90
Option: 15, domain name: corp100.com
DHCP Range
10.1.2.10 10.1.2.100
Network
10.1.2.0/24
Note: The DHCP server attempts to update DNS for a
particular lease before sending the DHCP ACK to the client
requesting the lease. However, if the DNS update is
unsuccessful, the DHCP client still gets its lease. The
DHCP server then continues its DNS update attempts at
predefined or user-defined intervals.
NIOS 4.1r3
Primary DNS
Server
ns1.corp100.com
Router
Secondary DNS
Server
ns2.corp100.com
4
When the update reaches the
primary server, it updates its
zone data, increases the
corp100.com zone serial
number, and sends a NOTIFY
to ns2.
When the secondary server
receives the NOTIFY, it checks
ns1 to see if the serial numbers
for corp100.com match.
Because the serial numbers
are different, ns2 requests an
incremental zone transfer
(IXFR).
ns1 sends the changed
zone data to ns2.
Infoblox Administrator Guide (Rev. A)
403
Configuring DDNS Updates from DHCP
To enable a DHCP server to send DDNS updates to a DNS server, you must configure both servers to support the
updates. First, configure the DHCP server to do the following:
•
Provide what is needed to create an FQDN: add a server-generated host name to a server-provided domain
name, add a server-provided domain name to a client-supplied host name, or permit the client to provide its
own FQDN
•
Send updates to a DNS server
Then, configure the following on the DNS server:
•
Accept updates from the DHCP server, a secondary DNS server, or a DHCP client
•
If the DHCP server sends updates to a secondary DNS server, configure it to forward updates to the primary DNS
server
When setting up DDNS, you can determine the amount of information that DHCP clients provide to a DHCP server—
and vice versa—and where the DDNS updates originate. A summary of these options is shown in Figure 15.3.
Figure 15.3 DHCP Clients and Server Providing DNS Information and Updates
DHCP Client
DHCP Server
DHCPDISCOVER
DHCPOFFER with an IP address and
configuration parameters, and a domain
name (option 15) to combine with a DHCP
server-generated host name when the
server sends a DNS update.
OR
DHCPDISCOVER with a host name
(option 12)
DHCPOFFER with an IP address and
configuration parameters, and a domain
name (option 15) to combine with the
client-provided host name when the server
sends a DDNS update
OR
DHCPDISCOVER with an FQDN and
DDNS update instructions (option 81)
DNS Server
For DHCP to update DNS dynamically, a
DHCP client must have an FQDN. The
DHCP server can assign one or work
with the client to create one, or the client
can provide an FQDN itself.
Because clients send a DHCP server
varying amounts of DNS-related
information (nothing, a host name, or an
entire FQDN), you can configure the
server to provide whatever missing
information is necessary to construct an
FQDN, depending on how much or how
little each client provides.
You can also configure the DHCP server
to disregard DNS-related information
from clients and apply its own settings.
For example, you might want the DHCP
server to always assign the domain name
(even when a client provides its own
FQDN), or you might want only the
DHCP server to update the DNS server
(even when a client requests to make its
own updates).
DHCPOFFER with an IP address and
configuration parameters.
Setting the DHCP server to update all
resource records ensures that new A
records do not overwrite existing A records,
which can happen if two hosts send the
same FQDN.
Optionally, you can set the DHCP server to
update PTR records and allow clients to
update their own A records.
DHCP server updates the DNS server with
A, TXT, and PTR records.
OR
DHCP server updates the DNS server with
a PTR record (option 81).
DHCP client updates the DNS server with its own A record (option 81).
404
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP for DDNS
You can make the DHCP and DNS settings for DDNS at the grid level, member level, and network and zone level. By
applying the inheritance model in NIOS, settings made at the grid level apply to all members in the grid. Settings you
make at the member level apply to all networks and zones configured on that member. Settings made at the network
and zone level apply specifically to just that network and zone. When configuring independent devices (that is,
devices that are not in a grid), do not use the member-level settings. Instead, configure DDNS updates at the grid level
to apply to all zones and, if necessary, override the grid-level settings on a per zone basis.
Configuring DHCP for DDNS
To configure the DHCP server to send DDNS updates, you must perform the following tasks:
•
Specify the domain name that the DHCP server provides to DHCP clients for DDNS updates.
For information, see Specifying a Domain Name for DHCP Clients on page 406
•
Enable the DHCP server to send DDNS updates.
•
Specify the DNS servers to which the DHCP server sends the updates.
For information, see Configuring DDNS on the DHCP Server on page 407.
For information, see Sending Updates to DNS Servers on page 408
You can also enable the following features for DDNS updates:
•
The DHCP server can support option 81, the Client FQDN option. The DHCP client sends this option which
contains either the host name or FQDN of the client, and instructions on whether the client or the server should
perform the update.
For information, see Client FQDN Option (Option 81) on page 409
•
The DHCP server can generate an FQDN and update DNS with this FQDN when a client does not send a host
name.
For information, see Generating Host Names for DNS Updates on page 411
•
The DHCP server can send DDNS updates for clients with fixed addresses.
For information, see Updating DNS for Clients with Fixed Addresses on page 412
•
The DHCP server can make repeated attempts to sends DDNS updates.
For information, see Resending DNS Updates on page 412
You can define the settings for dynamic DNS at the grid level, member level, network, shared network and address
range level. Settings you define at the grid level apply to all members in the grid. Settings you make at the member
level apply to all networks on that member. Settings made at the network, shared network or address range level
apply specifically to just that network, shared network or address range. You can also enable DDNS for a fixed address
and specify a domain name for it.
Note: Whether you deploy Infoblox devices in a grid or independently, they send updates to UDP port 53. Grid
members do not send updates through a VPN tunnel; however, grid members do authenticate updates
between each other using TSIG (transaction signatures) based on an internal TSIG key.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
405
Configuring DDNS Updates from DHCP
Specifying a Domain Name for DHCP Clients
Before a DHCP server can update DNS, the DHCP server needs to have an FQDN-to-IP address mapping. When a DHCP
client requests an IP address, it typically includes its host name in option 12 of the DHCPDISCOVER packet. You can
configure the Infoblox device to include a domain name in option 15 when it responds with a DHCPOFFER packet. The
appliance then combines the host name from the client and the domain name you specify to create the FQDN that it
uses to update DNS.
You can enter a domain name for a grid, member, network, shared network, address range and fixed address.
Grid Level
To add the domain name at the grid level:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the General Properties section of the Grid DHCP Properties editor, enter the Domain Name in the text field.
3. Click the Save icon.
Member Level
To override the grid-level settings and add the domain name at the member level:
1. From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties.
2. Click General Properties and enter the member level Domain Name in the text field.
3. Click the Save icon.
Network Level
To add the domain name for a network or shared network, follow the navigational path below and override the
member-level settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> General DHCP Options.
Address Range Level
To add the domain name for a range of IP addresses, follow the navigational path below and override the
network-level settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> General DHCP Options.
Fixed Address Level
To add the domain name for a fixed address, follow the navigational path below and override the address range-level
settings.
•
406
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
ip_addr -> Edit -> Fixed Address Properties -> General Properties.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP for DDNS
Configuring DDNS on the DHCP Server
You can enable DDNS on a grid, member, shared network, network, address range and fixed address.
Grid Level
To enable DDNS on a grid:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click DNS Updates.
3. In the DNS Updates section, select Enable dynamic DNS updates.
4. Click the Save icon.
5. Click the Restart Services icon.
Member Level
To enable DDNS for a member, follow the navigational path below and override the grid-level settings. Restart service
after you save the settings.
•
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid ) -> member -> Edit -> Member DHCP
Properties -> DNS Updates.
Network Level
To enable DDNS on a network, follow the navigational path below and override the member-level settings. Restart
service after you save the settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> Network Properties -> DNS Updates.
Address Range Level
To enable DDNS for a range of IP addresses, follow the navigational path below and override the network-level
settings. Restart service after you save the settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> DNS Updates.
Fixed Address Level
To enable DDNS for a fixed address, follow the navigational path below and override the address range-level settings.
Restart service after you change the settings.
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
ip_addr -> Edit -> Fixed Address Properties -> DNS Updates.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
407
Configuring DDNS Updates from DHCP
Sending Updates to DNS Servers
The DHCP server can send DDNS updates to DNS servers in the same grid and to external DNS servers. You specify
the DNS servers at the grid level only.
Sending Updates to DNS Servers in the Grid
When you enable the device to send updates to grid members, you must specify which view receives the updates. For
information abut views, see Using Infoblox Views on page 250. To configure the DHCP server to send updates to DNS
servers in the same grid:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. Click DNS Updates.
3. Enter the following:
— Internal updates to: Click Select View to open the Select DNS View dialog box. Select the view to receive
updates and click OK.
— Enable dynamic DNS updates: Select check box.
4. Click the Save icon.
5. Click the Restart Services icon.
Sending Updates for Zones on an External Name Server
The DHCP server can send dynamic updates to an external name server that you specify. You can specify the zone to
be updated and the IP address of the primary name server for that zone. You can add information for a forward and
reverse zone. The DHCP server updates the A record in the forward zone and the PTR record in the reverse zone. You
can also use TSIG (transaction signatures) to secure communications between the servers. For information about
TSIG, see Authenticating Updates with TSIG on page 416.
To send updates to a DNS server that is external to your grid:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. Click DNS Updates.
3. To update a forward zone, click Add beside External Forward Zones to Update.
4. In the External Forward Zone dialog box, enter the following:
— Zone Name: Enter the name of the zone that receives the updates.
— Name Server Address: Enter the IP address of the primary name server for that zone.
— Use TSIG: Select if you want to use TSIG. You can either specify an existing key or generate a new key.
— To specify an existing key:
•
Key name: Enter the domain name for the zone of this TSIG key. The Key Name entered here must
match the TSIG key name on the external name server.
•
Key: Type or paste the key.
•
To generate a new key, click Generate.
5. Click OK to close the External Forward Zone dialog box.
6. To update a reverse zone, click Add beside External Reverse Zone.
7. In the External Reverse Zone dialog box, enter the following:
— Zone Name: Enter the name of the zone that receives the updates.
— Name Server Address: Enter the IP address of the primary name server for that zone.
408
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP for DDNS
— Use TSIG: Select if you want to use TSIG. You can either specify an existing key or generate a new key.
— To specify an existing key:
•
Key name: Enter the domain name for the zone of this TSIG key. The Key Name entered here must
match the TSIG key name on the external name server.
•
Key: Type or paste the key.
•
To generate a new key, click Generate.
8. Click OK to close the External Reverse Zone dialog box.
9. Select Enable dynamic DNS updates.
10. Click the Save icon.
11. Click the Restart Services icon.
Client FQDN Option (Option 81)
When a DHCP client sends DHCP DISCOVER and DHCP REQUEST messages, it can include option 81, the Client FQDN
option. This option contains either the host name or FQDN (fully qualified domain name) of the client, and
instructions on whether the client or the server performs the DDNS update.
The DHCP server can support this option and use the host name or FQDN that the client provides for the update. It
can also allow or deny the client’s request to update DNS, according to the administrative policies of your
organization. The DHCP server indicates its response in the DHCP OFFER message it sends back to the client.
Sending Updates with Option 81 Enabled
When you enable the DHCP server to support option 81, it uses the information provided by the client to update DNS
as follows:
•
When a DHCP client sends a DHCP request with option 81, it can include either the FQDN or only the host name
of the client.
— If the request includes the FQDN, the DHCP server uses this FQDN to update DNS.
— If the request includes the host name, the DHCP server provides the domain name. It combines the host
name of the client and the domain name to create an FQDN for the client. It then updates DNS with the
FQDN it created. (You can enter the domain name in the General page of the DHCP Properties window. For
information, see Specifying a Domain Name for DHCP Clients on page 406.)
•
When a DHCP client sends a DHCP request with its host name (option 12), the DHCP server adds the domain
name you specified to create an FQDN for the client. It then updates DNS with the FQDN it created. (For
information about entering the domain name, see Specifying a Domain Name for DHCP Clients on page 406.)
•
When a DHCP client does not send a host name, the DHCP server provides a lease but does not update DNS.
You can configure the DHCP server to generate a host name and update DNS as described in Generating Host
Names for DNS Updates on page 411.
•
If multiple DHCP clients specify the same FQDN or host name, the DHCP server allocates leases to the clients,
but updates DNS only for the client that first sent the request. When it tries to update DNS for the succeeding
clients, the update fails.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
409
Configuring DDNS Updates from DHCP
Sending Updates from DHCP Clients or Server
When you enable the DHCP server to support option 81, you must decide if you want the DHCP server to allow clients
to update DNS. If you allow the client to update DNS, then the client updates its A record only. The DHCP server always
updates the PTR records. You can configure the DHCP server as follows:
•
The DHCP server can allow clients to update DNS when they send the request in option 81. This is useful for
small sites where security is not an issue or in sites where clients move from one domain to another and want to
maintain the same FQDN regardless of administrative domain.
If you configure the DHCP server to allow clients to perform DNS updates, you must also configure the DNS
server to accept these updates from clients. Note that multiple clients can use the same name, resulting in
multiple PTR records for one client name.
When a lease expires, the DHCP server does not discard the A record if it was added by the client.
•
The DHCP server can refuse the DHCP client’s request to update DNS and always perform the updates itself.
When the DHCP server updates DNS, it uses the FQDN provided by the DHCP client. Select this option if your
organization requires tighter control over your network and does not allow clients to update their own records.
If you do not enable support for option 81 and a client includes it in a DHCP request with its FQDN, the DHCP server
does not use the FQDN of the client. Instead, it creates the FQDN by combining the host name from the client with the
domain name specified in the DHCP Properties dialog box.
Configuring Support for Option 81
You can define the settings for option 81 at the grid level, member level, network and shared network level.
To enable support for option 81 at the grid level:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click DNS Updates.
3. Enter the following:
— Enable dynamic DNS updates: Select check box.
— Enable option 81 support: Select check box.
— DHCP server updates DNS only if requested by client: Select this check box to allow clients to update DNS
when they request it.
Or
— DHCP server always updates DNS: Select this check box to allow only the DHCP server to update DNS,
regardless of the requests from the DHCP clients.
4. Click the Save icon.
To configure option 81 settings for a member, follow the navigational path below and override the grid-level settings:
•
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> DNS Updates.
To configure option 81 settings for a network or shared network, follow the navigational path below and override the
member-level settings:
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> DNS Updates.
When a lease expires, the DHCP server removes the A and PTR records that it updated. It does not remove any records
that the client updated.
410
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DHCP for DDNS
Generating Host Names for DNS Updates
Some clients do not send a host name with their DHCP requests. When the DHCP server receives such a request, its
default behavior is to provide a lease but not update DNS. You can configure the DHCP server to generate a host name
and update DNS with this host name when it receives a DHCP REQUEST message that does not include a host name.
It generates a name in the following format: DHCP-WWW-XXX-YYY-ZZZ, where WWW-XXX-YYY-ZZZ is the IP address of
the lease. For example, if this feature is enabled and the DHCP server receives a DHCP REQUEST from a DHCP client
with IP address 10.1.1.1 and no host name, the DHCP server generates the name dhcp-10-10-10-1 and uses this
name for the DDNS update.
You can define the host name settings at the grid level, member level, network, shared network, and DHCP address
range level.
Grid Level
To allow the DHCP server to generate a host name at the grid level:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click DNS Updates.
3. Enter the following:
— Enable dynamic DNS updates: Select check box.
— Generate hostname if not sent by client: Select check box.
4. Click the Save icon.
5. Click the Restart Services icon.
Member Level
To allow the DHCP server to generate a host name at the member level, follow the navigational path below and
override the grid-level settings:
•
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> DNS Updates.
Network Level
To allow the DHCP server to generate a host name for a shared network or network, follow the navigational path below
and override the member-level settings:
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> DNS Updates.
Address Range Level
To allow the DHCP server to generate a host name for an address range, follow the navigational path below and
override the network-level settings:
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network ->
addr_range -> Edit -> DHCP Range Properties -> DNS Updates.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
411
Configuring DDNS Updates from DHCP
Updating DNS for Clients with Fixed Addresses
By default, the DHCP server does not update DNS when it allocates a fixed address to a client. You can configure the
DHCP server to update the A and PTR record of clients with a fixed address. When you enable this feature and the
DHCP server adds A and PTR records for a fixed address, the DHCP server never discards the records. When the lease
of the client terminates, you must delete the records manually.
You can define the fixed address settings at the grid level, member level, network and shared network level.
To send dynamic updates for fixed addresses at the grid level:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click DNS Updates.
3. Enter the following:
— Enable dynamic DNS updates: Select check box.
— Update fixed addresses: Select check box.
4. Click the Save icon.
5. Click the Restart Services icon.
To send dynamic updates for fixed addresses at the member level, follow the navigational path below and override
the grid-level settings:
•
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> DNS Updates.
To send dynamic updates for fixed addresses in a network or shared network, follow the navigational path below and
override the member-level settings:
•
From the DHCP and IPAM Perspective, select Networks -> + (for Networks or Shared Networks) -> network -> Edit ->
Network Properties -> DNS Updates.
Resending DNS Updates
You can enable the DHCP server to make repeated attempts to send DDNS updates to a DNS server. The DHCP server
first tries to update DNS for a particular lease before sending the DHCP ACK to the client requesting the lease. If the
update fails, the DHCP server still provides the lease and sends the DHCP ACK to the client. The DHCP server then
continues to send the updates until it is successful or the lease of the client expires. You can change the default retry
interval, which is five minutes.
You can enable this feature at the grid and member level only.
To enable the DHCP server to resend DNS updates at the grid level:
1. From the DHCP and IPAM Perspective, select DHCP Members -> grid -> Edit -> Grid DHCP Properties.
2. In the Grid DHCP Properties editor, click DNS Updates.
3. Enter the following:
— Enable dynamic DNS updates: Select check box.
— Retry updates when the DNS server becomes available: Select check box.
— Retry interval (minutes): You can optionally set the retry interval. The default is five minutes.
4. Click the Save icon.
5. Click the Restart Services icon.
To enable the DHCP server to resend DNS updates at the member level, follow the navigational path below and
override the grid-level settings:
•
412
From the DHCP and IPAM Perspective, select DHCP Members -> + (for grid) -> member -> Edit -> Member DHCP
Properties -> DNS Updates.
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS for DDNS
Configuring DNS for DDNS
For security reasons, a DNS server does not accept DDNS updates by default. You must specify the sources from which
you want to allow the DNS server to receive updates. For protection against spoofed IP addresses, you can use TSIG
(transaction signatures) to authenticate and verify updates (see Authenticating Updates with TSIG on page 416).
Enabling the DNS Server to Receive Updates
In addition to enabling the DHCP server to send DDNS updates (see Configuring DHCP for DDNS on page 405), you
must also enable the DNS server to receive them. You can enable the DNS server to receive updates at the grid,
member, and zone levels. Applying the Infoblox inheritance model, settings at the grid level apply to all zones on all
members, settings at the member level apply to all zones on that member, and settings at the zone level apply
exclusively to that zone.
Note: Whether you deploy Infoblox devices in a grid or independently, they send updates to UDP port 53. Grid
members do not send updates through a VPN tunnel. Grid members do, however, authenticate updates
between each other using TSIG (transaction signatures) based on an internal TSIG key.
Receiving Updates – Grid-Level Settings
You can configure the DNS server at the grid level to control the DHCP servers from which all grid members are allowed
to receive DDNS updates. Likewise, you can configure a DNS server receiving forwarded updates from another DNS
server. These are the DNS servers from which the grid members are allowed to receive forward updates (see
Forwarding Updates on page 415).
If you configure an independent (single) device or independent HA pair (an device or pair of devices not part of a grid),
do not use the member-level settings. Instead, configure updates at the grid level so they apply to all zones. If
necessary, override the grid-level settings on a per zone basis.
Note: To authenticate DDNS updates see Authenticating Updates with TSIG on page 416.
To allow or deny the DNS server to receive updates for all zones:
1. From the DNS perspective, click DNS Members -> grid -> Edit -> Grid DNS Properties.
2. In the Grid DNS Properties editor, click Updates.
3. Click the Override Grid Update Settings check box, and then in the Allow dynamic updates from section, click
Add.
4. Choose from the following information, and then click OK.
— IP Address: Select IP Address and enter the IP address from which you want to allow or deny updates. If this
is the IP address of a DHCP server on a single Infoblox device, enter the IP address of its LAN interface. If the
DHCP server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS
servers on the same Infoblox device, you must still enter the IP address of the interface that serves DHCP
(which, by the way, is the same interface that also serves DNS).
— Network and Subnet Mask: Select Network, enter the IP Address the network and choose a Subnet mask
from the drop-down list. This might be a subnet containing DHCP clients that—after receiving their address
leases—sends updates directly to the DNS server. (For details, see Client FQDN Option (Option 81) on page
409.)
— Any: Select this option to allow all updates.
— Permission: Select Allow to permit updates from the specified IP address or network. Select Deny to deny
updates from the specified IP address or network.
5. Click the Save icon.
6. Click the Restart Services icon.
NIOS 4.1r3
Infoblox Administrator Guide (Rev. A)
413
Configuring DDNS Updates from DHCP
Receiving Updates – Member-Level Settings
You can control the DHCP servers from which each grid member is allowed to receive DDNS updates.
To allow or deny the DNS server to receive updates at the member level:
1. From the DNS perspective, click DNS Members -> grid -> member -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Updates.
3. Click the Override Grid Update Settings check box, and then in the Allow dynamic updates from section, click
Add.
4. Choose from the following information, and then click OK.
— IP Address: Select IP Address and enter the IP address from which you want to allow or deny updates. If this
is the IP address of a DHCP server on a single Infoblox device, enter the IP address of its LAN interface. If the
DHCP server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS
servers on the same Infoblox device, you must still enter the IP address of the interface that serves DHCP
(which, by the way, is the same interface that also serves DNS).
— Network: Select Network, and enter the network IP Address the network. Then choose a Subnet mask from
the drop-down list. This might be a subnet containing DHCP clients that—after receiving their address
leases—sends updates directly to the DNS server. (For details, see Client FQDN Option (Option 81) on page
409.)
— Any: Select this option to allow all updates.
— Permission: Select Allow to permit updates from the specified IP address or network. Select Deny to deny
updates from the specified IP address or network.
5. Click the Save icon.
6. Click the Restart Services icon.
Receiving Updates – Zone-Level Settings
You can control the DHCP servers from which an individual zone is allowed to receive DDNS updates.
To allow or deny the DNS server to receive updates at the zone level:
1. From the DNS perspective, click Infoblox Views -> view -> + (for Forward Mapping Zones or Reverse Mapping
Zones) -> zone -> Edit -> Zone Properties.
2. In the Zone Properties editor, click Updates.
3. Click the Override member Update settings check box, and then in the Allow dynamic updates from section, click
Add.
4. Choose from the following information, and then click OK:
— IP Address: Select IP Address and enter the IP address from which you want to allow or deny updates. If this
is the IP address of a DHCP server on a single Infoblox device, enter the IP address of its LAN interface. If the
DHCP server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS
servers on the same Infoblox device, you must still enter the IP address of the interface that serves DHCP
(which, by the way, is the same interface that also serves DNS).
— Network and Subnet Mask: Select Network, enter the IP Address the network and choose a Subnet mask
from the drop-down list. This might be a subnet containing DHCP clients that—after receiving their address
leases—sends updates directly to the DNS server. (For details, see Client FQDN Option (Option 81) on page
409.)
— Any: Select this option to allow all updates.
— Permission: Select Allow to permit updates from the specified IP address or network. Select Deny to deny
updates from the specified IP address or network.
5. Click the Save icon.
6. Click the Restart Services icon.
414
Infoblox Administrator Guide (Rev. A)
NIOS 4.1r3
Configuring DNS for DDNS
Forwarding Updates
When a secondary DNS server receives DDNS updates—because it cannot update zone data itself—it must forward
the updates to the primary server. In such situations, you must enable the secondary server to receive updates from
the DHCP server, and then forward them to the primary DNS server.
To configure the secondary server to receive and forward updates for all zones:
1. From the DNS perspective, click DNS Members -> grid -> Edit -> Member DNS Properties.
2. In the Member DNS Properties editor, click Updates.
3. In the Allow dynamic updates from section, click Add.
4. Choose from the following information, and then click OK:
— IP Address: Select IP Address and enter the IP address from which you want to allow updates. If this is the IP
address of a DHCP server on a single Infoblox device, enter the IP address of its LAN interface. If the DHCP
server is running on an HA pair, enter its VIP (virtual IP) address. If you are running DHCP and DNS servers
on the same Infoblox device, you must still enter the IP address