Suffix searching is a client function, there is no explicit support for it in BIND or any nameserver implementation.
The only incredibly ugly thing you could do in DNS to support shortname resolution is set up a “fake” root zone containing the names you need to resolve. But, you really don’t want to go down that path. I consider
it a responsibility of DNS admins to push back on any unreasonable shortname-resolution requests from their customers/end-users. There are *very* few things left in today’s technology ecosystem that *require* shortname resolution. If it’s just
for _convenience_, then a management/political decision needs to be made, weighing the efficiency/scaling needs of the infrastructure, and the security/reliability risks of unexpected suffix matching, against the “convenience” arguments of those asking
for shortname resolution.
DHCP supplies a single domain suffix (option 15) which Windows clients can use for suffixing (but understand first the interactions between Connection-specific Suffix, Primary Domain Suffix and Suffix Search List).
That should be sufficient for any residual shortname-resolution needs. Note that you don’t *have* to give the same option 15 value to everything in the same DHCP scope. If you have a sufficiently-advanced DHCP server, you could tailor that value according
to, say, the “user class” set by the client and reported via DHCP (see RFC 3004). It might be possible to tailor it based on other parameters too (e.g. vendor class, RFC 3925), or combinations of parameters.