[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind9-users
Subject:    Re: [PATCH] resolv.conf addition for mobile users
From:       Sten Carlsen <ccc2716 () vip ! cybercity ! dk>
Date:       2004-06-12 1:57:45
Message-ID: 40CA6319.8030801 () vip ! cybercity ! dk
[Download RAW message or body]

Jean Tourrilhes wrote:
>>scenario 1:
>>no conn. (no route) -> ifup eth0 (packets are routed via eth0; use DNS 
>>as given by eth0) -> ifup erth1 (packets are now routed along eth1!!; 
>>use DNS as given by eth1) -> ifdown eth1 (packets can now not go via 
>>eth1, so they go via eth0; use DNS given by eth0);
>>
>>Scenario 2:
>>no conn. (no route) -> ifup eth0 (packets are routed via eth0; use DNS 
>>as given by eth0) -> ifup erth1 (packets are now routed along eth1!!; 
>>use DNS as given by eth1) -> ifdown eth0 (packets can still go via eth1; 
>>use DNS given by eth1; erase DNS given by eth0);
>>    
>>
>
>	Correct.
>
>  
>
>>Policy: keep a number of independant resolver configurations => one for 
>>each open interface. Use the configuration that matches the actual 
>>packet routing.
>>    
>>
>
>	Ok, so you suggest that the resolver read the routing table
>directly ? This could certainly be done with a conditonal block like
>this :
>		if route 10.0.0.0
>		include /etc/resolv-10.0.0.0.conf
>		if end
>	One of my problem is that this is highly OS dependant and
>usually messy to do, but I can add that to my patch. I'm using only
>Linux, and I've got tons of code that read the routing table, so I can
>make it work in a snap. However, I don't want to add too much OS
>specific code because the code for other OSes won't magically get
>written itself.
>
>  
>
One question (for me at least) is:
If we have more than one connection to the outside, will we catch every 
change of the default route by monitoring only PPP and DHCP? Will 
somebody have a function that will switch the default route based on 
e.g. response times?
If PPP and DHCP are both up, will you always use the last one to come up 
as the route? If that is blocked will you not switch to the other that 
is up? In that case we may be using the wrong nameserver. If you don't 
switch when the default route fails to answer, then why do you keep two 
connections up at the same time?
Trying all nameservers to see which will respond may not be adequate in 
case the correct one uses views to give us an internal view that is not 
accessable from the others.

Basically I fear we may miss some changes by not looking at the route 
table. On the other hand we only have to look at it when it changes.

>>All this about overwriting and restoring different configurations is not 
>>ever going to work.
>>    
>>
>
>	That was exactly my point. We need to have the possibility to
>do better than that.
>
>  
>
I couldn't agree more. I am now in the process of understanding exactly 
all events that have effect on which nameserver we should use.

>
>	This is exactly what my proposal is about, giving us the hooks
>to enable this to happen.
>	Please read my proposal and patch, give me feedback and
>suggest useful improvements. I really want us to discuss that so we
>can find the right balance between simplicity and functionality.
>	For example, Mark's suggestion of using a local DNS caching
>server and changind named.conf would solve the problem, but is rather
>heavy and complex for the target devices. Actually, on StrongArm the
>IPC cost of such solution might also be an issue (IPC are slow on
>StrongArm due to slow context switches).
>
>  
>
My reason to understand the basics is to make sure nothing is missed and 
not more than needed is done.

I have not been working with the source code, so I can not give you a 
reasonable comment on the patches.

>>Sorry to start from not just scratch, but somewhere earlier.
>>    
>>
>
>	Hu ?
>  
>
You have been on this much longer than me forgive me that I need to 
catch up.

>
>>I use a MAC OSX pc, it does solve most of these issues already. We might 
>>want to look at how they do it before rushing to quick fixes.
>>    
>>
>
>	Please report ;-) Note that Win32 also seems to get it right,
>but I don't expect to know how they do it :-(
>
>  
>
As far as I can tell the Apple source code is available at:
http://www.opendarwin.org/downloads/

I have not looked into the sources, I assume you could get the picture 
much quicker than me.

>	There is an alternate solution, and OS-X might do that :
>	1) Add only the "volatile_config" part of the patch to the resolver
>	2) Add a deamon that monitor the various part of the system
>and generate the right resolv.conf.
>	I don't like this solution for two reason :
>	A) Adding yet another daemon sucking ressources, and yet
>another config file to configure for this deamon. We are targetting
>mobile clients, footprint do matter, and the StrongArm is notoriously
>bad at context switching.
>	B) We need to mobify the resolver anyway because of (1), so we
>don't decrease the level of pain. If we modify the resolver, we might
>as well do it completely.
>	This is why the proposal look like it is today.
>
>	Have fun...
>
>	Jean
>
>  
>


-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 




[prev in list] [next in list] [prev in thread] [next in thread]