exit-policy-reject-star relays should refuse dns?

Description

lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forced to do. "also permit reverse resolve for private
addresses, which could lead to leaks of names, in normal circumstances,
only available locally."

I can think of some cases where operators of middleman nodes might be surprised of DNS requests, for example in

places which do split-horizon DNS or if they have a premium subscription to a DNS blacklisting service (e.g. MAPS).

The second part is similar. I can think of places where reverse-resolving internal IP addresses would leak some
information (e.g. Cambridge) and I can't think of what this would break. However. it will not fix all the problems.
For example, in one site I am aware of they have internal-IP addresses which are not from RFC1918 (this was from the
time that IPv4 addresses were sufficiently abundant that internal networks were given globally-routable ones).

The patch will cause a problem for setups which send all reverse-DNS inquiries over Tor. Do the virtual machine
bundles of Tor do this? How will they fail if some reverse DNS fails. I would have thought it would be OK --
reverse DNS fails all the time.

The right solution is for Tor exit nodes to use a recursive resolver with no special access to information. Still,
that doesn't mean we shouldn't deal with the common case, which is what this patch addresses.

I did have an idea a while back of using this "feature" to identify which recursive resolver all Tor nodes are

using. If two nodes share the same one, then maybe they should be in the same family. I never implemented this,
and the patch will break this feature, but maybe that's OK.

non-exit relays can still be induced to do arbitrary DNS requests
if 'begin' relay cells contains DNS hostnames.

Some optimal solution for task: non-exit relays should answer with
'resolve_failed' for 'begin' or 'resolve' relay cells if it contained
DNS hostnames, and check of cells contained ip addresses with usual
conditions.

thats could be normal behaviour for well-behaved clients also, if
client have 'obsolete' descriptor for some relay which newest
descripor include non-exit policy.
(if connection was requested to ip address and 'REASON_EXITPOLICY'
was received then marking relay as non-exit, else don't)