The DNX server configuration doesn't allow you to specify which checks should be ran through DNX workers... What it does allow you to do is specify the checks that should be handled locally and not be sent to the message queue for DNX workers to process.
# OPTIONAL: Local service check regular expression.
# This allows you to specify a regular expression which will be used to
# disqualify matching service checks as candidates for remote execution by
# DNX. Use this to make sure your local host checks stay local. There is no
# default value. If this parameter is not specified, then *ALL* Nagios checks
# will be handled by DNX.
#localCheckPattern = .*local.*
You could potentially use this if all your checks you want to run locally match a common regular expression that does not match the ones you want to be ran remotely. By default DNX server will schedule all checks to be ran by DNX so this could allow you to short circuit this.
That said I would hazard that DNX is not the right tool for what you're attempting and might be better suited setting up a distributed poller that handles all the checks for the remote network and passes the results back to this Nagios instance. DNX was more designed to distribute the actually polling load without having to run multiple Nagios instances as the DNX work only needs to have the plugins.
I have a Nagios deployment with a single central server and then Nagios polling instances in 3 data centers that report back to it. We're looking to use DNX in each data center from the polling instances to be able to add DNX workers to maintain the ability to execute all the checks within a certain period of time. As more checks are added we can add additional DNX workers and when the number of checks decline reduce the number of DNX workers. In this each polling instance only receives the configuration for those checks it is expected to actively check and the central server is setup to accept these results as passive checks.