Firstly, I will illustrate shortcomings of the existing scheme:
Imagine you have a computer set up to use your home network. You have fixed the ip address and DNS settings. You take your machine to a friend's house then use DHCP to configure the adapter. Your DNS settings will be overwritten. You will need to re-write /etc/resolv.conf to make your machine operate again on the home network.
Imagine you have a local office network. You need to make a VPN connection to another office. You need to use the remote office's DNS server whilst connected. You will need to overwrite your resolv.conf file and DNS settings for the period of the connection. You will then need a method of reverting the resolv.conf file to it's original state. This in practise, often fails, leaving the local network broken. For example, when pppd dies unexpectedly.
As in 2 above, you may have domain names you need resolved both by your local DNS server and by the remote DNS server over the VPN. The current set-up does not provide a method for DNS look-ups to fall through to another server.
Like in 2, above, you have a local network. You need to connect to the internet through dial-up on your local computer. Whilst dialled on the internet, your resolv.conf will be overwritten. The local DNS servers will not resolve anything for you.
Whilst a user is dialled up using VPN or internet connection sharing, the resolvers have changed for all other users of the system. One user may then render the system inoperable for all other users.
Imagine you have a wired and a wireless network adapter. Your wired network adapter uses a fixed ip address and fixed dns. You connect to a wireless network, configure DNS and ip through DHCP. When you wish to revert back to your fixed ip fixed DNS adapter, the DNS settings have been permanently altered. Normal internet will no longer operate on your wired adapter till your resolv.conf is updated.
When a DNS resolver entry is added to the system temporarily, eg through PPP/VPN or DHCP, the DNS resolver entry should by default be removed again when no longer needed, leaving the resolver entries unchanged.
When multiple DNS resolver entries are temporarily added to the machine, each DNS server is searched in a prioritised fashion. So if you have a local DNS server then you connect to the internet via ppp, you may still resolve domain names only available through your local DNS server.
2a) The resolver entries added by DHCP or PPP are searched first. If they fail to resolve to an ip address, the query is handed in turn to the less recently added DNS entry then finally to the default system DNS entries.
Domain name entries specific to a user. If a user connects via VPN to a remote network, only applications started by that user should use the remote VPN DNS server. DNS entries made by a user using VPN should not necessarily change the resolver for all users. A resolver change can be either per user or system wide.
/etc/resolv.conf remains the system's default file containing a list of nameservers and the search domain. The proposed system is therefore fully backwardly compatible with existing systems.
The resolver checks directories in the following order:
~/.resolv.d/*
/var/resolv.d/*
/etc/resolv.conf
Files in the resolv.d and .resolv.d directories are sorted by modification time. Ideally, early in the boot process, ~/.resolv.d/ and /var/resolv.d/ are cleared to ensure no stale resolver entries remain from a previous boot. pppd and dhcp-client should name the files in the resolv.d directory according to the name of the network interface (eg eth0, wlan0, ppp0). This way, if the DNS associated with the interface changes, the file is overwritten. When pppd dies or a lease on a network interface expires, or the net interface is disconnected, the process which created the resolver file should delete the file. This proposal only recommends the files in the resolv.d directories contains a list of nameservers. There may be scope to add other data in the folders, such as priority or expiry data. Therefore I recommend each nameserver entry keeps the same format as the /etc/resolv.conf file where each nameserver is prefixed with the word nameserver.
This may currently be half-baked but should form the basis of a great resolver upgrade. I have attached a flow chart of the program flow which should explain any ambiguities.
You can download a source file for the chart http://www.nickhill.co.uk/resolver_proposal/resolv_proposal.dia
This proposal and chart may be distributed and modified under the terms of the GNU FDL. If you feel like implementing this in code, please do so! email me at nick at nickhill -dot- co -dot- uk
