Re: Temporarily changing DNS servers and search domains in Tiger
Re: Temporarily changing DNS servers and search domains in Tiger
- Subject: Re: Temporarily changing DNS servers and search domains in Tiger
- From: Allan Nathanson <email@hidden>
- Date: Thu, 2 Jun 2005 14:35:16 -0400
On Jun 2, 2005, at 1:42 AM, Nicholas Riley wrote:
On Jun 1, 2005, at 11:10 PM, Allan Nathanson wrote:
As in the past, the network configuration agents post information
to the SCDynamicStore (on a per-service basis) which reflects the
requested and derived DNS configuration. A configd plugin,
IPMonitor, collects all of this information and builds a DNS
configuration based on the current state. The change for Tiger is
that we have a new way of passing around the actual DNS
configuration to the resolver code. We left the /etc/resolv.conf
file in place to help any legacy code which looked at its contents
but the file is essentially a read-only copy of the configuration.
Makes sense.
Again, the State:/Network/Global/DNS key in the SCDynamicStore
reflects the generated configuration. Changing the value (which
you shouldn't have been doing anyway) won't have any effect.
I wasn't able to find anywhere that said you weren't supposed to
change these - but now I know.
In general, all of the SCDynamicStore keys (or at least those
involved in the network configuration) should be viewed along the
lines of a single "writer" and one or more "reader"s. With this view
we don't need to worry about one process (or plugin) stepping on the
toes of another.
Your VPN configuration agent/tool should publish a network service
with its desired DNS configuration.
Since the VPN tunnel interface doesn't show up in
SCNetworkInterfaceCopyAll(),
The SCNetworkInterfaceCopyAll() API reports interfaces associated
with "real" network capable devices including ethernet, airport,
firewire, and modems (which can be used w/PPP). The API also reports
VLAN and BOND interfaces.
and I need an interface before I can create a service, should I use
kSCNetworkInterfaceIPv4 or the current primary interface as a
parameter to SCNetworkInterfaceCreateWithInterface (or something
else?).
What you probably want to do here is create an [VPN] interface which
is layered on top of IPv4.
vpn = SCNetworkInterfaceCreateWithInterface(
kSCNetworkInterfaceIPv4,
CFSTR("edu.uiuc.vpn"));
Unfortunately, there are a couple of gotchas.
1. The code that shipped with Tiger won't allow the above call (I
included all of the "supported" types but left out the code to allow
"non-supported" types).
2. The Network Prefs pane isn't ready for non-standard interface types.
3. Your configuration agent would still need to most of the work.
You'd still need to read the preferences, create the network
interface, establish the tunnel, and post information about the
"state" of your service. For a VPN service, it's the "state" that's
key to making everything work. Yes, you "could" store some
configuration information along with the preferences but that
information could also be pulled from the application(s) that bring
the tunnel up/down.
It would be good to file a bug report / enhancement request to help
track the issues.
SCNetworkServiceCreate(scPrefs, kSCNetworkInterfaceIPv4) crashes,
so I imagine that is totally wrong.
You can configure an ethernet interface (e.g. en0). You can
configure a PPP interface (e.g. ppp0). What you can't do is
configure a IPv4 address.
As to the crash, can you please file a bug report?
Which kSCNetworkInterfaceType should I be using? (The VPN is none
of the predefined types, e.g. kSCNetworkInterfaceTypePPTP or L2TP.)
Ideally, you'd establish your own custom type.
SCNetworkInterfaceGetSupportedProtocolTypes
(kSCNetworkInterfaceIPv4) returns NULL, which seems to contradict
the documentation.
This is correct since you can't run any network protocol types such
as IPv4 on top of an [IP] address. What you need to do is layer a
network interface on top of IPv4.
A call to SCNetworkInterfaceGetSupportedInterfaceTypes
(kSCNetworkInterfaceIPv4) will report that you can layer L2TP, PPTP,
and 6to4 interfaces on top of the kSCNetworkInterfaceIPv4 interface
and it's these layered interfaces that support the various protocol
types.
Having your VPN tunnel become the primary service is the simplest
solution (you'll capture both the default route and the default
resolver configuration). Other options are also available but
they are a bit trickier.
I'm not sure what you mean by "capture"; if necessary I guess I
could manually reestablish the default route once the DNS changes
take effect. Sending all traffic over the VPN interface is not
really an option.
The IPMonitor.bundle looks at all of the active network services and,
based on the service order established in Network Prefs and any
"OverridePrimary" keys, determines which service should be
"primary". Both the default route and the default resolver
configuration track the primary service.
If you *DO NOT* want the default route pointing to your VPN tunnel
but you *DO* want to change the default resolver configuration than
you're best option would be to "OverridePrimary" but specify the same
default route.
Also, if you only want to direct DNS requests to an alternate
resolver for a specific [set of] domain name[s] than you might
consider using Tiger's new "supplemental" DNS support. Briefly, this
is a mechanism to say "send DNS queries for the foo.bar domain to a
different DNS server. I can provide more details if needed.
Note: it's best to work with the system/network configuration
agents than to try and change things behind the scenes.
That's what I'm trying to do. :-)
Great!
- Allan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden