bind9-users Digest V5 #155
Sten Carlsen
ccc2716 at vip.cybercity.dk
Tue Jun 15 07:46:41 UTC 2004
Jean Tourrilhes wrote:
>
> 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.
>
>
>
Yes for mobile and even portable (battery operated) devices all
interfaces not needed will be not just down, they will be "power off".
This leaves the question of switching sequence: current if goes down
(off line) before next is started. Or opposite? I believe in the first.
A user will always(?) use the cheapest way to connect and only when that
fails switch to the next option (if any). If this is true, clean up is
much easier and only the code for each if going up or down needs to be
involved. This is pretty much current situation, where this gets messy
is when you also have fixed (static) setups involved, and when DHCP or
PPP will not provide the needed details.
Routing tables from my MAC, I don't use IP6:
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default christina.s-carlse UGSc 2 0 en1
localhost localhost UH 10 29367 lo0
169.254 link#5 UCS 0 0 en1
192.168.14 link#5 UCS 1 0 en1
silver.s-carlsen.d localhost UHS 0 0 lo0
christina.s-carlse 0:2:96:1:3e:98 UHLW 5 354 en1 200
Internet6:
Destination Gateway Flags Netif Expire
UH lo0
fe80::%en0 link#4 UC en0
0:3:93:d3:c3:36 UHL lo0
fe80::%en1 link#5 UC en1
0:3:93:eb:7f:59 UHL lo0
ff01:: U lo0
ff02::%lo0 UC lo0
ff02::%en0 link#4 UC en0
ff02::%en1 link#5 UC en1
>>> 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.
>
>
>
>
Fresh from the system (behind a NAT. All details given by DHCP):
silver:~>cd /etc
silver:/etc>ls re*
resolv.conf
resolver:
254.169.in-addr.arpa local
silver:/etc>cat resolv.conf
domain s-carlsen.dk
nameserver 192.168.14.254
silver:/etc>cd resolver/
silver:/etc/resolver>ls
254.169.in-addr.arpa local
silver:/etc/resolver>cat local
nameserver 224.0.0.251
port 5353
timeout 1
silver:/etc/resolver>cat 254.169.in-addr.arpa
nameserver 224.0.0.251
port 5353
timeout 1
silver:/etc/resolver>
All the resolver/* stuff is for "Rendevouz" = multicast DNS , even that
works together with windows on a separate isolated network.
> Have fun...
>
> Jean
>
>
--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
More information about the bind-users
mailing list