Introduction

A traditional CNAME record (see also Stand-alone CNAME Records) defines a static, explicit alias in the DNS, with the oft-lamented technical limitation that a CNAME record cannot be placed at the apex of a zone (e.g. example.com).

Virtual Alias records are a non-standard but increasingly common DNS feature specifically designed to work around that limitation while still accomplishing a similar goal.

When we configure a virtual A Alias record in IPAM, our authoritative nameservers periodically query other nameservers to find the current A record(s) of the desired target name (e.g. abc123.cloudfront.net), and synthesize corresponding A record(s) for the alias name (e.g. example.com).  The result is a dynamic, transparent alias:

1. IPAM authoritative nameserver receives a query matching the virtual alias:  example.com. IN A?

2. IPAM authoritative nameserver sends a query for the target name: abc123.cloudfront.net. IN A?

3. IPAM authoritative nameserver receives this response for the target name:

   abc123.cloudfront.net. 60 IN A 198.51.100.17
   abc123.cloudfront.net. 60 IN A 198.51.100.18

4. IPAM authoritative nameserver returns this synthesized response for the virtual alias name:

   example.com. 60 IN A 198.51.100.17
   example.com. 60 IN A 198.51.100.18

The intermediate response is cached according to its TTL (time-to-live) value, so any further identical queries received by the same IPAM authoritative nameserver within the next 60s will skip steps 2 and 3, and return the same synthesized records with a lower remaining TTL.  Each individual IPAM authoritative nameserver maintains its own independent cache.

When the external nameserver’s response for the target name changes, IPAM’s response for the virtual alias name will also change (once the old response expires from cache).

If no A records are found for the target name, then IPAM will return zero A records for the virtual alias name.

This virtual A Alias record is only used to answer A record queries, but we could additionally and independently configure a virtual AAAA Alias record to answer AAAA record queries.

Key differences vs CNAME records

• A CNAME record affects query behavior for all record types, but each virtual Alias record applies to only one record type (e.g. only A records, or only AAAA records).  This enables virtual Alias records to coexist with records of other types, which is why they can be placed at a zone apex while a CNAME record cannot.

• Virtual Alias records are transparent (invisible) to clients, ultimately yielding the same query response as an equivalent set of static records:

  example.com.  IN A  198.51.100.17
  example.com.  IN A  198.51.100.18

  whereas CNAME records are explicitly returned and must be interpreted by the client:

  www.example.com.        IN CNAME  abc123.cloudfront.net.
  abc123.cloudfront.net.  IN A      198.51.100.17
  abc123.cloudfront.net.  IN A      198.51.100.18

  In this case only the CNAME record comes from our IPAM authoritative nameserver; the client’s recursive resolver combines that with A records from some other authoritative nameserver to form the sample response shown.

Limitations

Virtual Alias records cannot coexist in IPAM with other records of the same type (i.e. you cannot define both a virtual A Alias and a stand-alone A record for the same name).  There is no “fallback” functionality.

Virtual Alias records can be difficult to troubleshoot, since the external behavior of their target names might change unpredictably. 

Virtual Alias records cannot be used in DNSSEC signed zones.

At this time, we are offering virtual Alias records only for the zone apex of a second-level non-.edu domain (e.g. example.com), not for .edu subdomains.

(Note however that third-level .edu subdomains can be registered as a third-level CNAME record in the illinois.edu zone instead.)

Configuring virtual Alias records

Unfortunately we are not able to offer self-service configuration of virtual Alias records within IPAM at this time.  Changes should be made by request to hostmgr; be sure to include

• fully qualified domain name (FQDN) for the virtual alias
• which record type(s) should be aliased
• the target FQDN

Virtual Alias records vs DNS Traffic Control

Virtual Alias records and DNS Traffic Control both involve synthesized responses, but they are aimed at different use cases.

Consider using DNS Traffic Control if your service has a stable set of eligible target IP addresses, but some of them might be unhealthy from time to time.

Consider using a Virtual Alias record if your service has a stable target DNS name, but the set of IP addresses that name might resolve to is unpredictable (and it’s not possible to use a CNAME record).

This page contains some additional tips to help you use Grid Manager more efficiently. These tips will be most helpful to users who have already logged in once or twice and familiarized themselves with the basics.

Bookmarks

Grid Manager allows you to bookmark an object (zone, network, etc) and easily navigate back to it later. This is a good way to quickly access your most commonly used objects.

Adding bookmarks:

1. Open the object you wish to bookmark, so its name or identifier is displayed near the top of the main window (see Getting Started with IPAM).

2. Click the Bookmark (red swallowtail flag) icon to add a new bookmark for this object.

   screenshot

   

Using bookmarks:

1. Locate the Finder panel on the far left-hand side of the window; if it is currently collapsed, click the gray folder icon to expand it.
   

2. Expand the “Bookmarks” subpanel.

   screenshot

   

3. Click on the name of a bookmark to immediately navigate to the object.

You can also hover over a bookmark and click the Edit (blue pencil) icon to change its name, or the Delete (trash can) icon to delete it.

Smart Folders

The following smart folders can provide you with quick, convenient access to your own domains and networks (the ones for which you are listed in Contacts Database), but they require a one-time set up for each user account.

Setting up the My Domains smart folder

1. Navigate to Smart Folders > Global Smart Folders using the rows of tabs at the top of the screen.

2. Select the global smart folder named “My Domains”.

3. Click “Save Copy As” to create your own personal copy of this smart folder named “My Domains Copy” under Smart Folders > My Smart Folders.

   screenshot

   

4. Click the Edit (blue pencil) icon to edit “My Domains Copy”.

5. In the last filter criterion (CDB Permission equals NETID), replace “NETID” by your netid.

6. Click the “Save” button (not “Save Copy As”) to save your changes.

   screenshot

   

Setting up the My Networks smart folder

1. Navigate to Smart Folders > Global Smart Folders using the rows of tabs at the top of the screen.

2. Select the global smart folder named “My Networks”.

3. Click “Save Copy As” to create your own personal copy of this smart folder named “My Networks Copy” under Smart Folders > My Smart Folders.

4. Click the Edit (blue pencil) icon to edit “My Networks Copy”.
5. In the last filter criterion (CDB Permission equals NETID), replace “NETID” by your netid.

6. Click the “Save” button (not “Save Copy As”) to save your changes.

Using Smart Folders

1. Locate the Finder panel on the far left-hand side of the window; if it is currently collapsed, click the gray folder icon to expand it.
   

2. Expand the “Smart Folders” subpanel.

3. Click the (+) icon to the left of a smart folder (e.g. My Domains or My Networks) to expand its contents within the Finder panel.

4. For smart folders with grouped results (e.g. My Networks), click the (+) icon to the left of a result group (e.g. network name) to show the individual objects (e.g. network CIDRs).

   screenshot

   

5. Click on a domain name or a network CIDR to navigate directly to the pertinent Zone or Network object.

Using the Toolbar panel

The Toolbar panel on the right-hand side of the main window (just to the left of the Help panel) provides many convenient shortcuts for the experienced IPAM user.

For example, you can use the Toolbar’s Add menu to create DNS Records, DHCP Ranges, and even MAC Address Filter Items (MAC addresses within a MAC Address Filter) without having to first navigate to and open a particular Zone, Network, or MAC Filter object. If you know exactly what you want to add and where you want to put it, this can save a lot of clicks.

The Toolbar panel is available in most screens of the Grid Manager interface, but displays different choices depending on navigational context (e.g. which tabs are selected at the top of the window).  If it is currently collapsed, click the gray toolbox icon to expand it.

User Profile

To open the User Profile dialog box, click the drop-down control labeled with your username in the upper right-hand corner of the interface, and select “Profile”.

• You can customize Table Size to increase the number of rows you see at a time in Grid Manager tables (up to 256).

  Be aware that increasing the table size may result in slower UI performance; you may wish to experiment with different values to find a good balance. The default setting is 20.

• If you like, you may also enter an Email Address which Grid Manager will use e.g. to send you an email when one of your Scheduled Tasks completes.

Customizing Table Columns

Most tables in Grid Manager can be easily customized to display additional columns. For example, to add the Network Name column to the table that appears when browsing a list of Networks in DHCP View:

1. Mouse over any currently displayed column header (e.g. “Network”), and click the downward arrow button that appears on its right side.

2. Choose Columns > Edit Columns from the context menu.

   screenshot

   

3. Select the “Visible” checkbox for all desired columns (e.g. Network Name).
4. Click the “Apply” button.

Additional columns you may find useful:

• Network Name (when displaying a list of Networks in DHCP View or IPAM View)
• MAC Address (when displaying the contents of a Network or Range)
• Property Tag (when displaying the contents of a Network or MAC Address Filter)
• TTL (when displaying Records in a Zone)

Scheduled Tasks

If you don’t want your changes to take effect immediately, you can schedule them to occur later at a time of your choosing.  Important things to keep in mind:

• While a scheduled task is pending, no further changes can be made to the target object (by you or anyone else) until the task either completes or is cancelled.
• You can manage your own scheduled tasks, but you cannot manage scheduled tasks owned by another user.
• Always double check the Time Zone when choosing a time.

When adding a new object:

1. Use “Next” to keep advancing through the dialog screens until you reach a choice between “Now” and “Later” (or click “Schedule for Later” to skip ahead to this screen).
2. Choose “Later”, double-check the Time Zone, and enter the desired date and time.
3. When you click “Save & Close”, your change will be scheduled for the selected time.

When editing an existing object:

