bind9-users Digest V5 #155

[Jean Tourrilhes]

On Sat, Jun 12, 2004 at 07:51:39AM +0000, ISC Mailing List Manager wrote:
> Date: Sat, 12 Jun 2004 03:57:45 +0200
> From: Sten Carlsen <ccc2716 at vip.cybercity.dk>
> Subject: Re: [PATCH] resolv.conf addition for mobile users
> 
> 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.

	This is even more messy than that. A casual look at the
routing table can't tell you if a given nameserver is going to work or
not.
	Just to give you a *real* example. This is my route table :
----------------------------
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
15.4.88.0       0.0.0.0         255.255.248.0   U     0      0        0 eth4
0.0.0.0         15.4.88.1       0.0.0.0         UG    0      0        0 eth4
----------------------------
	The appropriate nameserver are :
-----------------
search hpl.hp.com
nameserver 15.0.48.4
nameserver 15.0.152.4
nameserver 15.255.168.31
-----------------
	In this case, the proper route is "0.0.0.0". But, 0.0.0.0
could point to anywhere else, so testing the presence of the 0.0.0.0
route is not enough. In other case, you would use the subnet route,
and that works differently. And you have no idea what kind of route is
going to be configured, I may use a specific host route just for the
nameserver.
	But, remember that I'm behind a application level
firewall. Therefore, I can access some part of 15.X, and some part of
15.X is not accessible (on the other side). So, I can't access the
nameserver on the external HP network (but you can). There is no way
I'm going to know that from the routing table.
	If you want to do a perfect job, the only way to know is to
try it, i.e. to send the request over the network. But, that's exactly
what I'm trying to avoid for performance reason. And also because all
resolver only allow for 3 nameserver, which is totally inadequate for
such scenario.

	So, what do I want to acheive. The point is not to get the
perfect solution, that's impossible, but to get something that works
in most cases and give the user enough hooks so that he can make the
system works for him.
	Now, back to your example. My assumption is that, if DHCP or
PPP setup goes far enough to get some DNS info, it means that there
was network connectivity one node on the subnet (PPP/DHCP
server). Most connectivity problems happen at the link level, which
means at that point, except rare messup of subnet config, you are good
to go. Similarly, when link connectivity goes down, PPP and DHCP will
exit and cleanup.
	If both are up at the same time, you just hope that either the
nameserver are on the local subnet (most case - would work ok), or
that the user knows what he is doing and fix the resolver
configuration accordingly. Because the config is now split in multiple
files, one per interface, it's easy for the user script to just rename
the file of the interface it's not using to something else. The
difference with what we have today, is that today we have an anonymous
config in /etc/resolv.conf, whereas my proposal allows to strongly
associate config to interface, making it easy to know which is which.
	Note that in the case of most mobile device, for battery sake,
you really want to "down" the interfaces that you are not using. And
it's far easier to just down an interface than to play elaborate
tricks with the routing table.

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

	I'm not familiar with *BSD code, and I've never used OS-X, so
you would know much faster than me. Just check the content of
resolv.conf on a live system and how it evolves.

> Best regards
> 
> Sten Carlsen

	Have fun...

	Jean