site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Prior to a socket connection being permitted, a set of rules is analyzed. A matching rule can specify what will happen to that connection. One criterion upon which a rule can match is that of a host name. Thus the need to have access to the address(es) associated with a given host name (and expeditiously, if possible). = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... Curtis Jones wrote: As Josh points out, you need to be able to deal with a hostname expanding to an arbitrary list of addresses. However, there's no reason for you to re-lookup these addresses for every packet. Process the list at load time (in your userland tool). Use this as an opportunity to convert the datastructure you keep in userland (which will be optimised for handling by your rule editing tool) into one that is more suitable for use by your kernel code (optimised for lookup operations). You can do all sorts of smart stuff if you like; compute a TTL for your in-kernel data based on the TTL information that comes back with your DNS queries. Fold entries together that have the same rules but different addresses, or different names but the same address. Divide your work so that things that you have to do on the socket path are in the kernel, and everything else is in userland. If you're not expecting to handle traffic in a performance-sensitive fashion, consider using a divert socket as previously suggested and handle things entirely in userspace; this will make your development/debugging process much easier. This email sent to site_archiver@lists.apple.com