Am 06.06.2008 um 16:04 schrieb Josh Fisher:
>
> Ariano Bertacca wrote:
>> Am 05.06.2008 um 16:32 schrieb Josh Fisher:
>>
>>
>>> Martin Simmons wrote:
>>>
>>>>>>>>> On Wed, 04 Jun 2008 14:16:33 -0400, Josh Fisher said:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>> Why would they be unroutable? If you have two subnets that are not
>>> routable between each other, then it wouldn't make sense to have a
>>> DNS
>>> server with a single view spanning both of those subnets. Either
>>> the DNS
>>> server would have separate views for each of the subnets or each
>>> subnet
>>> would use a different DNS server. Come to think of it, you are
>>> right.
>>> The more I consider it, the more I am coming to believe that this
>>> is a
>>> DNS configuration problem, not a Bacula problem. Name resolution
>>> should
>>> not be returning an unroutable address.
>>>
>>
>> Imagine:
>> Two networks: A = 192.168.1.0/24 and B = 10.1.0.0/24
>> The Backup Server contains DIR and SD and has two interfaces:
>> 192.168.1.10/24 and 10.1.0.10/24.
>> FD has one interface (10.1.0.11/24).
>>
>> The backup server has a fqdn which is "backup.internal.foo.local".
>> Both systems use the same dns and backup.internal.foo.local has one
>> A record (192.168.1.10).
>>
>> Now: the FD will get backup.internal.foo.local as SD and tries to
>> connect. The packet may even be routable, but the answer will
>> always come from the wrong ip, because the SD will answer from the
>> nearest interface, which would be 10.1.0.10. This could be fixed,
>> but that's not the point right now.
>>
>> When i add the second A record to the host
>> backup.internal.foo.local i will get both addresses and the FD
>> might even check both, but imagine other hosts inside the network
>> 192.168.1.0/24 that might not be able to reach 10.1.0.0/24. These
>> will now fetch a second A record and might fail to connect, since
>> they don't know about 10.1.0.0/24.
>>
>
> No. This is why bind 9+ has the View clause. It allows different
> views of the namespace it is serving depending upon whether the
> connecting client matches certain criteria. The match-clients
> directive in each view determines which view the client will see.
> The example below defines a DNS server with 2 views, one for clients
> connecting from 192.168.1.0/24 and one for clients connecting from
> 10.1.0.0/24. When clients on the 192.168.1.0/24 network query the
> DNS server for the name backup.internal.foo.local they will receive
> the answer 192.168.1.10. But when clients on the 10.1.0.0/24 network
> query the DNS server for the same name they will receive the answer
> 10.1.0.10.
>
> I have found this the best way to handle split networks in general.
> Much easier than fiddling with hosts files on clients or working
> only with IP addresses.
I'm quite sure that this is a valid solution, but only if the user
really uses bind and/or is capable of making changes to his bind
setup. There may be setups where other nameservers are used, or where
modifiying the nameserver is out of the question.
Anyway - i think that a problem that relates to a specific problem in
one piece of software should be taken care of in that particular
software and not elsewhere.
It might be easier to tweak the name resolution, but the only way to
find a solution that does not depend on external modifications, would
be to clear up the issue inside bacula. I can easily imagine several
setups (from small single-user sites, to enterprise business) where
that tweaking solutions can't be done as easily as we are talking
about them.
Cheers
Ariano
>
> # example bind 9.x views for split network
> options {
> ...
> };
> view lan1 {
> match-clients { 192.168.1.0/24; };
> zone "internal.foo.local" {
> type master;
> file "lan1.hosts";
> };
> };
> view lan2 {
> match-clients { 10.1.0.0/24; };
> zone "internal.foo.local" {
> type master;
> file "lan2.hosts";
> };
> };
> #eof
>
> # lan 1 hosts
> internal.foo.local IN SOA ns1.internal.foo.local.
> hostmaster.internal.foo.local. {
> ...
> backup A 192.168.1.10
> lan1-client A 192.168.1.20
> #eof
>
> #lan 2 hosts
> internal.foo.local IN SOA ns1.internal.foo.local.
> hostmaster.internal.foo.local. {
> ...
> backup A 10.1.0.10
> lan2-client A 10.1.0.22
> #eof
>
>
>> It gets even worse when you transform 192.168.1.0/24 to a valid
>> and internet routable address and your servername is something
>> like backup.my-domain.com and people from all over the world get
>> your valid address, as well as your private ip, which - in this
>> case - would definitly be unroutable.
>>
>> I don't think that would be a good idea ;)
>>
>>
>> Kind regards
>>
>> Ariano Bertacca
>> Systemmanagement
>>
>>
>> fon +49 211 7357-834 | fax +49 211 7357-859
>>
>>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
