Hi, Thanks for the feedback. See my responses below:
andrewv@melbpc.org.au writes:
Assume I have (at most), all of these entries in /etc/hosts
custom1.company.com nnn.nnn.nnn.nnn custom2.company.com nnn.nnn.nnn.nnn default.company.com nnn.nnn.nnn.nnn
That won't work. It's
<address> <canonical name> [<alias> ...]
Sorry, you're right - my typo :)
where nnn is some specific IPv4 address number
I want to lookup the hosts in say this order:
custom2.company.com custom1.company.com default.company.com
It doesn't work that way, sorry.
I wasn't clear enough - I meant the application will specifically attempt to look up custom2.company.com, and if not found, will try to look up custom1.company.com, then if not found, will lastly try default.company.com. I wasn't trying to say that this search order had anything to do with how the lookup/resolving will be done for me by the lookup service.
If the custom2 entry is not found, I want to try custom1, and if not ok, then I want to try default.
You're talking about reverse resolution (IP to FQDN)?
No, I mean this is what my application will explicitly attempt, in that order.
Importantly, I do _not_ want _any_ DNS lookup to be performed for _these_ _specific_ host lookups, because I want an immediate failure if the entry is not defined in /etc/hosts.
I don't think you can have that, at least not on a per-host basis.
ok
The way different name services (such as flat files and DNS) are used is governed by nsswitch on eglibc/glibc-using (and most other) systems.
You can probably add
1.2.3.4 canthappen.invalid
And if nsswitch has "hosts: files dns" then it will hit that first, and not try DNS. You can't have an absence in /etc/hosts -- hosts(5) has no support for the equivalent of an authoritative NX RR.
ok
Note: I want an _immediate_ failure initially, _and_ for every lookup thereafter - an initial DNS lookup that fails after a DNS lookup timeout, and then perhaps caches that failure result is no good, because every lookup must respond immediately (and of course /etc/hosts and DNS service entries can change at any time so even then, cacheing is not useful).
You can't have this with hosts(5).
ok
Your best bet is probably to point resolv.conf at a local DNS resolver that is configured to return spoof results for particular domains (including, obviously, the C.B.A.in-addr.arpa for the PTR RR).
This one sounds like the most viable option for me. I can run a DNS resolver on the same host as the application is running on, and configure it just for this application, and change the DNS search order to consult this local DNS service first (and then the ones it currently uses). I can use multiple domains if needed (not just company.com).
You could, alternatively, disable DNS altogether and ensure that all hosts you need to reach are hard-coded in /etc/hosts.
Not an option, because many other lookups are performed aside from those servicing this application.
Assume that I am using software that I cannot change, and so workarounds like actually reading the /etc/hosts file to see which entries exist, cannot be wired into the software.
LD_PRELOAD might still be a viable option, though I don't recommend it.
Considered that one, I see it as last resort stuff, but yes, viable if nothing else hits the mark.
I am thinking of something functionally like a like /etc/disable_dns_lookup that I can also copy all 3 of the above entries to, and linux will _never_ try DNS if the entries appear in /etc/disable_dns_lookup.
AFAIK no such feature exists.
This all sounds like an xyproblem; what is the ACTUAL problem you're trying to solve?
I want to be able to use the configuration entered in /etc/hosts, as the sole data driven means of configuring host selection order, assuming the hosts are always going to be on an internal network, with well known addresses.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Message sent using MelbPC WebMail Server