BIND not reading /etc/hosts on MacOSX Lion

In your dig output, the name servers for that domain appear to be ns.agasoft.co.il and ns3.agasoft.co.il.

However, as of right now, their name servers are webserver1.agasoft.co.il and webserver2.agasoft.co.il.

It appears they changed their name servers.

In addition, mailhost.agasoft.co.il does not exist, according to those servers. Instead, their mail server (as identified by their MX record) is mailserver1.agasoft.co.il. This host does exist, and both name servers return the same address for it: 82.80.246.156.

Also note that in your dig output above, you requested a trace for mailhost.agasoft.co.il but the output shows for mailserver1.agasoft.co.il. Was that a typo in your question?

Summary: the agasoft.co.il domain appears to have recently changed their name servers and possibly also their mail server. If you are trying to find out why mail couldn’t be delivered to them, that’s why. The old name servers (according to your dig output) have a TTL of 1 day, so the problem should clear up in a day or so.

Yes, Bind does this with views. Some in detailed examples are here and here.

It would look something like this in named.conf:

view "trusted" {
 match-clients { 192.168.23.0/24; }; // our network
  recursion yes;
  zone "example.com" {
   type master;
   // private zone file including local hosts
   file "internal/master.example.com";
  };
  // add required zones
 };
view "badguys" {
 match-clients {"any"; }; // all others hosts
 // recursion not supported
 recursion no;
 };
 zone "example.com" {
   type master;
   // public only hosts
   file "external/master.example.com";
  };
  // add required zones
 };

One trick I typically do to make administration easier is to simply have the internal file $INCLUDE the external file -- just don't forget about SOAs.

As a final word of caution, don't pretend this is anything more than Rubber Chicken Security (not that there's anything wrong with that).