[DoS] DNS should be asynchronous, and cache

[geofft@MIT.EDU]

It is kind of poor that if I get sent a few hundred zephyrs from an IP address that doesn't reverse-resolve, barnowl locks up for 10 seconds or so per zephyr waiting for DNS and mDNS to determine that no, in fact, this address doesn't reverse-resolve to anything. This would be fixed by resolving addresses asynchronously (e.g., libares or libadns), and caching resolutions for at least a few minutes. Another solution would be to not look up IP addresses until they're needed to render the message or display the info popup.

Not sure if this is a barnowl bug or a libzephyr bug.

[kchen@MIT.EDU]

My first instinct is "That's what your caching nameserver is for."

But then, that's a different bug, given that BIND doesn't cache authoritative nameserver timeouts. (Nameservers do cache negative responses, though.)

There's a thread on bind-users about this issue at ​https://lists.isc.org/mailman/htdig/bind-users/2003-August/045152.html , but I can't actually find the original message. I also don't think anything happened with it.

[geofft@MIT.EDU]

That doesn't really help mDNS/Avahi, which is where most of my time spent timing out is. 192.168.1.12, the IP in question, resolves pretty quickly to NXDOMAIN on the public internet, and regardless it would have gotten cached.

[kcr@mit.edu]

Pretty clearly not libzephyr; it doesn't do any ip address lookup at all for incoming messages. (unless you're demanding an asynchronous reverse-resolver in the library...)

[andersk@mit.edu]

Yeah, definitely BarnOwl.

message.c:856:  hent = gethostbyaddr(&n->z_uid.zuid_addr, sizeof(n->z_uid.zuid_addr), AF_INET);

[andersk@mit.edu]

We should remember the IP, too, because reverse DNS could theoretically be spoofed to anything.