Strange NAT problems with bigger queries

[Christian Holz @ ITC]

Hi List,

I have the following very strange problem:

We're setting up our main DNS servers (visible to the Internet;
authoritative for some domains) in a NATted environment. This means
that internally our servers have addresses such as 192.168.7.10,
externally they have routable addresses that have been assigned to
us. So far so good. NAT seemed to work fine, we could use the 
servers to look up outside addresses and from the outside people
can use our servers to look up single addresses. 

The problem comes into play when we try to do "larger" queries or
queries of a different type then "A"; Here is a sample output
from two nslookup sessions from the Internet (i.e. not from 
within our internal networks):

$ nslookup 
> server <ourservers IP>
> www.philosophers.de
> www.philosophers.de
Server:  dns2.integra-europe.de
Address:  213.68.144.129

Name:    www.philosophers.de
Address:  195.190.75.123
> set type=mx
> philosophers.de
Server:  dns2.integra-europe.de
Address:  213.68.144.129

At this point, the connection times out. The same query from inside
our NATtet environment works perfectly. 

Next, we tried to move the nameserver exactly as it is outside of
the NAT environment and give it a "real" IP-Address. Result: The
above query works. 

Now the question is: Why is a normal query for "www.philosophers.de"
working fine, while a question for the MX's for philosophers
does not get answered?

Ah, one more note: I turned on all the debugging options in 
named and I got the following entries while trying to do the
above (non-working) query:

XX+/208.178.101.2/philosophers.de/MX/IN
XX+/208.178.101.2/philosophers.de/MX/IN

I don't know what the "+" means after the "XX"... Other queries in 
the Logfile do not have this "+".

We're using the newest BIND 8 from isc.org and the NAT is done by a
Cabletron SSR 8600...

Any help would be _very_ appreciated since we're trying to go live
with this system and I am afraid that our registered domains cannot 
be queried by the registries right now with this problem...

Thanks

Christian