Haven't really seen anything like that before. Sounds like it could be useful to test the status of a DNS through batch processes though.I can think of a number of ways to have a shell script query the DSP, and take actions based on what might be going on.
Indeed, I would think this approach could provide an excellent means of status monitoring. Since it requires minimal overhead, it would be resistant to denial-of-service attacks.
Assuming that there's a 16-byte status report that changes at most a few times a second, and that the system keeps a 16-bit counter for how many times it's changed, one could query the status by sending (abcdefghijklmnopqrstabcdefghijklmnopqrstabcd). A lowercase "a" would get translated into the first digit of the counter, "b" into the second digit, "e" the first character of the status report, "f" the second, etc. The server would return three copies of the counter and two copies of the report. If the first two copies of the counter match, the report between them will be valid. Otherwise if the second two copies of the counter match, that report should be good.
This style of server, while it's extremely lightweight on the host side, is not terribly efficient in network traffic utilization. The client sends a packet to the host, and the host sends a packet with the same data to the client but does not acknowledge receipt of the data. The client then acks the data from the host, and the host bounces the ack back to the client.
A little messy, but the beauty of the system is that when a packet comes in the host simply examines it, munges it a little, sends it out, and forgets about it. If the packet gets dropped en route to the client, that will result in the client's not hearing a reply it was expecting. The client will then re-send its packet, and the host will re-send its reply.