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.
Sounds like your internet provider must blocking access to the root name servers. They obviously don't block access to their own resolvers, and they probably exempt a couple of other popular external resolvers like Google Public DNS, but might block all domain-port access otherwise.
Is this common? It depends. I think it's relatively common for such blocks to be present on university and corporate networks, but I would say it's not supposed to be a particularly common occurrence with regular residential providers. (Most providers do block outgoing smtp-port, however.)
Why would anyone block external nameservers? This has probably to do with various man-in-the-middle attacks that are possible if legitimate nameservers are substituted for compromised ones. To avoid any such attacks and to reduce user complaints, most providers usually redirect all domain-port requests to their own servers: when they do so, you can't run your own recursive server anymore or do dig +trace troubleshooting, but at least you wouldn't have to change your DNS settings otherwise.
Anyhow, indeed there is nothing wrong with your command itself: you're supposed to receive a reply as below, which would make it possible for you to make another request on the manual recursive path to the resolution of the given name.
# dig @b.root-servers.net www.ubuntu.com
; <<>> DiG 9.7.3 <<>> @b.root-servers.net www.ubuntu.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20828
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.ubuntu.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
;; ADDITIONAL SECTION:
a.gtld-servers.net. 172800 IN A 192.5.6.30
b.gtld-servers.net. 172800 IN A 192.33.14.30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
m.gtld-servers.net. 172800 IN A 192.55.83.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
;; Query time: 12 msec
;; SERVER: 192.228.79.201#53(192.228.79.201)
;; WHEN: Sat Jan 12 22:52:12 2013
;; MSG SIZE rcvd: 492
Best Answer
You can 'dig @b.root-servers.net . ns' to get updated root hints (which you should do periodically). Every root DNS server can return the root hints, so as long as all the root servers don't change at once you can always get updates re: those that have changed from those that have not.