Internet Sharing & Firewall -- A Small Puzzle

I just solved a vexing little problem with enabling internet sharing via airport between two macs running 10.6.8. The trouble is that I'd like to understand what's going on, and my efforts to retrace the steps which led to the solution have puzzled me further. The puzzle involves the "named" and "internet sharing" applications (the term "application" I think means "process" in this context), as they are listed in the list of incoming connections on the Firewall's advanced screen. I apologize for the lengthy narration which precedes the question, but I don't understand the issue well enough to be more succinct.

My imac gets internet service via ethenet from a cable modem. I decided to use built-in Airport to share the internet with a Macbook. When I clicked on the check-box to enable internet sharing, the prompts led me easily through the steps for creating an airport network. It was equally easy to turn on airport on the Macbook and to join the new airport netowrk -- but no file sharing.

After trying a few pointless things, I recalled that, at about the time I had turned internet sharing on, I had gotten two of those irritating messages asking if I want to allow or deny an application the ability to accept incoming connections. My reflex is to click "deny," usually with no noticeable harm. In this case I had clicked "allow" for"Internet Sharing," but clicked "deny" for something called "named", which seemed like a suspiciously inscrutable moniker. [I think now that it's the short name for a standard unix process, a DNS server, but I don't know enough about networking for that to mean much to me.]

Sure enough, "named" was one of the listed applications in the Firewall's advanced window, and was set to "deny". I clicked "allow", and all of a sudden internet sharing worked like a charm.

Curious to know what "named" was, I toggled it back to"deny" -- but internet sharing continued to work. For good measure I deleted it from the firewall's list of applications with the minus key, but internet sharing continued to work. (Yes, I should have logged out, or rebooted. I did some logging out and rebooting in the course of this process, but didn't take notes and so don't remember exactly when.)

I was finally able to disable internet sharing by (if I recall) , disabling all sharing services and rebooting., Fine, I thought, now I'll re-enable named, but of course I had deleted it from the firewall list of applications, and since it's not an "Application" in the simple Mac sense, I couldn't use the plus key to add it to the list. (I even tried searching visible and invisible files for "named", but no dice.)

And although I tried various permutations of enabling and disenabling internet sharing, I couldn't coax the operating system to flash the message about allowing "named" to accept incoming connections. Finally I succeed (I think by setting the Firewall to block all incoming connections,rebooting, and then re-enabling internet sharing.) I gratefully clicked "allow", and internet sharing started working again like a champ.

But here's the puzzle (thanks for staying with me!): neither named or Internet Sharing is listed in the Firewall's list of applications. I know that they are running, because they're listed in the Activity Monitor. But I don't understand why I formerly had control over them via the Firewall application, and now I don't.

"What's the problem, it works, doesn't it" (I hear you cry.) Well yeah, but by the time I have to do this again, I won't really remember what I know now, and it's bothersome that a high-level function that should be available without mucking with Terminal doesn't work in a straightforward manner. In other words, if Internet Sharing doesn't work without allowing "named" to accept incoming connections, it should manage the process behind the scenes, or else make it clear what needs to be done and give an easy interface to do it.

I guess I haven't framed a very clear question, apart from "what's going on here," but I'd be very grateful if someone could shed some light on this.

Cheers,

Tom