Differences

This shows you the differences between two versions of the page.

--- infoblox_uddi:dhcp [2026/02/10 10:56] – bstafford
+++ infoblox_uddi:dhcp [2026/03/25 00:09] (current) – [Split Scope] bstafford
@@ Line 29: / Line 29: @@
   * Port security / 802.1X / NAC
   * VLAN segmentation / access controls
+What Kea (not necessarily NIOS-X at this point in time) can do is to tighten control of “who gets served”
+While Kea can’t prevent another server from responding to clients, it can help you enforce that Kea only serves the traffic you intend:
+Kea supports DHCPv4 Option 82 (Relay Agent Information Option).
+In many enterprise designs, you combine:
+  * Relays that insert Option 82, and
+  * Kea client classes that match on Option 82 values,
+  * plus DROP for anything that doesn’t match
+That gives you “Kea only answers requests that come through my trusted relay/switch insertion,” which helps prevent unauthorized clients/segments from successfully using your Kea server.
+But it still does not stop a rogue DHCP server from answering those clients unless the switch blocks the rogue server’s offers.
+===== Starvation Attacks =====
+(For Kea, not NIOS-X yet)
+for DHCP starvation and DECLINE loops, Kea’s best built-in mitigations are:
+  * Client classification + DROP (hard-block bad patterns)
+  * Limits hook (libdhcp_limits.so) for rate limiting and lease limiting (contain flood impact)
+  * Backlog guardrail (parked-packet-limit) to avoid getting swamped
+Two key realities to keep in mind
+  * Rate limiting can’t stop pool exhaustion by many spoofed MACs by itself; it mainly protects server responsiveness and buys time.
+  * If you want the strongest starvation/rogue resilience at the edge, the network control is still DHCP snooping / port security (outside Kea).
+A “good default” policy for exposed subnets (guest / access edge)
+  * Per-subnet rate limit (limits hook) to cap how much traffic can consume CPU.
+  * Per-class rate limit for “unknown/untrusted” clients (especially if you can match on relay info / expected options).
+  * Set a reasonable parked-packet-limit so floods don’t turn into runaway backlog.
+===== DNS Suffix =====
+  * DHCP Option 15 – Domain Name
+    * Defines the client’s primary DNS domain name
+    * Historically used as the system’s default domain
+    * On many systems, it becomes:
+      * The device’s DNS suffix
+      * The first entry in the DNS search list (if no Option 119 is provided)
+      *
+  * DHCP Option 119 – Domain Search List
+    * Explicitly defines the DNS suffix search list
+    * Supports multiple domains
+    * If present, it typically overrides Option 15 for search list purposes
+===== Ping Before Offer =====
+  * Ping Before Offer - applies across entire tenant and set in Global DHCP Configuration.
+  * Can configure timeout (default = 100ms) and number of pings (default = 1)
+  * e.g. 1000ms + 3 Ping = Client will not get Offer for 3 seconds.
+  * This does not impact the overall LPS capability of the machine as different leases are handled in parallel.
+  * Ping check information is only available in the logs at DEBUG level (i.e. does not get sent up to Infoblox Portal). Only INFO and above gets sent to Infoblox Portal.
+  * If DHCP server gets a ping response, Infoblox Portal marks the IP as ABANDONED.
+===== Split Scope =====
+  * General use case for Split Scope is IPv6 and also Microsoft Migration.
+  * Infoblox manages DHCP on other vendors like Versa networks and which only support split scopes (or vendors like Microsoft which support split scope and can be managed by Universal DDI) - so Universal DDI must support Split Scopes.
+  * With IPv6 you can divide a /64 into two /65 subnets
+  * Split Scope has no lease sharing or heatbeat so it is simpler.
+  * DDNS Expirations can be an issue for Fixed Address objects in Split Ranges.
+  * Both servers in split scope will get any fixed address object in that range.
+  * You cannot adjust the split. It is always 50/50. Possibly off by 1. If Exclusion ranges block a large section of one half of the range, that server will only serve the bits it can. The system doesn't consider exclusion ranges when dividing the range into 50/50. Basically, don't put lots of exclusion ranges in.
+  * Don't convert split range to Active/Passive. (Until such a time as UDDI can copy leases to server)
+  * Resizing pool (e.g. 100-120) can also cause confusion because PartA doing 1-50 and PartB doing 51-100 is now PartA doing 1-60 and PartB doing 61 - 120
+  * When you REPLACE a box, the new one will get the old leases from portal.
+  * If client got lease from ServerA and then ServerA fails, when client comes back for IP. If client has "Authoritative turned on" ServerB would reply with NACK. Without "Authoritative" turned on; wait for lease expiration or T2. You gain simplicity but sacrifice T1 renewal by peer. Authoritative basically says the server knows all the leases that should be on the subnet. With Split Ranges... we don't; by definition we only know half.