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:
>>>>>>>
>>> Rather than tweaking the resolver on the client, however, it would  
>>> be
>>> better to put two A records for the FQDN in DNS. The FD would then  
>>> have
>>> to pull all IPs from its DNS query and favor an IP in its own subnet
>>> over the others. I doubt the FD currently does this (though it  
>>> might be
>>> worth a try). It probably pulls only the first IP, in which case  
>>> the IP
>>> chosen would alternate between the two because the resolver normally
>>> load-balances in round-robin fashion by changing the order of the
>>> answers. So this likely wouldn't work without a change to the FD to
>>> cause it to parse the addresses returned from the resolver and  
>>> look for
>>> an IP in its own subnet, rather than just choosing the first answer.
>>>
>>
>> Deliberately putting unroutable IP addresses in the DNS sounds  
>> wrong to me,
>> because it will break communication with the SD for all other  
>> programs that
>> don't check both addresses.
>>
>
> 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.

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

-- 
Vereinigte Verlagsanstalten GmbH
Höherweg 278 | 40231 Düsseldorf
fon +49 211 7357-0 | fax +49 211 7357-123

HR Düsseldorf HRB 658
Geschäftsführer Stefan Meutsch




-------------------------------------------------------------------------
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