ENTERPRISE NETWORK OPERATIONS · 7 OCTOBER 2026

Enterprise IP addressing, DHCP and DNS: a handover worksheet

A new LAN can pass a link test and still fail in daily operation because its address plan, DHCP scopes, relay settings and DNS ownership were never handed over as one system. This worksheet connects each service and VLAN to the addresses, options, name records, tests and responsible owners needed for a supportable network.

Visual reference photographs

Begin with services, not spare address blocks

List the services the network must carry before assigning subnets: corporate users, guest access, CCTV, access control, building management, voice, wireless management, network management, servers and internet edge services. For each service, record the VLAN, routed interface, gateway, address source, DNS path, security boundary and operational owner.

An address plan should show how a device reaches its gateway and essential services, not only which numbers are unused. Link it to the approved VLAN matrix, logical diagram, rack records and device inventory. Record IPv4 and IPv6 separately where both are in scope, and avoid implying that one automatically validates the other.

Separate infrastructure, reserved and dynamic use

Define which addresses are used by gateways, switches, access points, firewalls, servers, printers, cameras, controllers and other fixed devices. Then define the dynamic pool and any reservation range. Do not let a spreadsheet reservation and a live DHCP scope overlap silently.

For each fixed or reserved device, record its asset ID, hostname, MAC address where relevant, address, prefix, gateway, DNS settings, switch location and purpose. A reservation tied only to a MAC address becomes difficult to investigate when equipment is replaced. The asset and service context make the record useful.

Record the DHCP service as a complete scope

The IETF's RFC 2131 defines DHCP as a framework for supplying configuration information and allocating network addresses. RFC 2132 defines the DHCP options used to carry configuration details. For handover, capture the result expected on each client segment, not only a screenshot showing that a scope exists.

Record the pool start and end, exclusions, reservations, lease policy, gateway option, DNS server option, domain or search settings where used, time source or other approved options, server identity and configuration backup. State whether the scope is authoritative for that segment and who may change it.

Where clients and servers are on different subnets, include every relay point and target server. Cisco's current Catalyst 1200 IPv4 administration guide describes a DHCP relay agent as forwarding DHCP packets between clients and servers that are not on the same physical subnet. A working server does not prove that the relay path from every VLAN is correct.

Treat DNS as an operational dependency

RFC 1034 describes DNS name space, resource records, name servers and resolvers. RFC 8499 provides current DNS terminology. The handover record should distinguish the DNS servers supplied to clients, internal authoritative zones, recursive or forwarding resolvers, and public DNS records managed outside the site.

List the important internal names needed for operations, such as controllers, recorders, management platforms and servers. Record the zone owner, record type, target, time to live policy, update method and change authority. Include reverse records where the operational tools or applications require them. Do not assume that a successful public website lookup validates internal DNS.

Control names, addresses and device identity together

Use one device identifier across the asset register, DNS record, DHCP reservation, switch-port label, monitoring platform and drawing. When a camera, access point or server is replaced, the change record should show what identity stayed the same and what changed. This prevents old reservations, stale name records and duplicate static addresses from becoming hidden faults.

For high-availability services, record the actual design: active server, standby or failover partner, replicated configuration, virtual address if used, backup location, restore owner and recovery test. Do not label a service redundant merely because two servers appear in a diagram.

Commission from every client segment

Use an approved test client on each user and device VLAN. Capture the address, prefix, gateway, DHCP server, lease time and DNS servers received. Then verify the permitted business path for that segment. A client that obtains an address but cannot resolve its required names or reach its allowed service has not passed.

1. Release and renew the client lease on each tested segment.
2. Confirm the assigned address is inside the intended pool and outside exclusions.
3. Confirm the gateway, DNS and other required options match the approved scope.
4. Verify that the relay path reaches the intended DHCP server.
5. Test resolution of an approved internal name and an approved external name.
6. Verify the answer comes through the intended resolver path.
7. Test a known nonexistent name and confirm the result is handled correctly.
8. Check one reservation or fixed device without disturbing a live service.
9. Look for duplicate-address warnings, stale leases and unintended scopes.
10. Repeat the client test after any correction to a scope, relay or DNS record.

Plan controlled failure tests

If DHCP or DNS resilience is part of the contracted design, agree a maintenance window and a safe test before handover. Record the starting state, action, expected client behaviour, observed interruption, recovery time and rollback decision. Protect live building systems from uncontrolled experiments.

Useful checks may include taking one approved resolver out of service, renewing a client while a DHCP partner is unavailable, restoring a saved configuration in a lab or staged environment, and confirming monitoring alerts. The accepted test must match the deployed design and vendor guidance.

Handover evidence package

1. Approved service, VLAN and subnet matrix.
2. DHCP scope export with exclusions, reservations, options and lease policy.
3. DHCP relay map showing client VLANs, relay interfaces and server targets.
4. DNS zone and resolver ownership record, including public and internal boundaries.
5. Fixed-address and reservation register tied to asset IDs.
6. Configuration backups with device or service version and capture date.
7. Client test results from every required segment.
8. Failure-test evidence where resilience is in scope.
9. Known exceptions with owner, risk, target date and closure evidence.
10. Change procedure and named operational contacts.

Decision checklist

1. Does every subnet have a named service and owner?
2. Are gateways, dynamic pools, exclusions and fixed ranges unambiguous?
3. Are reservations tied to assets, not only MAC addresses?
4. Do DHCP options match the approved design for each VLAN?
5. Are all relay interfaces and server targets recorded?
6. Are internal DNS, recursive DNS and public DNS ownership separated?
7. Are critical names, records and update methods documented?
8. Can a test client renew and resolve names from every required segment?
9. Are backups dated, versioned and restorable by a named owner?
10. Are resilience claims supported by a controlled test?
11. Are monitoring, capacity thresholds and exception owners defined?
12. Does the final record match the live configuration?

Engineering worksheet

Keep one scope row for each client segment and one device row for each fixed or reserved endpoint. Attach exported configuration and test evidence instead of transcribing every setting manually. Use a clear result such as pass, conditional pass, fail or not applicable. Any conditional result should have a risk statement, owner and closure date.

Related reading: use the enterprise VLAN and switch handover worksheet to define segmentation, the switch redundancy worksheet to test controlled failures, and the rack labeling and documentation worksheet to align physical and logical records. See enterprise networking services for design, installation, testing and handover scope.