1. Click the blue calendar icon  at the top right-hand corner of the dialog window to show scheduling options.
2. Choose “Later”, double-check the Time Zone, and enter the desired date and time.
3. Optionally, you may collapse the scheduling options again (the calendar icon will turn green as a visual reminder).
4. When you click “Save & Close”, your change will be saved and scheduled for the time you selected.

When deleting an existing object:

1. Select the object in any table view (making sure no additional checkboxes are selected).
2. Click the drop-down arrow next to the Delete (trash can) icon above the table, and choose “Schedule Delete” from the context menu.
3. In the dialog box, choose “Delete Later”, double-check the Time Zone, enter the desired date and time, and click “Schedule Deletion”.

To manage your own scheduled tasks:

1. Navigate to Administration > Workflow > Task Manager using the rows of tabs at the top of the screen.
2. Your current scheduled tasks will be displayed with an Execution Status of “Pending”.
3. From here you can:
   • Mouse over the various fields for a pending task to show details of the change.
   • Select a pending task and “Execute Now”.
   • Select a pending task and Reschedule it for a different time.
   • Select a pending task and Delete it.

Extensible Attributes

Grid Manager supports the definition of custom fields called Extensible Attributes to store additional data which is not natively part of an object type. Technology Services has created a few Extensible Attributes that you may find useful:

• Property Tag: Can be used to store a University property tag value for inventoried items
• Comment+: The built-in comment field for Grid Manager objects is limited to 256 characters. If you want to store a longer comment, you can use this attribute to do so. 

You can set these attributes on the Extensible Attributes subscreen, while creating a new object or editing an existing one:

1. Click the Add (+) icon above the Extensible Attributes table to place a new row in the table.
2. Click the Attribute Name field in that row to choose the desired attribute.

3. Click the Value field in that row and type the desired value.

4. Some extensible attributes (e.g. “Comment+”) can have multiple values for the same object; use the “+” icon to the left of the attribute name to add another value.

   screenshot

   

If you have a request for a new Extensible Attribute that is not already defined, please contact hostmgr.  Keep in mind that Extensible Attribute definitions are global, so they should be potentially relevant (or at the very least, not confusing) to the entire IT Pro community.

Recycle Bin

If you delete an item by accident, you may be able to restore it using the Recycle Bin.

To view items in your Recycle Bin:

1. Locate the Finder panel on the far left-hand side of the window; if it is currently collapsed, click the gray folder icon to expand it.
   

2. Expand the “Recycle Bin” subpanel.

   screenshot

   

3. To restore a deleted item, hover over the item in your list and click the “Restore” (circular arrow) icon.

   Grid Manager does not display a confirmation dialog before restoring an object from the Recycle Bin!

   It also does not show you the newly restored object; if you want to examine it, you must navigate to it on your own.

   You can also click “Show All” to display a table showing slightly more information about each deleted item (including the Parent/Container where it will be found if you choose to restore it).

CSV Import and Export

Most tables in Grid Manager have an Export (up arrow) button which you can use to download the contents of the table in CSV format.  This can be very helpful if you want to sort or filter your data in a way that the Grid Manager interface doesn’t support.

You can also import records into Grid Manager from a .csv file.

See CSV Imports and Exports for details.

Introduction

IPAM, which stands for “IP Address Management”, is the integrated platform used by IT professionals to manage DNS and DHCP configuration for their networks and authoritative zones served by campus DNS and DHCP.

The user interface for IPAM is called Grid Manager.

How do I gain access to IPAM?

IT Professionals listed in Contacts Database with the “DNS Requests” permission for one or more network(s) and/or domain(s) may log in to IPAM Grid Manager and make changes to objects and records within those network(s) and domain(s).

The preferred way to obtain Contacts Database permissions for an existing network or domain is to contact the person responsible for that network or domain and ask them to grant you permissions.  If you cannot identify this person, feel free to contact hostmgr@illinois.edu for help.  Please note, however, that bulk permission change requests should be submitted to the Contacts Database team via consult@illinois.edu.

Updated permissions in Contacts Database are automatically read and imported into IPAM nightly.

Employees with a home campus other than Urbana must have an account in the Urbana UofI Active Directory in order to access IPAM.

About Contacts Database

Contacts are the people (or distribution lists) who should be informed when problems or questions arise regarding this domain:

• The Primary contact is the technical person who has operational (day-to-day) responsibility for the domain and will be contacted first regarding any questions or problems.
• The Backup contact will be contacted if the Primary contact is unavailable or does not respond.
• The Administrative contact is managerial rather than technical (typically a department head or business manager), representing the unit that owns the domain and pays for it.  They will be contacted for help re-establishing Primary and Backup contacts if the ones listed are out of date or not responding.
• You may list more than one Primary, Backup, or Administrative Contact.  You may also list contacts of type “Other” who are allowed to view the domain in Contacts Database but who will generally not be contacted with questions about the domain.
• Please list at least two Primary/Backup contacts (i.e. two Primary or one of each) and at least one Administrative contact.
• Please do NOT list the same person in multiple contact roles.

Permissions identify the Active Directory users (or groups) who are allowed to manage this domain:

• Change Contacts permission-holders can update the information in Contacts Database (which includes granting and revoking permissions), and are expected to keep this information up to date as people leave the University, change jobs, etc.
• DNS Requests permission-holders can perform self-service tasks in IPAM Grid Manager and request non-self-service changes from hostmgr@illinois.edu.  Note that requests for certain major irrevocable changes such as deactivating a domain or transferring it to another owner will be reconfirmed with a Primary contact (unless originated by a Primary contact).

Note that Contacts and Permissions are entirely separate concepts; it is common to grant Permissions to the same people who are Contacts, but not required.

Networks in CDB have DNS Requests permission too, but they can also have other types of permission which are used to manage access to other services.  See Contact Types in Contacts Database (CDB) for more information.

How do I log in?

Visit https://ipam.illinois.edu and click the “SSO Login” button (without entering anything in the text boxes) to authenticate using Shibboleth single sign-on.

• Multi-Factor Authentication (MFA) is required.
• See Linking a Secondary Account for Multi-Factor Authentication (MFA) if you perform IPAM tasks using a “secondary” AD account.
  • After configuring the alias in the NetID center, please additionally email TechServices-IAMU@illinois.edu to request that your secondary account be enabled for MFA in Azure.
• See also Identity Management, Troubleshooting and Solutions for using Urbana Single Sign-On Pages.

When the Shibboleth identity provider redirects you back to IPAM, you will be automatically logged in and should see a (fairly sparse) dashboard page.  If you instead end up back at the IPAM login screen, or if you see “Error: ‘Auto Create User’ option disabled, login denied”, this probably means you don’t currently have permissions to access IPAM (see How do I gain access to IPAM? above).

Technical notes:

• The “SSO Login” button requires your browser to briefly connect to an additional non-standard HTTPS port (8765/tcp) on the Grid Manager server, which may not work if you are behind a firewall that restricts outbound connectivity.

Alternative Login Method

If you experience difficulties using SSO Login, you can also authenticate to the web GUI using your full Active Directory userPrincipalName (typically yournetid@illinois.edu) and the regular “Login” button.

• Multi-Factor Authentication (MFA) is still required.  IPAM is not able to prompt you interactively for a second authentication factor, but you can append a passcode or factor name to your password as documented in https://guide.duo.com/append-mode.

  If you don’t append anything to your password, you should automatically receive a push notification (if you have a smartphone registered for Duo).

  If you have more than one smartphone registered for Duo, you might need to append e.g. “,push2” to use your second device.

  If your actual password happens to contain any commas (the delimiter character for append mode), we suggest always appending something (e.g. “,push”) so that your authentication can succeed on the first try without requiring an extra round-trip to AD on the back end.

• For UIC and UIS employees, be sure to enter the userPrincipalName of your Urbana UofI Active Directory account (typically yournetid@illinois.edu), not yournetid@uic.edu or yournetid@uis.edu

Your user profile for the Alternative Login Method will not reflect any customizations you have previously made while using SSO Login, nor vice versa.  See this known issue for details.

How do I log out?

Your Grid Manager session will automatically log out if it is idle for over 4 hours.  To log out manually, click the drop-down control labeled with your username in the upper right-hand corner of the interface, and select “Logout”.

In either case, logging out from IPAM does not end your Shibboleth identity provider session, which means you may still be able to click “SSO Login” and get right back in again.  You can prevent this by additionally visiting https://shibboleth.illinois.edu/idp/profile/Logout or by completely closing your web browser (see also Logging out of individual web applications with Shibboleth).

How soon will my changes take effect?

Many changes made in Grid Manager take effect instantly. Other changes (e.g. creating a DHCP Range) take effect only after a behind-the-scenes service restart, which will automatically occur within 5 minutes of making such a change.

Keep in mind that DNS records are routinely cached in accordance with their TTL (time-to-live) values.  Even though authoritative DNS record changes take effect instantly in IPAM, some clients may continue to see the old record data until it has expired from all caches.

If you don’t want your changes to take effect immediately, see the section on Scheduled Tasks in Advanced Tips and Tricks.

Getting started and navigating the interface

New users should start at Getting Started with IPAM. This page contains basic information about navigating the Grid Manager web interface once you have logged in.

DNS Configuration Tasks

Host Records explains how to create, edit, and delete Host records.

Stand-alone DNS Records explains how to create, edit, and delete all other types of DNS records.

DNS Traffic Control explains how to dynamically adjust DNS query responses based on server health checks.

DHCP Configuration Tasks

