0

Edit: Looks like ns lookup on some mcast IP doesn't not get a failed answer right away. Any suggestion?

I have two env, the new one we built is running BIND on linux. When running lsof or tcpdump, they stuck or become slow when they try to resolve addresses in the multicast IP range. Yes, I can live with no name resolution, but some guys can't.

In the old env built by some guys left the firm, running lsof has no problem. It doesn't try to resolve the mcast address.

Any clue where I should look? I checked named.conf and there's nothing diff.

Thanks W

Billy K
  • 99
  • 1
  • 3
  • 14

1 Answers1

1

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.

Celada
  • 6,060
  • 1
  • 20
  • 17
  • Do I actually need to add a reverse lookup zone for multicast range? – Billy K Jun 12 '13 at 01:50
  • As I said, you shouldn't have to, because there are public servers on the Internet that provide them already, but if you are experiencing difficulty or timeouts with those, or for speed, or if you are not connected to the Internet, then you can add them on your own servers if you want. – Celada Jun 12 '13 at 02:07