Tools like lsof
— in fact, all tools, don't treat multicast addresses specially for name resolution purposes. They try to resolve them like any other address. This is useful because these addresses actually do have valid names attached to them on the Internet:
; <<>> DiG 9.7.3 <<>> -x 224.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65271
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.224.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.224.in-addr.arpa. 28800 IN PTR all-systems.mcast.net.
And those that don't should receive quick negative answers.
; <<>> DiG 9.7.3 <<>> -x 235.255.255.255
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39854
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;255.255.255.235.in-addr.arpa. IN PTR
In either case, the answer should be fast, and there should not be timeouts.
Check your caching resolver nameserver to make sure it is able to resolve these addresses. If it is not, it may be firewalled from reaching the appropriate authoritative servers or something.
If you want, you can always short-circuit resolution of these names locally and guarantee fast answer with no need for Internet access by defining them as stub zones on your caching resolver pointing to empty zones on your authoritative nameserver. I doubt that there is very much software out there than relies on, for example, 224.0.0.1 mapping to all-systems.mcast.net. The zones you should serve are 224.in-addr.arpa through 239.in-addr.arpa as well as f.f.ip6.arpa.