DHCP Ranges (Dynamic Pools) explains how to configure a pool of IP addresses that can be assigned interchangeably to any eligible DHCP client.

DHCP Fixed Addresses explains how to configure an individual IP address for use exclusively by a single DHCP client.

Managing DHCP Leases contains information about working with leases, which represent the allocation of a particular IP address to a particular client for a specified period of time.

Advanced Features

Advanced Tips and Tricks contains some additional tips to help you use Grid Manager more efficiently. These tips will be most helpful to users who have already logged in once or twice and have familiarized themselves with the basics. If you’re just getting started with Grid Manager, we recommend you skip this section for now and come back to it later on.

CSV Imports and Exports gives instructions on how to to perform “bulk” updates which create or modify many DNS and/or DHCP objects at once.

Using the IPAM API contains information about using Grid Manager’s application programming interfaces.

Customized Training

If you’d like free, customized training for your particular unit or department about how to manage DNS and DHCP using Grid Manager, contact hostmgr@illinois.edu.

Known Issues

Known Issues contains information about known issues with Grid Manager that may be relevant to campus network administrators.

Introduction

DNS Traffic Control (DTC) enables the IPAM authoritative nameservers to dynamically adjust their query responses for a particular domain name and record type, potentially returning a different address (A or AAAA) record each time depending on:

• health checks
• the source IP address of the query (note that this source IP usually belongs to the recursive DNS resolver rather than the end user)

  RFC7871 defines an EDNS0 Client Subnet option for recursive DNS resolvers to tell the authoritative nameserver about the originating client’s IP, but many recursive DNS resolvers do not implement this option (in part due to some privacy shortcomings).

DNS Traffic Control can be used to provide active/passive failover or active/active load distribution (not true load balancing, see below) between multiple target IP addresses for the same service.  The target IP addresses must be stable and known in advance.

The query response synthesized by DNS Traffic Control is returned instead of any normal DNS resource records which may be configured in IPAM for the queried domain name and type.  However, if DTC is not able to synthesize a response (e.g. because none of the eligible target IPs appear to be healthy), then the normal DNS resource record set is returned as a fallback.

Responses for other record types, such as TXT, are completely unaffected by DNS Traffic Control.

Example

The following illustration shows a DTC Load-Balanced Domain Name (LBDN) with two DTC Pools comprising a total of three DTC Servers.

Using multiple Pools makes it possible to implement fairly sophisticated logic, but this is not always necessary; many real-world use cases require only a single Pool (which can be either active/passive or active/active depending on the load balancing method chosen).

For introductory purposes this example shows only DTC Servers with IPv4 addresses, but we can add more DTC Servers with IPv6 addresses to get equivalent behavior for AAAA record queries as well (using the same Pools and LBDN).  Note that DNS Traffic Control automatically ignores DTC A records while synthesizing an AAAA response, and vice versa.

About TTLs

The scalability of DNS depends upon caching DNS records in accordance with their TTL (time-to-live) values.  The effectiveness of DNS Traffic Control as a failover mechanism depends upon using very short TTL values, typically 60 seconds or less, to limit the cache lifetime of its synthesized query responses.  It also depends on client applications issuing a new DNS query before reconnecting to your service, instead of just retrying against the same remembered IP address.  Note as a consequence that DNS Traffic Control is generally much more effective at mitigating protracted outages than brief intermittent outages.

About CNAME Records

When you create a Stand-alone CNAME Record pointing to a domain name handled by DNS Traffic Control, the alias name automatically benefits from the DTC behavior of the target name:

www.example.illinois.edu. 3600 IN CNAME example.illinois.edu.
example.illinois.edu.     60   IN A     18.217.84.3

No DTC configuration is required for the alias name www.example.illinois.edu, because that portion of the response is always the same; only the A record for example.illinois.edu is dynamically synthesized.

Note also that you do not need to set a short TTL on the CNAME record; the TTL values in the sample response shown above appropriately reflect our expectations that the CNAME record will be stable but the A record might change suddenly.

Glossary

DTC Server: represents a single target IP address which is capable of providing your service.  Note that DTC Server objects do not necessarily correspond 1:1 to your real servers, since

• a single DTC Server might target a Server Load Balancing (SLB) VIP which distributes incoming client requests among multiple real servers.
• a real server with both an IPv4 address and an IPv6 address will require two separate DTC Server objects, one per address (assuming you wish to use DNS Traffic Control for both A and AAAA responses).

Health Monitor: a test performed independently by each authoritative nameserver to determine whether a DTC Server is healthy

DTC Pool: a grouping of one or more DTC Servers with a load balancing method for choosing among them

Load-Balanced Domain Name (LBDN): a slightly misnamed object which maps one or more domain name patterns to a grouping of one or more DTC Pools, with a load balancing method for choosing among them

DTC LBDN Record: a manifestation of the LBDN which automatically appears within associated DNS Zones based on the LBDN’s domain name patterns.  Technically LBDN Records are separate objects from the LBDN, but you don’t normally need to worry about this distinction.

DTC A (or AAAA) Record: record data associated with a DTC Server which is used to synthesize DTC query responses.  Usually auto-populated based on the DTC Server’s IP.

Load Balancing Methods

Global Availability: always selects the first available target from an ordered list.  Use this for active/passive failover.

Ratio:Fixed: randomly selects an available target each time, optionally “weighted” to select certain targets more often than others.  Use this for active/active load distribution.

All Available (Pool only): instead of returning just one address record at a time, return the address records for all healthy Servers in the Pool (omitting any unhealthy ones).  This is an alternative active/active method which behaves more like traditional “round-robin DNS” (see also below), but cannot be used in DNSSEC signed zones because the number of distinct responses it might hypothetically produce is an exponential power set.

Topology: selects a target by evaluating the source IP address of each incoming query against a custom-configured set of rules (note that this source IP usually belongs to the recursive DNS resolver rather than the end user).  Use this e.g. if you need to provide a different answer to on-campus vs off-campus clients – or at least, to clients currently using an on-campus DNS resolver vs clients currently using an off-campus DNS resolver.

Round Robin: rotates through the available targets in ordered sequence, returning the “next” one for each successive query (1, 2, 3, 1, 2, 3, …).  This alternative active/active method involves maintaining state on the nameserver, which will expire if no matching queries are received for a while (empirically around 60s) causing the sequence to restart deterministically from 1.

Configuring DNS Traffic Control

Unfortunately we are not able to offer any self-service configuration of DTC objects within IPAM at this time.  We are hopeful that future software releases from the vendor will provide enough granular permissions that we can safely open up at least partial self-service, but for now, all DTC configuration changes should be made by request to hostmgr (except fallback records, which are not themselves DTC).

The following documentation will walk you through the design process step by step; we encourage you to read through all the steps, and then submit one request with as much detail as possible.

1. Configure Non-DTC Fallback Records

First, follow the usual self-service steps to create one or more normal Stand-alone A and/or AAAA Records for each fully-qualified domain name (FQDN) which will be handled by DNS Traffic Control.  Ultimately these static records will be unused most of the time, but they will be returned as a fallback whenever DNS Traffic Control is unable to synthesize a satisfactory query response targeting a known healthy DTC Server.  Broadly speaking, this can happen for two reasons:

1. Your servers are working, but something is wrong with DNS Traffic Control’s monitoring of your servers.  Consider in this scenario what static DNS response would generally give clients the best chance of successfully using your service.

   Note that it is common for DTC to return fallback records for up to 1 second after a behind-the-scenes service restart in which other DTC configuration changes are being applied (even if those changes have nothing to do with your LBDN).

2. None of your servers are working.  Consider in this scenario what static DNS response would be most useful to have already cached (by recursive DNS servers and/or client applications) at the moment when your servers begin working again.

Be sure to set a custom TTL (e.g. 60 seconds) on your fallback records so that they will not remain cached for too long once DTC is again able to synthesize a response.

The two most common choices for a fallback resource record set are:

• all of the eligible target IPs (essentially falling back to traditional “round-robin DNS“)

  Note: in this case, if you want the target IPs to have matching PTRs pointing back to the service FQDN (and assuming the target IPs do not have other PTRs already) you may opt to create a fallback Host record rather than stand-alone A/AAAA records.

• just one of the eligible target IPs (this might be preferable in some active/passive use cases where there is a significant penalty associated with actually using the secondary server)

Once your DTC LBDN is configured, Grid Manager will display the fallback records in strikethrough font as a visual reminder that they are masked by DTC:

2. Choose or Customize a Health Monitor

Next, decide how IPAM should determine the health of your DTC Servers (i.e. target IP addresses).  You can use one of the default pre-defined Health Monitors (icmp, http, or https), or email hostmgr to request a customized Health Monitor for your service.

Try to choose a health monitor that will not be blocked by firewall policy; by default, each authoritative nameserver performs its own health monitor testing independently of the others, and not all of them have University of Illinois System IP addresses.  If necessary we can work around this with consolidated health monitor settings (configured per Pool, details further down).

Please provide the following details when requesting a customized Health Monitor:

