Subject: Re: re-reading /etc/resolv.conf on change
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@NetBSD.ORG>
From: mouss <firstname.lastname@example.org>
Date: 01/08/2004 00:26:59
The thing is that (I just read about policy vs mechanism in a playboy,
so let me put it in:)
the 1st question is:
should resolv.conf be reloaded automatically if it is
My understanding is that it should be automatically reloaded. An
application queries the resolver to get an answer, it won't say "take a
margarita and then tell me the IP of foo, the guy who lives at
sosalitos", it'll only says "what's the IP of foo?" At least, this is
the way the resolver has always been _used_ [vs documented].
Also, the problem isn't just for host to IP or IP to host, it's also a
problem for getting the MX, and the like (so modifying gethostbystuff
doesn't solve the issue, if we happen to agree there's an issue).
Of course, this will cause trouble to those who relied on the
"misfeature" to use differnt resolv.conf for differnt apps. But
hey have been clever enough to do that, so they can be clever enough
to get around any modifications.
If so, the questions are:
1- how to detect the modification
2- where to implement the change
1- There are multiple possiblities:
* notification (via a signal or whatever)
However, there is no need for notification, since the program (at
any layer) can just check if resolv.conf was modified or
not. Also, signalling N applications isn't very nice. From a
design viewpoint, it's always better when programs take care of
their own instead of being notified by someone else: programs
ought to be adult
* always reload
This is a bit too expensive, mostly given the fact that
resolv.conf rarely changes.
* periodical reload
works, but is arbitrary...
* check at use
This seems to be the right way. a stat, following symlinks,
comparing the current (inode, mtime) with the last value, and
not reloading if both are unmodified, is the way.
2- where to implement?
This seems to be the hard point. If you look at it from the left, you
have to change the resolver, cos' it where myst is happening. If you
look from the right, you gotta not touch the resolver, cos' it ain't
your code. If you take it from behind, you don't see the front, and if
you put yourself up, you feel the cold clouds...
Should this be in the resolver itlsef, in gethostbystuff, in a new
wrapper lib or in the app?
Clearly, it is not desirable to have this in applications. This must be
Also, the gethost things don't solve the getmx problem (and the like),
besides being what I'd call rabbit functions (they proliferate too fast:
you now have all kinds of functions to do the same thing, but some are
reentrant, some are IPv6 compatible, some are something else, and in 6
months, you'll probably have gethostbyname_withmilk).
So it's either in the resolver or in a wrapper. Unfortunately, C isn't
wrapper friendly. A compromise is to add a new function to the resolver,
and make it used by defalkt, while not modifying a lot fo the resolver
code. but once you put your hands in the water, you'd better accept