Thank you very much for sharing this information!
Today I stepped in a similar situtation where I had a batch task that uses a file which I haven't set as an additional file in my distribution package. the "dns... " error message put me in the wrong direction of investigation put your post helped me to get back on the right track.
It's an unfortunate side-effect of us trying to be helpful.
When we get an error back, it's usually in the format of "some_number : some_number" - for example "3510:3" - where 3510 indicates that this particular code comes from OSD, and error 3 is the ACTUAL error code.
Now, rather than just throwing a status of "3510:3" as a result for your task status, we try to give meaningful error messages for the more common error codes.
So far so good.
Now, if we run into an error doing anything, we try to get SOME error from anywhere that will give us. These things are not overly standardized - so "9876:xxx" is not ALWAYS going to be "REG.EXE" or whatever is being run at the time.
What happened in this case, is that we get an error-code + error-source which we have an error-message prepared for ... except that the (unfortunately matching) error-code has nothing to do with the component it's supposed to be.
This is pretty much an educational issue, and I can't yet think of a better way ... the Console just faces "an error code" - it doesn't know whether this error code is coming from REG.EXE or a more genuine component. So it processes the numerical error and tries to match it to a string if it can - since it did (unfortunately so), it tried to be helpful and throw up the error-string we have, as opposed to just numerical values.
Hope this makes more sense now in regards to behaviour.
LANDesk EMEA Technical Lead