• Interval (seconds): how long to wait between the end of one health monitor cycle (either receiving a response or timing out) and sending the next request to the same DTC Server.  Default: 5s
• Timeout (seconds): how long to wait for a response before giving up.  Default: 15s
• Retry Up Count: number of consecutive successes for a currently unhealthy server to be marked healthy.  Default: 1
• Retry Down Count: number of consecutive failures for a currently healthy server to be marked unhealthy.  Default: 1
• protocol: choose one of
  • ICMP (ping): sends an ICMP or ICMPv6 echo request and expects an ICMP/ICMPv6 echo response.  No additional parameters.
  • HTTP: sends an HTTP request and optionally examines the response
    

    Parameter	Default	Remarks
    Port	80
    HTTP Request	GET /	May be a multi-line message including HTTP headers.  Recommended examples: GET / HTTP/1.0 GET / HTTP/1.1 Host: example.illinois.edu Connection: close Note that we do not generally recommend using the HTTP/0.9 request format (e.g. “GET /” without HTTP-Version) because HTTP/0.9 responses do not include a status code; see RFC 1945 for more information.
    Response Code Check	any response code is valid	may require a specific HTTP response status code (e.g. 200) or accept any
    Response Content Check	do not check	may search first 5KB of headers, body, or both using a POSIX Extended Regular Expression, and optionally perform additional validation on the matched content

  • HTTPS: sends an HTTPS request and optionally examines the response
    

    Parameter	Default	Remarks
    Port	443
    HTTP Request	GET /	(same as HTTP above)
    Enable Certificate Validation	false	boolean
    Enable SNI (Server Name Indication)	false	boolean (the SNI Hostname to use is configured in each DTC Server)
    Response Code Check	any response code is valid	(same as HTTP above)
    Response Content Check	do not check	(same as HTTP above)

  • TCP: opens a TCP connection to the specified port (successful when the handshake completes)
    

    Parameter	Default
    Port	no default (must be customized)

  • SIP, PDP, SNMP: talk to us if you feel that one of these might be appropriate for your service
• internal display name

  There is a single global namespace for all DTC Health Monitor objects, so try to choose something reasonable that begins with your department or group.

• Owned By Domain: the name(s) of one or more domain models (from Contacts Database) that should confer “ownership” rights to this object.  Self-service management of DTC objects is not possible at this time, but any user with permissions on any of the named models will be authorized to request changes through hostmgr.

You can examine Health Monitors under Data Management > DNS > Traffic Control, Toolbar: Manage Health Monitors

3. Configure DTC Servers

Please email hostmgr to request creation or modification of DTC Server objects.  Provide the following details for each:

• the IPv4 or IPv6 address which should be returned in response to A or AAAA queries when this DTC Server is selected as the answer
• (optional) any Health Monitors for this DTC Server which must target a different IP address than the one returned in response to queries
• (optional) an alternate SNI Hostname to be used for HTTPS Health Monitors
• internal display name

  This name has no functional effect on DNS behavior; it is used only for administrative purposes within Grid Manager.  There is a single global namespace for all DTC Server objects, so try to choose something reasonable that begins with your department or group.

• Owned By Domain: the name(s) of one or more domain models (from Contacts Database) that should confer “ownership” rights to this object.  Self-service management of DTC objects is not possible at this time, but any user with permissions on any of the named models will be authorized to request changes through hostmgr.

Once configured, you can examine DTC Server objects under Data Management > DNS > Traffic Control.

4. Configure DTC Pools

Please email hostmgr to request creation or modification of DTC Pool objects.  Provide the following details for each:

• which DTC Servers should be members of this Pool

  Note that it is possible to add the same DTC Server to multiple Pools.

• which Load Balancing method should be used to select a member (choices are described above under “Load Balancing Methods”)
• which Health Monitors should be applied to all members (targeting the main IP address configured for each DTC Server object)
• (optional) Consolidated Health Monitor settings: should off-campus nameservers use health status information obtained by the on-campus nameservers, instead of performing their own independent tests?

  This workaround makes it possible to use DNS Traffic Control for internal use cases where your entire service (and perforce also the health monitor target) is only reachable from on campus.

• internal display name

  This name has no functional effect on DNS behavior; it is used only for administrative purposes within Grid Manager.  There is a single global namespace for all DTC Server objects, so try to choose something reasonable that begins with your department or group.

• Owned By Domain: the name(s) of one or more domain models (from Contacts Database) that should confer “ownership” rights to this object.  Self-service management of DTC objects is not possible at this time, but any user with permissions on any of the named models will be authorized to request changes through hostmgr.

Once configured, you can examine DTC Pool objects under Data Management > DNS > Traffic Control.

5. Configure the LBDN

Please email hostmgr to request creation or modification of a DTC LBDN object for your service.  Provide the following details:

• one or more fully-qualified domain names (FQDNs) for which this LBDN object should synthesize responses, e.g. example.illinois.edu

  Best Practice

  Wherever possible, configure the LBDN to synthesize responses for a single primary FQDN, and implement any additional FQDNs using CNAME Records:

  www.example.illinois.edu. IN CNAME example.illinois.edu.
  myothersubdomain.illinois.edu. IN CNAME example.illinois.edu.

  Assign multiple FQDNs to the same LBDN only if they cannot be implemented as aliases (e.g. because they reside at the apex of a zone).

• the TTL value to return for synthesized responses, e.g. 60 seconds
• one or more DTC Pools to use

  Note that it is possible to add the same DTC Pool to multiple LBDN objects.

• which Load Balancing method should be used to select a Pool (if using more than one)
• internal display name

  This name has no functional effect on DNS behavior; it is used only for administrative purposes within Grid Manager.  There is a single global namespace for all DTC Server objects, so try to choose something reasonable that begins with your department or group.

• Owned By Domain: the name(s) of one or more domain models (from Contacts Database) that should confer “ownership” rights to this object.  Self-service management of DTC objects is not possible at this time, but any user with permissions on any of the named models will be authorized to request changes through hostmgr.

Once configured, you can examine LBDN objects under Data Management > DNS > Traffic Control.

You can also see their DTC LBDN Records which appear within the associated DNS Zones.

Monitoring DNS Traffic Control

You can see the health status of your DTC objects in Grid Manager by navigating to Data Management > DNS > Traffic Control.

Notice the “Last Status Update” time!  When your server goes down or comes back up, the underlying health check and actual DNS query responses will update quickly, but it may take a few minutes for the new status to be displayed in Grid Manager.

Select an object and click “Show Visualization” from the Toolbar panel on the right to see at a glance how this object relates to other DTC objects.

Comparisons with other technologies

The following sections discuss similarities, differences, and trade-offs between DNS Traffic Control and several other technologies which can be used for similar purposes.

DTC vs Traditional Round-Robin DNS

Publishing several static (non-DTC) A or AAAA records for the same domain name, a technique known as “round-robin DNS“, is a simple and time-honored way to achieve basic active/active load distribution and (sometimes) fault tolerance among multiple target IPs.

Most recursive DNS resolvers will randomly permute the order of the record set for each response, and most clients will initially try whichever IP appears first in the list they receive.  If that first IP doesn’t work, many clients are smart enough to automatically try another one, although this may involve a noticeable delay (outcomes vary widely depending on client implementation).  Without manual intervention, the unhealthy IP will continue to appear in round-robin DNS responses and thus continue to impact the end-user experience for some fraction of new clients until service is restored.

DNS Traffic Control attempts to improve upon this user experience by no longer returning an address record for the unhealthy IP, thereby (eventually, once the old response has expired from all caches) directing all new connections to a healthy IP.

Of course DTC also offers some additional options which can’t be implemented using traditional round-robin DNS, including active/passive and topology-sensitive behaviors.  But if simple active/active is what you want, it’s worth considering whether traditional round-robin DNS might be good enough (perhaps with a moderately low TTL to facilitate manual changes in response to a protracted outage) before deciding to implement DTC.

Note that despite having a similar name, the Round Robin DTC load balancing method has nothing to do with traditional round-robin DNS.

DTC vs network-layer Server Load Balancing (SLB)

In typical internet applications (e.g. web browsing), the client first uses DNS to resolve a target domain name into an IP address, then initiates a connection to the server at that IP address.

DNS Traffic Control alters the first part of this process by returning a different DNS record so that the client will connect to a different IP address.  Network-layer Server Load Balancing (SLB) alters the second part of the process by distributing client requests made to the same virtual server IP address (VIP) among different real servers behind the scenes.

Advantages of SLB:

• SLB offers better fault tolerance for individual real server failures, because failover is transparent to the client; existing clients need only reconnect to the same VIP, and new clients are not impacted at all.  By contrast, failover in DNS Traffic Control requires client cooperation and is subject to the potential pitfalls described in “TTL Caveat” above.
• Because SLB handles individual client connections, it can perform true load balancing (i.e. spreading the workload evenly among multiple active real servers).  The best DNS Traffic Control can do is to provide different answers to different recursive DNS resolvers and trust to the law of large numbers to distribute the overall workload, which may not be effective e.g. if many of the clients are using the same recursive DNS resolver, or if a few clients generate disproportionately large numbers of connections.

The primary limitation of SLB is that it is only available in certain locations and places additional constraints on the networks your real servers may belong to; see Server Load Balancing (SLB) for details.

The comparative advantage of DNS Traffic Control is that it can provide failover and load distribution between multiple geographically-distributed sites where sharing the same virtual IP address is not possible, thereby offering some protection (subject to “TTL Caveat” above) against a total failure of one of the sites.

DTC and SLB can also be used in tandem, with DTC directing clients to one of several SLB VIPs (which may in turn be located at different sites).  Note in this case that DTC will need a way to monitor the health of each SLB VIP.

DTC vs Global Server Load Balancing (GSLB)

GSLB is a term commonly used by many other vendors to describe the same functionality which we (and our vendor) call DNS Traffic Control.  We prefer the term DNS Traffic Control because it is more descriptive of the actual behavior and harder to confuse with SLB.

DTC vs Amazon Route 53 DNS Failover

