> > It occurs to me that it would be a whole lot simpler to do the PTR
> > queries using unicast. The LLMNR resolver could use a TTL=1 when
> > sending the query. This way it would either get an immediate
> > no-route response from the local TCPIP stack, a direct response from
> > the holder of the address, or an ICMP time exceeded reply from the
> > default router. Either way, the resolver wouldn't have to do any
> > checking on the address. This approach has several benefits:
> > 1) Immediate error response if there is no route for the address
> > 2) Error response from default router if the address is off-link
> > 3) LLMNR resolver does not need to do any checking on the address
> > 4) Unicast is easier on the network
> I think that is a good idea. This is what the Node Information Query
> reverse lookup does.
> When asked to reverse lookup a multicast address what then? Offhand I
> can't think of a good reason not to just multicast the PTR query to
> the address you are looking up.
limit the propagation, I wouldn't want to send a PTR query to the subnet
The first question is, is it useful to support PTR queries for multicast
and broadcast addresses at all? If yes, we have to define the behaviour
both ways. Does a responder also include its subscribed multicast
addresses to A and AAAA responses? Multicast addresses would also have
to be treated as non-UNIQUE RRs to avoid problems with conflict
I would say just return an error to PTR queries for multicast/broadcast
the word 'unsubscribe' in a single line as the message text body.