On 09/30/2016 10:12 AM, Reindl Harald wrote: > > Am 30.09.2016 um 16:22 schrieb Tim Daneliuk: >> On 09/29/2016 04:45 PM, Darcy Kevin (FCA) wrote: >>> Yeah, sure, just run it with your own special config file (with -c); in >>> that config file, set the listen-on to an unprivileged port, and make sure >>> all of the pathnames (including implicit pathnames like the pid-file) are >>> to files/directories to which the unprivileged user has read and (where >>> necessary) write access. >>> >>> As a sanity check, I just fired up an instance on a Red Hat box, as an >>> unprivileged user, listening on port 12345. It's a caching-only config, >>> with our own internal-root hints, and it's resolving (internal) names just >>> fine. >>> >> How did you get your code to look at that instance:port rather than the >> one dictated by /etc/resolv.conf or a local server on port 53? > > dig [@server] [-b address] [-c class] [-f filename] [-k filename] [-m] [-p > port#] [-q name] [-t type] [-v] [-x addr] [-y [hmac:]name:key] [-4] [-6] > [name] [type] [class] [queryopt...]
As I understand it, dig uses it's own code to determine which resolver to use, hence this works. In my particular case, I am trying to figure out a way to redirect gethostbyname() calls to the resolver of my choice so that existing code will run without change. The problem is that I need to do this without root or sudo access to the machines in question, and this is increasingly looking impossible. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