Amazon Route 53 DNS Failover provides functionality very similar to DNS Traffic Control, but for DNS domains or subdomains which have been delegated to Route 53 (see AWS Authoritative DNS Guide for Illinois) instead of domains which are served by IPAM.

The main advantage of Route 53 DNS Failover is that it can take advantage of what AWS already knows about your target resources, e.g. automatically evaluating the health of alias records for Elastic Load Balancers.

DTC vs Virtual Alias records

See Virtual Alias records vs DNS Traffic Control.

Introduction

A Host record allows a single primary Name (fully-qualified domain name) to be associated with any of the following, managed collectively in Grid Manager as a single database object:

• one or more IPv4 addresses, which manifest as matching pairs of A and PTR records
• one or more IPv6 addresses, which manifest as matching pairs of AAAA and PTR records
• one or more Host Aliases, which manifest as CNAME records pointing to the primary name
• optional DHCP fixed address configuration for each IP address

Host records provide several advantages compared to managing an equivalent collection of Stand-alone DNS Records, the most important of which is that if you change one part of a Host record, the other parts will automatically update to stay in sync.

The trade-off is that you must be VERY careful when deleting a Host record!

myprefix-192-168-1-10.sandbox.illinois.edu. IN A 192.168.1.10
myprefix-192-168-1-11.sandbox.illinois.edu. IN A 192.168.1.11
...
10.1.168.192.in-addr.arpa. IN PTR myprefix-192-168-1-10.sandbox.illinois.edu.
11.1.168.192.in-addr.arpa. IN PTR myprefix-192-168-1-11.sandbox.illinois.edu.
...

This page contains information about configuring DHCP Ranges (Dynamic Pools) and DHCP options.

Introduction

A DHCP Range provides a pool of IP addresses that can be assigned interchangeably to any eligible DHCP client.

To configure an individual IP address for use exclusively by a single DHCP client, see DHCP Fixed Addresses or Adding DHCP to a Host Record.

The instructions below assume that you are working in DHCP View (see Getting Started with IPAM). Some DHCP configuration tasks can also be performed from IPAM View, but the exact sequence of steps may differ.

Creating A New IPv4 DHCP Range

To create a new DHCP Range:

1. Open the Network in which you want to add a new range (see Getting Started with IPAM).
2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Range”.
3. Click “Next” at the bottom of the dialog window.

4. Enter the desired Start (first) and End (last) IP addresses for the range.

   Make sure the range will be large enough to comply with Range Size Guidelines.

5. Optionally enter an internal display name and/or a comment.

6. Click “Next”.

7. Important: for “Served by”, choose “IPv4 DHCP Failover Association” and then click the “Select Association” button to automatically select “DHCP-A” which is the only failover association available.
   

   Do NOT select “Grid Member”.  Although a DHCP Range served by a single Grid Member may appear at first glance to function correctly, this configuration is unsupported because it does not properly utilize the redundancy provided by DHCP Failover.

8. Click “Save & Close” at the bottom of the dialog window.

Editing a Range

To edit an existing Range:

1. Navigate to the Range you want to edit (e.g. by opening its Network in DHCP View, see Getting Started with IPAM).
2. Select the checkbox for the Range object and click the Edit (notepad) icon above the table.  This opens the Edit dialog box.
3. Be sure to enable Advanced Mode for the dialog.
4. Make any desired changes (see subsections below).
5. Click “Save & Close”.

Setting DHCP Options

See DHCP Standards for the option values that will automatically apply unless you choose to override them.

To configure additional DHCP options:

1. Choose the “IPv4 DHCP Options” subscreen in the Edit dialog.
2. Scroll down to the “Custom DHCP Options” section at the bottom.
3. Add your new option in the last row:
   
   1. First field:
      • Choose a custom vendor option space if you wish to set a vendor-specific option which will be automatically encapsulated inside option 43 (see RFC 2132 Section 8.4) when replying to clients with the appropriate vendor class identifier (option 60).
      • Otherwise, choose “DHCP” to set a standard DHCP option.

   2. Second field: choose which option to set.  Option names are not standardized and may vary by implementation, so check the numeric option code (displayed in parentheses) to be sure you have the right one.

      If you need to set a custom DHCP option or vendor-specific option that is not yet defined in Grid Manager (i.e. does not appear in the drop-down lists), please contact hostmgr@illinois.edu.
   3. Third field: type the desired value.  The format of this value depends on the type defined for the option; see DHCP Option Data Types in the vendor documentation.
4. To add another option, click the + button.

To configure BOOTP/PXE settings:

1. Choose the “IPv4 BOOTP/PXE” subscreen in the Edit dialog (requires Advanced Mode).
   Click the Override button next to the setting you wish to override, and enter a new value.

   Hint: most PXE clients require values for Next Server and Boot File (which respectively populate the “siaddr” and “file” protocol fields defined by RFC 2131); please note that these settings are not the same thing as options 66 and 67. Clients utilizing the Boot Server (“sname” protocol field) setting are much less common in our experience.

If you need to enter a value that contains backslash characters, they should be doubled, e.g. foo\\bar instead of foo\bar.

Exclusion Ranges

To exclude certain addresses within a DHCP Range from being dynamically assigned to clients:

1. Choose the “Exclusion Ranges” subscreen in the Edit dialog (requires Advanced Mode).
2. To add a new exclusion range:
   1. Click the Add (+) icon above the table to create a new row.
   2. Click the empty “Start Address” field in the new table row that appears, and type the first address to be excluded.
   3. Click the “End Address” field and type the last address in the range to be excluded. To exclude only a single IP address, enter the same value for Start Address and End Address.
3. To remove an exclusion range:
   1. Select the checkbox to the left of the exclusion range to be deleted.
   2. Click the Delete (trash can) icon above the table.

Email Alerts

By default, the DHCP servers will automatically alert you by email whenever the current utilization of one of your DHCP Ranges exceeds 95% (and again when it drops back below 85%), with a maximum of one email alert per Range per day.  The recipient list for these emails is automatically populated (at the Network level) based on the network contacts listed in Contacts Database.

From: <no-reply@dhcp-a1.techservices.illinois.edu>
Subject: DHCP high threshold crossed:

Message: DHCP high threshold crossed:
  Member: 192.17.2.10
  Network: 172.21.195.0/28/default
  Range: 172.21.195.7/172.21.195.14///default
  High Trigger Mark: 95%
  High Reset Mark: 85%
  Current Usage: 100%
  Active Leases: 5
  Available Leases: 0
  Total Addresses: 5

Reporting: DHCP
Node: 192.17.2.10
Time: Mon Mar  7 15:01:49 2018


Network Name: 0210-citesdhcp-net

Utilization graphs: 
https://ipam-tools.techservices.illinois.edu/dhcpmon/view.fcgi?subnet=0210-citesdhcp-net

Help: https://netwiki-dev.techservices.illinois.edu/public/home/ipamdocs/using-ipam/dhcp-ranges-dynamic-pools/#Email_Alerts

You can customize the behavior of Email Alerts for this Range by choosing the “IPv4 DHCP Thresholds” subscreen in the Edit dialog (requires Advanced Mode).

• To adjust the threshold values (or disable notifications altogether) for this Range, click the Override button for the “DHCP Thresholds” area.

  • Be sure to check both “Enable DHCP Thresholds” and “Enable Email Warnings” if you do still want to receive notifications.  Do NOT check “Enable SNMP Warnings”.

    screenshot

    

  • Note that actual utilization must be strictly greater than the High Trigger Mark (or strictly less than the Low Trigger Mark) in order to trigger an alert.

    Hint: do NOT set High Trigger Mark to 100. If you only want notifications when the range is completely full, set High Trigger Mark to 99.

• To manually specify the list of email addresses which will receive threshold alert notifications for this Range (overriding the default recipient list for the Network), click the Override button for the “Email Addresses” area and populate the table as desired.
• To return either area to its default behavior, click the corresponding “Inherit” button.

Restricting Access to a Range

By default, IP addresses in a DHCP Range can be dynamically allocated to any client machine that is connected to the appropriate network. To restrict the use of a DHCP Range to specific clients:

1. Create a new MAC Address Filter and populate it with the desired MAC addresses (see MAC Address Filters), OR identify a suitable existing MAC Address Filter.

   You can use the same MAC Address Filter to restrict access to multiple DHCP Ranges.
2. Choose the “Filters” subscreen in the Edit dialog for the Range (requires Advanced Mode).
3. Click the Add (+) icon for the Class Filter List table, and select your MAC Address Filter.
   • By default the filter will be added with Action “Grant Lease”, meaning that clients matching this MAC Address Filter will be permitted (and clients not matching any MAC Address Filter listed in the Class Filter List will be denied).
   • If instead you want to deny leases to MACs matching this filter, click on “Grant Lease” and it will become a drop-down, then choose “Deny Lease” instead.

To return to the default behavior of permitting all clients, simply remove all Filters from the Class Filter List.

Advanced note: some use cases may involve adding an IPv4 Option Filter to the Class Filter List instead.  If a Class Filter List contains more than one type of filter (e.g. one or more MAC Address Filters AND one or more IPv4 Option Filters), then clients will be checked against the criteria for each filter type separately, and must satisfy them all in order to receive a lease.

Using Multiple DHCP Ranges

In most cases, you will want to create only one DHCP Range per network. If your network has a discontinuous collection of IP addresses which should be assigned interchangeably, it is better to create one large DHCP Range with Exclusions then to create several small DHCP Ranges which are otherwise identical, because Email Alerts apply individually to each Range.

