DHCP "dig" Tool

BIND comes along with a "dig" tool that can aid problem diagnosis by querying DNS servers. The idea of an equivalent tool for DHCP - as part of the Kea suite of programs - has been raised. ISC Support (in the person of Brian Conry) has raised a set of questions/ideas for further discussion. Additional comments have been supplied by Cathy Almond.

The following questions have been used to guide things:

  1. What are some of the key features of "dig" that make it distinctive, and how do those translate into the DHCP world?
  2. How is "dig" used, and how do those usages translate from the DNS world into the DHCP world?
  3. What are some things unique to DHCP that require special consideration?

Features of "dig"

  • Directable ( @server ) - will default to using resolv.conf, but can be used to target individual servers.
    • In the DHCP world the default could be sending to the broadcast address but individual IPs can be targeted.
    • If a client configuration is found then that could be used to set the default values for a bunch of options.
  • Options to control retry/retransmit intervals and number of attempts.
    • Similar concepts exist in the DHCP world, although it seems reasonable here to report on timeouts and to possibly default to no retries.
    • Alternatively, ther default should be what most DHCP clients do or what the protocol advises on retries.
  • Options to control what output is produced at a fairly granular level.
    • The concept would be pretty much the same in the DHCP world, although thought needs to be given to what the logical chunks should be.
  • Options for different display methods for some specific data.
    • Probably also appropriate,
    • Nice to have, but not needed for the first implementation.
  • Options to control the header flags and EDNS option settings.
    • In the DHCP world this gets a lot more complex, as the messages from the client are more commonly richer in sent data. (This is a topic all by itself, specific to DHCP...)
  • IPv4 and IPv6 support.
    • In the DNS world this is a relatively trivial distinction but in the DHCP world the two protocols are significantly different.
    • It may be better to have two completely separate programs than to try to combine both protocols into one program. (This idea does have support.)
  • Does not directly affect the system it is run from.
    • This is the default for the DNS world, but in the DHCP world it is worth mentioning explicitly. has no built-in capability to change any files or interface settings. Has no built-in capability to invoke scripts with received data.
    • Just as in the DNS world querying a server can alter cache contents, in the DHCP world conversing with a server can alter the server's lease database. Care should be taken with the defaults to prevent accidental changes to the lease database that would be detrimental to the current system should it be a DHCP client (including changes to the DNS name associated with the lease).
      • We may need two potential operational options here.
        • If we're running this tool against a test server, then we may actually *want* the server to update its leases.
        • If we're running against a live server, then it becomes a much harder thing to prevent impact. We could add an option that the tool should attempt to release any leases it is granted at the end of the test run - but even being given leases temporarily is going to change the state of the server because we'll have leases that have the concept of having been granted before and which therefore would be lower preference for handing out to a new client and so on.
  • Tracks statistics for the data sent/received (sizes, counts of various sections, timing, etc).
    • The concept stays the same, but the details of what ought to be tracked will change.
  • Produced output is stable from version to version.
    • This makes the tool more useful for automation, this implies that extra care should go into crafting the first version to produce display modes that will hold up over the long haul.
  • Compiled program, leveraging existing code while also being relatively minimal in the way of runtime dependencies.
    • I don't think that our existing DHCP codebase is architected to be well suited for this kind of code reuse.
    • In implementation using a scripting language could be easier to write but likely at the expense of adding runtime requirements in the form of referenced external modules/libraries/etc that will complicate the install process.
  • Able to specify multiple queries and/or servers in a single command-line invocation, with some options being able to behave either globally or locally depending on where in the sequence they are used.
    • It is probably less likely in the DHCP world for it to be common to explicitly specify multiple servers to "query" with different options, all in one single invocation.
    • Given that "querying" a broadcast address is expected to be a normal behavior with multiple received responses something that already needs to be handled, it seems that much of the "hard work" for handling this is already required functionality.
      • We already have a bulk-test tool - we don't need to reinvent it here. But it would be good to be able to emulate a PXE client...

"dig" Use Cases

  • Manual probing of suspected issues.
    • In my mind this implies a richness of being able to quickly and easily tweak the command options to change the outbound packet to explore the behavior boundaries of whatever is being investigated.
    • This ought not be at the expense of being able to concisely refer to user-created persistent behavioral "bundles".
  • Automated data collection program embedded in other systems so they don't have to grow the ability to handle DNS natively
    • In the DHCP world this type of use /might/ be mostly limited to monitoring systems, but I'm sure I can think of other (ab)uses.
    • An extension of this is the potential for use in automated tests of DHCP client/server behavior.
  • While it's possible to manually validate DNSSEC signed responses with "dig", it's not recommended, but "delv" is designed for that.
    • As such, maybe a more useful tool would be a "delv" equivalent than a "dig" equivalent, due to the implication of a "session" in which multiple "queries" are made and answers received before a final result is determined.
    • Session mode v. packet mode? Session mode handles the entire dialogue necessary to obtain a lease (or not, if this fails). There are probably multiple 'session' types too - to emulate the different things that a client might 'do' in relation to a lease.
    • Or maybe we call it a "dig"-like tool while really building a "delv"-like tool, since "dig" is more well-known than "delv".

DHCP Specific Considerations

  • It is common enough for multiple DHCP servers to respond to a request, especially a broadcast request, that a DHCP "dig" tool MUST be prepared to handle this well.
    • Capable of not simply moving on or terminating with the first received response (but the order of received responses MUST be noted and preserved).
    • Capable of displaying equivalent information from all received responses in a manner that makes it easy to distinguish the groupings.
    • Whatever default is chosen, options MUST exist to choose handling of multiple responses.
  • In the DHCP world for troubleshooting you sometimes need to listen first rather than speak first.
  • Is there value in putting effort into making shortcut options for easy use with "derivative protocols" such as WPAD or BSDP?
    • This is a good idea - a shortcut to standardizes client settings.
    • How about having the tool have a concept of client 'profiles' that you can either set up manually (which options it requests, what it will/won't accept, whether it has a prior expired lease etc.). From there you can either ask it to operate in session or in packet mode. Session mode I suppose, also has retry timeouts? And then on top of this, we provide some quick-setup profiles, such as PXE client and various Apple clients (build these up, perhaps as folks contribute them to us or we see them during troubleshooting). In fact.. we could have an online repository of client profiles that we maintain ourselves with a few key useful ones to start with, but accept updates and suggestions and alternatives from our user base into?
  • Sometimes the in-packet representation of a value is just as significant as the logical value (e.g. a value encoded as a single instance of an option vs. being encoded as two concatenated instances of the option). Sometimes the order of options within the packet is significant. for maximum utility this kind of behavior needs to be easily controllable.
  • It is common for option data to use values outside of the normal printable ASCII range, so the tool needs to have mechanisms for unambiguous, yet easy to use, encoding of these values when necessary.
  • It is much more common to need to emulate a "broken" client behavior when troubleshooting DHCP than it is when troubleshooting DNS, enough so that the tool should be capable of producing a wide variety of known broken behaviors (e.g. incorrect option value encodings) while still making it easy for the user to produce proper packets by default.
    • Part of the 'profile' concept suggested earlier? Plus of course the ability to override non-broken profiles manually to emulate a new brokenness, not encountered before...
  • In DHCP there are a much larger set of factors that determine the answer you will receive from a given server, especially the client identifier (and MAC address), apparent subnet of origin of the request, and relay agent options.
  • In some cases it may be impossible to both emulate a specific request 100% /and/ directly observe the response (if any). it may be worthwhile to build the tool in such a way that it can be fed data from indirect sources (e.g. getting a feed from a tcpdump) in order to still perform the display and/or analysis portions of the tool's functionality.
  • It may be useful to build a programmable state machine into the tool (i.e. paralleling "delv" more than "dig"), but I think it will also be useful to have the tool be able to send a sequence of packets where the second and subsequent packet takes account of the responses to previous packets.
  • One alternative to building in a programmable state machine would be building the tool with the idea of being able to chain invocations together where the output of one invocation is fed into a second invocation as input (along with command-line options) to produce the "final" result.
    • How this should interact with cases where multiple responses are received requires additional thought.
    • There is a question on if we should build a mechanism whereby the second invocation can have conditional behavior based on either input data, random factors, etc.
      • This ties in with my 'session mode' versus 'packet mode' idea, although being able to step through session mode with choices could be a third way. Maybe. I'd put that on the 'nice to have but not essential' list too.
  • Note that some "queries" don't expect any output, e.g. RELEASE but the tool ought to be prepared to show them anyway.
  • It may be useful for some people to be able to supply an external "options definition file" that is used to allow complex vendor encapsulated options to be specified more easily, without us having to find and build-in support for all of them (or to select between ones that are incompatible but overlap in their identifiers).
Last modified 3 years ago Last modified on Oct 30, 2015, 12:21:23 PM