Problem handling thin clients' "subnet" within GOsa (was: Re: DNS for the thin client network should be handlet by Gosa)

["Andreas B. Mundt" <andi.mundt@web.de>]

Hi all,

unfortunatelly it looks like we have a little problem with the
DNS/GOsa setup. 

In skolelinux, we have at least two networks: The 10.0.2.-net called
main-net and the 192.168.-nets. However, both networks are part of the
"intern" domain. 

Now we need a zone to handle these networks. I prepared a
"intern"-zone, the corresponding reverse zone is 2.0.10.in-addr.arpa.  
This is a standard setup and it can handle all requests asked
concerning machines in the 10.0.2.-net.

What happens if I ask for the ltspserver's thin-client interface
with associated name ltspserver? Well, I can add an A-record in the
intern-zone that translates to 192.168.0.254. So far so good.

However, what happens if I ask for the reverse lookup,
i.e. host 192.168.0.254?

There is no lookup possible, because the reverse zone that corresponds
to intern is 2.0.10.in-addr.arpa. and it is not taken into account when
asking for an address like 192.168.0.254 not in 10.0.2.

So how to solve this? Add a reverse zone for 192.168.0.254 like 
168.192.in-addr.arpa.?

I tried that, but in GOsa the reverse zone is created automatically
from the forward zone. Which means I have to create a zone
corresponding to the 192.168.-net. but how should I call this zone? I
have to use the same domain i.e. "intern" which is not possible,
because there is already the 10.0.2-net with that domain.

First I thougth well, the 192.168.-networks are subdomains. But from
the old setup I saw that they are no subdomains at all. It's all the
same domain "intern".

But they are also no subnets in the sense that parts of the host
addresses are used for the network address. 10.0.2.- and 192.168.-
have no network-part in common.  

So how can we solve that? I have no idea. The subdomains would be one
solution, but I don't know how much changes that brings in the
end. A second solution is the inclusion of all machines we want to
manage under one domain with real subnets. That domain could be
handled in a single zone-file i.e. something like intern and
10.in-addr.arpa.   

Both 'solutions' look not very attractive in the short run.

Any ideas?

Best regards,

     Andi