It may make sense to create multiple DHCP Ranges if each one is intended to be used by a different (non-overlapping) set of clients.  If this is your goal, make sure that you associate at least one Filter with each Range.

Hint: if you configure one DHCP Range with action “Grant Lease” for a particular Filter, and a second DHCP Range with action “Deny Lease” for the same Filter, then any clients matching that Filter will be placed in the first range and all other clients will be placed in the second range.

Placing Fixed Addresses inside a DHCP Range

Introduction

A DHCP Fixed Address makes a particular IP address available for use exclusively by a single designated client.  For as long as the Fixed Address is configured, the designated client will always receive this IP address when connected to the appropriate network, and this IP address will never be allocated to any other client.  For DHCPv4, the designated client is identified by MAC address; for DHCPv6, it is identified by DUID (DHCP Unique Identifier – see also Limitations of DHCPv6 fixed address allocation).

From the client’s point of view, obtaining a lease from a Fixed Address is exactly the same as obtaining a lease from a DHCP Range.

On the server side, however, there is an important difference: fixed addresses are timeless, which is to say that the server’s behavior does not take into account whether the IP address in question was previously leased (either to the same client or to a different client).  This has two practical consequences for the careful network administrator wishing to avoid an operational conflict:

• Avoid configuring a Fixed Address for an IP which currently has an Active lease belonging to a different client (unless you are certain that the old client is no longer on the network).
• Avoid configuring a Fixed Address for an IP which very recently had a Fixed Address belonging to a different client (unless you are certain that the old client is no longer on the network).

Stand-alone Fixed Addresses vs DHCP-enabled Host records

The stand-alone DHCP Fixed Address objects described on the remainder of this page are DHCP-only objects with no DNS component.

You may alternatively wish to consider enabling DHCP for an IP address within a Host record, which is functionally equivalent to creating a stand-alone Fixed Address but makes it easy to keep the DNS and DHCP configuration for a client in sync (in case you later decide to migrate the client to a different IP address or retire it altogether).

Reservations

You may notice that it’s also possible in IPAM to create a “Reservation” object.  This is not the same thing as a Fixed Address, and will not accomplish what you probably intend; a “Reservation” in IPAM is a placeholder which does not permit any DHCP client to use the IP.

Users familiar with Microsoft DHCP should note that a Microsoft DHCP “Reservation” is analogous to a Fixed Address in IPAM, not a “Reservation”.

Creating a DHCP Fixed Address

To create a new stand-alone DHCP Fixed Address:

1. Using either DHCP View or IPAM View, Open the Network in which you want to add a fixed address (see Getting Started with IPAM).
2. Optionally (if using IPAM View), select the checkbox next to the desired IP address.
3. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Fixed Address”.
4. Click “Next” at the bottom of the dialog window.

5. Enter the desired IP address.

   If you have opened a Network in IPAM View and selected an IP address in the main workspace, it will automatically be pre-populated for you.

6. For IPv4 addresses: ensure that “MAC Address” is selected, and enter the MAC address of the client that will use this IP.
7. For IPv6 addresses: enter the DUID (DHCP Unique Identifier – see also Limitations of DHCPv6 fixed address allocation) of the client that will use this IP.

8. Optionally, you may use the Name field to specify an internal display name for this Fixed Address object.

   The Name field does not create a DNS hostname! If you want to manage DNS and DHCP for this client together, consider adding DHCP to a Host record instead of creating a stand-alone Fixed Address.

9. Click “Save & Close”.

Please note that your network must have autoconfiguration service appropriately enabled (see Requesting DHCP for Networks) in order for creating a DHCP Fixed Address to have any effect.

Editing a Fixed Address

To edit an existing stand-alone DHCP Fixed Address:

1. Navigate to the Fixed Address you want to edit (e.g. by opening its Network in DHCP View, or opening the individual IP address in IPAM View to display Related Objects – see Getting Started with IPAM).
2. Select the checkbox for the Fixed Address object, and click the Edit (notepad) icon above the table.
3. Make sure to enable Advanced Mode for the dialog.
4. Make any desired changes.
5. Click “Save & Close”.

Note that you can configure custom DHCP options that will apply only to this individual fixed address (but are otherwise similar to Setting DHCP Options for a Range).

Deleting a Fixed Address

To deleted an existing stand-alone DHCP Fixed Address:

1. Navigate to the Fixed Address you want to edit (e.g. by opening its Network in DHCP View, or opening the individual IP address in IPAM View to display Related Objects – see Getting Started with IPAM).
2. Select the checkbox for the Fixed Address object (making sure no other checkboxes are selected), and click the Delete (trash can) icon above the table.
3. If you’re sure, click “Yes” when the confirmation dialog appears.

Requesting Autoconfiguration Service

To enable autoconfiguration for your existing network, email net-trouble@illinois.edu with the following information:

• The name and IP CIDR of the network
• Which type of autoconfiguration you would like to enable (see below for details)
• If the network already has a DHCP server, let us know and provide details so that we can assist you in migrating your existing DHCP configuration into IPAM.
• Optionally, any other special configuration changes you require at this time (e.g. DHCP options set at the network level)

For new networks, work with your network designer to request autoconfiguration service as part of the network creation process.

Autoconfiguration Design Guide

There is no one-size-fits-all optimal approach to autoconfiguration; which type you choose, and which DHCP objects you configure in IPAM, will vary depending on how you want to use and administer your network.

The first step is to determine which of the following client behaviors you want to support:

• dynamic address allocation: each client automatically obtains an available IP address which is arbitrary and unpredictable. It doesn’t matter which client gets which IP, or if a particular client gets a different IP next time it comes back. This behavior is the easiest to configure, and requires very little administrative maintenance once set up.
• fixed address allocation: each client automatically obtains an IP address which has been administratively reserved for that client’s exclusive use.  This behavior requires more configuration work in IPAM (new clients must be added and old ones removed), but allows individual client IPs to be stable and predictable.
• manual client configuration: each client device is manually configured with the necessary network parameters, and does not use autoconfiguration at all. This is usually only necessary for devices which do not support autoconfiguration.

It is possible to mix and match, using different behaviors for different clients on the same network, but care must be taken to avoid conflicts!

Next, select the autoconfiguration type that best supports your desired behavior(s) – these are covered in detail in the following sections – and request that type of autoconfiguration service on your network.

Finally, if you’ve chosen DHCPv4 and/or IPv6 Stateful autoconfiguration, configure the desired DHCP objects in IPAM (see Using IPAM for detailed instructions):

• DHCP Ranges (Dynamic Pools) for dynamic address allocation

• DHCP-enabled Host Records and/or DHCP Fixed Addresses for fixed address allocation

  Notes for Microsoft DHCP users

  A Microsoft DHCP “Reservation” corresponds to a “Fixed Address” in IPAM. Avoid the temptation to create a “Reservation” in IPAM; that term refers to a different concept entirely and will not accomplish what you intend.

  Also, there is no need to place Fixed Addresses inside a DHCP Range (a “scope” in Microsoft terms); in fact, it’s best practice to avoid doing this. If you don’t want to use dynamic address allocation behavior on your network, you should not create a DHCP Range at all.

IPv4 Autoconfiguration Types

For IPv4, autoconfiguration is synonymous with DHCPv4, so the standard choices are simple; DHCPv4 is either enabled or disabled for any given network.

Notes:

• Several best practice recommendations are discussed in DHCP Ranges (Dynamic Pools).
• One strategy for preserving flexibility on a mixed-behavior net is to create a DHCP Range near the end of the net (i.e. highest-numbered IPs), and allocate Fixed Addresses, DHCP-enabled Hosts, and static IPs for manual configuration (if any) starting from the beginning of the net (lowest-numbered IPs).

IPv6 Autoconfiguration Types

For IPv6, there are multiple standard implementation choices for autoconfiguration, each supporting different behavior(s):

Notes:

• Where feasible, choose Stateless over Stateful autoconfiguration for your IPv6 networks.
  • Stateless is simpler than Stateful, and significantly easier on the DHCP servers.
  • If your network includes clients without DHCPv6 support, they will still be able to obtain an IPv6 address using Stateless autoconfiguration. Such clients will not learn the IPv6 DNS resolver address or other option values, but in many cases clients can function successfully without this information (e.g. by using IPv4 for DNS resolution, if available).
  • It is easy to migrate between Stateless and Stateful in the future if your requirements change.
• Most modern clients do support DHCPv6, as shown in https://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems.

Limitations of DHCPv6 fixed address allocation

The DHCPv4 protocol specification (RFC 2131) includes a “client hardware address” (chaddr) field which in practice contains the MAC address of the requesting client’s network interface.  This makes it easy for a DHCPv4 server to identify clients by MAC, and to assign fixed address allocations based on the client’s MAC.

The DHCPv6 protocol specification (RFC 3315) does not include a client hardware address field; instead, it defines the DHCP Unique Identifier (DUID) which is intended as an opaque, globally unique, and stable identifier for the whole client device (not just for one of its network interfaces).  Because the MAC address is not included in DHCPv6 messages, there is currently no way for a DHCPv6 server to assign fixed address allocations based on the client’s MAC address; instead, you must configure them based on the client’s DUID.

The challenge is that it can be difficult or impossible to learn the client’s DUID ahead of time.  While the MAC address is a property of the physical hardware, the DUID (for most general-purpose computers, at least) is a software property generated and stored on disk by the operating system.  Depending on your operating system, the DUID may not even exist until it is needed for the first time – and it will almost certainly change if you reinstall the operating system, dual-boot to a second operating system, etc.

Recommendations:

• Where possible, sidestep this issue entirely by using dynamic address allocation instead of fixed.
• If you do require fixed address allocation, make sure you understand the challenges discussed in this section and that you have a strategy for ascertaining client DUIDs.

Other Information

DHCP Standards details important guidelines and recommendations for using the DHCP service, as well as the default configuration parameters that will automatically apply to all networks unless you choose to override them.

Email Alerts explains the automated email notifications that may be sent to network administrators by the DHCP service.

This page contains information about creating and managing stand-alone DNS records.

Introduction

We use the term “stand-alone” to refer to any standard DNS record type (A, AAAA, CNAME, MX, SRV, TXT, etc) which does not have special proprietary behavior in Grid Manager.  There are many different types of stand-alone records, but the steps for managing them are very similar; we will discuss a few of the most common ones.

This page does not contain many screenshots, but some of the screenshots from the Host Records page may also be helpful here.

Stand-alone A Records

An address (A) record maps a fully-qualified domain name to a single IPv4 address:

www.example.com. IN A 198.51.100.17

Publishing multiple A records for the same name is legal and results in “round-robin DNS” behavior.

To create a stand-alone A record (with no matching PTR):

1. Open the DNS Zone in which you want to create the new record (see Getting Started with IPAM).

2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Record” and finally “A Record”.

3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired fully-qualified domain name (e.g. to create “myrecord.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

4. Type the leading portion of the Name (e.g. “myrecord“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.
   • You may leave this text box empty to create a record with the same name as the zone itself (e.g. “sandbox.illinois.edu”).
   • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.
   • You may type “*” or e.g. “*.bar” in the text box to create a record with a wildcard domain name (see RFC 4592).
5. Enter the target IP Address to which your A record should resolve.

6. Important: UNCHECK “Create associated PTR record”
   

   If you do want a matching PTR, you should Cancel this operation and create a Host Record instead.  Leaving this box checked creates a stand-alone A record and a separate stand-alone PTR record, which is undesirable because they can easily get out of sync in the future.
7. Click “Save & Close”.

AAAA records are exactly like A records, but they target IPv6 addresses instead of IPv4 addresses.

www.example.com. IN AAAA 2001:db8::17

When should I use stand-alone A records?

Use stand-alone A (and AAAA) records when you do not want a matching PTR record.

Common reasons for this include:

• the IP address already has a PTR record pointing to a different fully-qualified domain name

• the IP address belongs to a network whose reverse-mapping DNS is not managed in IPAM

Otherwise, it is preferable to use Host Records (which automatically manifest as matching pairs of A/AAAA and PTR records).

Note that it is best practice to avoid creating multiple PTR records for the same IP address.  While not technically an error, this may cause problems for software which expects reverse lookups to return a single name (an expectation subtly encouraged by language such as “primary” and “the host name” in https://tools.ietf.org/html/rfc1035#section-3.5).

When you want several fully-qualified domain names (FQDNs) to resolve to the same IP address, the recommended best practice is:

1. Create a Host Record for the FQDN that you consider to be primary.
2. Where possible, implement each additional FQDN as a Host Alias or stand-alone CNAME record pointing to the primary FQDN.
3. Create a stand-alone A record with no PTR for each additional FQDN which cannot be implemented as a CNAME record.

Example: Host Record for server17.mysubdomain.illinois.edu, stand-alone CNAME records (pointing to server17.mysubdomain.illinois.edu) for www.mysubdomain.illinois.edu and www.example.com, and stand-alone A records (pointing to the same IP as the Host Record) for mysubdomain.illinois.edu and example.com (which cannot be implemented as CNAME records since each resides at the apex of a zone).

MX Records

A mail exchanger (MX) record indicates the fully-qualified domain name of a mail server which can accept incoming email messages for a domain:

illinois.edu. IN MX 10 incoming-relays.illinois.edu.

Note that successful use of this record also entails resolving A (and/or AAAA) records for the mail server name.

To create an MX record:

1. Open the DNS Zone in which you want to create the new record (see Getting Started with IPAM).

2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Record” and finally “MX Record”.

3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired fully-qualified domain name (e.g. to create “myrecord.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

4. Type the leading portion of the Mail Destination (e.g. “myrecord“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.
   • You may leave this text box empty to create a record with the same name as the zone itself (e.g. “sandbox.illinois.edu”).
   • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.

5. In the “Mail Exchanger” field, enter the target fully-qualified domain name of the mail server to which the MX record should point.

   Per RFC 2181, the target of an MX record MUST NOT be an (explicit) alias (i.e. a Host Alias or CNAME record).  You are responsible for following this rule; it is not enforced automatically.

6. In the Preference field, enter a priority value for this record. (10 is selected by default)

7. Click “Save & Close”.

Stand-alone CNAME Records

A CNAME record defines a static, explicit alias in the DNS which affects query behavior for all record types:

www.illinois.edu. IN CNAME illinois.edu.

• Query: www.illinois.edu. IN A?
  Answer:

  www.illinois.edu. IN CNAME illinois.edu.
  illinois.edu.     IN A     192.17.172.3

• Query: www.illinois.edu. IN MX?
  Answer:

  www.illinois.edu. IN CNAME illinois.edu.
  illinois.edu.     IN MX    10 incoming-relays.illinois.edu.

Common points of confusion:

• This CNAME record helps your browser find the IP address of a web server for www.illinois.edu.  It does not tell your browser to redirect HTTP requests for http://www.illinois.edu/ to a different URL (only the web server itself can do that).

• A CNAME record cannot coexist with other records (e.g. no other records are permitted at www.illinois.edu)

  RFC 1034: “If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.”

  A few special record types for DNSSEC are exempted by later RFCs.

• A CNAME record cannot be placed at the apex of a zone (e.g. illinois.edu).

  This follows from the previous point, because the apex of a zone is required to have NS and SOA records.

• CNAME stands for “canonical name”, but that term (correctly applied) refers to the target name, not the alias name.  Best practice: use the terms “alias” and “target” to avoid confusion.

To create a stand-alone CNAME record:

1. Open the DNS Zone in which you want to create the new record (see Getting Started with IPAM).

2. Click the dropdown arrow next to the Add (+) icon above the table in the main workspace, then choose “Record” and finally “CNAME Record”.

3. If necessary, click the “Select Zone” button and choose the zone which will contain the desired fully-qualified domain name of the alias (e.g. to create “myalias.sandbox.illinois.edu”, you would select the zone “sandbox.illinois.edu”).

4. Type the leading portion of the Alias name (e.g. “myalias“) into the text box to the left of the selected zone name, so that both pieces together form the desired fully-qualified domain name.
   • You may type e.g. “foo.bar” in the text box to create a record named “foo.bar.sandbox.illinois.edu” even if there is no zone “bar.sandbox.illinois.edu”.
   • You may type “*” or e.g. “*.bar” in the text box to create a record with a wildcard domain name (see RFC 4592).

5. In the “Canonical Name” field, enter the target fully-qualified domain name to which the alias should point. 

   The target of a CNAME record should not be another (explicit) alias.  So-called “CNAME chains” are not technically an error, but create inefficient behavior and are discouraged as a bad practice (see RFC 1034 sections 3.6.2 and 5.2.2).

6. Click “Save & Close”.

When should I use stand-alone CNAME records?

A Host Alias is functionally equivalent to a stand-alone CNAME record pointing to the Host’s primary FQDN, but carries trade-offs with respect to ease of future maintenance.  Which option is preferable depends on the situation.

Advantages of using a Host Alias:

• A Host Alias will automatically be kept up to date if you change the Host’s primary Name, whereas a stand-alone CNAME record will be left “dangling” if the target Host record is renamed or deleted.

Advantages of using a stand-alone CNAME record:

• Modifying an existing stand-alone CNAME record to point to a different target is a simple one-step operation.  The corresponding process for a Host Alias requires editing the old Host (to remove the Host Alias) and then editing the new Host (to add the Host Alias).

• If a Host Alias resides in a different zone (from the primary Name of the Host) which is not managed by the same set of people, the disparity in permissions may impede self-service changes to the record (possibly requiring an escalation to hostmgr).  A stand-alone CNAME record presents no such problem; it is governed by the permissions on the zone containing the alias name, while any target record(s) are governed by the permissions of the zone containing the target fully-qualified domain name.

  Best practice: always use a stand-alone CNAME record in the case where the desired alias name and the canonical (target) name reside in different zones which may not be managed by the same set of people.

Stand-alone PTR Records

A PTR record is a pointer to another fully-qualified domain name.  PTR records (unlike CNAME records) are simple data; they do not alter DNS behavior, may coexist with other records, and have no inherent special meaning.  Their significance is understood by convention from where they are placed in the namespace (e.g. “17.100.51.198.in-addr.arpa” is understood to represent the IPv4 address 198.51.100.17).

PTR records are most commonly used for reverse-mapping DNS (i.e. mapping from an IP address to a fully-qualified domain name).  In general, you should never create a stand-alone PTR record in IPAM for this purpose; instead, create a Host Record which will automatically manifest as matching pairs of A (or AAAA) and PTR records.

If you do need to manage stand-alone PTR records for reverse-mapping DNS, just Open the Network in IPAM View (see Getting Started with IPAM); it is not necessary to navigate the arpa zones.

Stand-alone PTR records in forward-mapping DNS zones (used infrequently for other purposes such as DNS-SD) are not a special case, and can be managed just like the other types of stand-alone records described on this page.

Editing Stand-alone DNS Records

1. Navigate to the record you want to edit (see Getting Started with IPAM).
2. Select the checkbox for the record and click the Edit (notepad) icon above the table. This opens the Edit dialog box.
3. Make any desired changes.
4. Click “Save & Close”.

Deleting Stand-alone DNS Records

1. Navigate to the record you want to delete (see Getting Started with IPAM).
2. Select the checkbox for the record (making sure no other checkboxes are selected), and click the Delete (trash can) icon above the table.
3. If you’re sure, click “Yes” when the confirmation dialog appears.

This page contains information about configuring and using the Grid Manager API (application programming interface).

Introduction

IPAM Grid Manager includes a RESTful Web API (WAPI).  The purpose of this page is to help you get started using WAPI, and to make you aware of some important considerations that are specific to the University of Illinois IPAM service.  Please refer to the vendor documentation for a comprehensive API reference.

WAPI vendor documentation is available from https://ipam.illinois.edu/wapidoc/ or published in PDF format.

The current WAPI version is 2.12.3. New client programs should be written to use this version.

Previous WAPI versions still supported include: 1.4.2, 2.2.2, 2.7.3, 2.11.1

API Credentials

All IPAM users (see How do I gain access to IPAM?) also have access to the API.  You must authenticate using your full Active Directory userPrincipalName (typically yournetid@illinois.edu or serviceuser@ad.uillinois.edu, but other variations are also possible).

Using your own credentials is appropriate for direct, interactive use of the API (e.g. command-line utilities) where you can supply your Active Directory password and Multi-Factor Authentication (MFA) at run time.  IPAM is not able to prompt you interactively for a second authentication factor, but you can append a passcode or factor name to your password as documented in https://guide.duo.com/append-mode.

If your application requires unattended access to the IPAM API, you will need to create and authorize a non-person service user:

1. Create an Active Directory user object under your own organizational unit (OU) with a strong, randomly generated password.  We suggest choosing a name longer than 8 characters that begins with your unit or group followed by a dash (e.g. “techsvc-foo”) for easy identification and to avoid conflicting with potential NetIDs; see also Active Directory Naming Conventions.

2. Use Contacts Database to grant the desired permissions to your service user (either directly or via an AD group).

   Note that Contacts Database identifies users by their Active Directory sAMAccountName, a.k.a. “User logon name (Pre-Windows 2000)”, which is different from the userPrincipalName you will use to authenticate to the IPAM API.
3. Non-person service users must be individually exempted from MFA for IPAM by the IPAM service managers.  Contact hostmgr with the Active Directory userPrincipalName of your service user to request this.
4. Verify that you can successfully authenticate to the IPAM API with the Active Directory userPrincipalName of your service user.  If the actual password happens to contain any commas, we suggest appending “,push” as a placeholder so that authentication can succeed on the first try.

Rules of Use

1. Contrary to some of the vendor-provided examples,

   • Always use a hostname (i.e. “ipam.illinois.edu” for production) in the WAPI request URL. Do not use an IP address.

     It is possible that the IP address of the grid master may change from time to time, but the hostname ipam.illinois.edu will always resolve to the current grid master’s IP.

   • DO NOT disable SSL/TLS validation e.g. by passing the “-k” option to curl.
2. Use the “ibapauth” cookie (see Transport and Authentication) when making multiple API requests in the same program invocation, so that IPAM will not have to recheck your credentials (and MFA) for every single request.

3. Keep in mind that the grid master has finite computational resources, and be responsible and considerate in your usage. Do not (for example) write a script that performs lots of intensive API operations and schedule it to run automatically every few minutes.

   If you need to write a recurring API job that could significantly impact the grid master, please talk to us first. We don’t want to have to revoke access to the API.

4. Read and understand Backward Compatibility, and plan your deployments accordingly.

   Best practice: obtain the full WAPI base URL including version (e.g. https://ipam.illinois.edu/wapi/v2.12.3) from one or more configuration parameters rather than hardcoding it directly into your program.

Quick Start

Try a few simple GET requests from the command line using curl:

• Retrieve the singleton Grid object (a simple test to make sure your credentials work):

  curl --user yournetid@illinois.edu -X GET 'https://ipam.illinois.edu/wapi/v2.12.3/grid'

• Again, but also save the returned “ibapauth” cookie to a temporary cookie jar file, and use it to make a subsequent request without having to supply credentials:

  COOKIE_JAR=$(mktemp)
  
  curl --user yournetid@illinois.edu -c ${COOKIE_JAR:?} -X GET 'https://ipam.illinois.edu/wapi/v2.12.3/grid'
  
  curl -b ${COOKIE_JAR:?} -X GET 'https://ipam.illinois.edu/wapi/v2.12.3/grid'
  
  rm ${COOKIE_JAR:?}

  Be sure to consider the security implications of storing the cookie in a file!  Real applications should store it in memory instead (where it cannot be read by other processes).

• List all IPv4 Networks you have permission to see:

  curl --user yournetid@illinois.edu -X GET 'https://ipam.illinois.edu/wapi/v2.12.3/network'

• Again, but include Extensible Attributes (such as Network Name) in the returned data, and limit the result set to 2 objects:

  curl --user yournetid@illinois.edu -X GET \
  'https://ipam.illinois.edu/wapi/v2.12.3/network?_return_fields=network,extattrs&_max_results=2'

• Again, but use paging to iterate through the entire result set, retrieving 2 objects at a time.

  This is a simple example for demonstration purposes.  In practice, results paging is only necessary when your search might return too many objects to retrieve all at once (e.g. > 1000), and you should use a page size on the order of 500 or 1000.

  Initial request:

  curl --user yournetid@illinois.edu -X GET \
  'https://ipam.illinois.edu/wapi/v2.12.3/network?_return_fields=network,extattrs&_max_results=2&_paging=1&_return_as_object=1'

  Subsequent requests:

  curl --user yournetid@illinois.edu -X GET \
  'https://ipam.illinois.edu/wapi/v2.12.3/network?_page_id=789c5590...9c96b659'

  where each new request’s `_page_id` is the value of `next_page_id` returned by the previous request.

The documentation includes sample curl requests for PUT, POST, and DELETE (Examples accessing WAPI using Curl), but many of these examples require permissions that are not given to non-superusers in our environment (e.g. creating Networks).  Try adapting them to other object types, such as a stand-alone A record:

• Use POST to create a new stand-alone A record:

  curl --user yournetid@illinois.edu -X POST 'https://dev.ipam.illinois.edu/wapi/v2.12.3/record:a' \
  -H "Content-Type: application/json" \
  --data '{ "name": "mytestrecord.sandbox.illinois.edu", "ipv4addr": "192.168.0.5", "comment": "WAPI is fun" }'

• Search for the record we just created, and note its object reference (“_ref“) in the output:

  curl --user yournetid@illinois.edu -X GET 'https://dev.ipam.illinois.edu/wapi/v2.12.3/record:a?name=mytestrecord.sandbox.illinois.edu'

• Use PUT to modify the ipv4addr field of the existing record (using the object reference obtained above):

  curl --user yournetid@illinois.edu -X PUT 'https://dev.ipam.illinois.edu/wapi/v2.12.3/record:a/ZG5zLmJp...LjAuMC41' \
  -H "Content-Type: application/json" \
  --data '{ "ipv4addr": "192.168.0.6" }'

Resources

The Infoblox Community site has an article on Getting Started with the Infoblox Web API (WAPI) which you may find helpful, as well as a long list of REST examples (user-contributed) and other searchable content.

Perl

Here are a helper module and a working example script that you can use as a basis for your own programs.  Set environment variable IPAM_WAPI to the desired WAPI base URL (including version) before running the script.

• IPAMUserAgent.pm

  Helper module for IPAM WAPI scripts written in Perl.
  Requires LWP::UserAgent, optionally uses Config::Simple

• add_host_ip.pl

  Uses GET, POST, and PUT requests to either create a new Host record or add an IP to an existing Host record.
  Requires IPAMUserAgent.pm (above), JSON, and NetAddr::IP.

Python

Here are a helper module and a working example script that you can use as a basis for your own programs.  Set environment variable IPAM_WAPI to the desired WAPI base URL (including version) before running the script.

• ipam.py

  Helper module for IPAM WAPI scripts written in Python 3.
  Requires requests (http://docs.python-requests.org)

• add_host_ip.py

  Uses GET, POST, and PUT requests to either create a new Host record or add an IP to an existing Host record.
  Requires ipam.py (above)

Ansible

Ansible provides official Infoblox NIOS modules for many common use cases; see also Ansible’s Infoblox Guide.  Here are a helper playbook and some working example playbooks to get you started; note that these playbooks take extra care to avoid unexpectedly overwriting or deleting an existing record.

Requires infoblox-client (https://infoblox-client.readthedocs.org/)

• ipam-provider.yml

  Helper playbook for IPAM automation using Ansible 2.8+

• add-ipam-host.yml

• delete-ipam-host.yml
• add-ipam-a.yml
• delete-ipam-a.yml
• add-ipam-aaaa.yml
• delete-ipam-aaaa.yml
• add-ipam-cname.yml
• delete-ipam-cname.yml

Deprecated Perl-only API (PAPI)

You may encounter occasional references to a legacy Perl-only API (PAPI) which predated the modern RESTful Web API (WAPI), worked only with Perl, and required specific Infoblox perl modules to be installed on every client system and upgraded in lockstep with the appliance grid.  Use of PAPI at the University of Illinois has been strongly discouraged for many years, and it is now officially deprecated by the vendor as well.  Our only reason for mentioning it here is to forestall confusion in case you encounter the term and wonder what it means.