The latter part of this post is wrong. I was under the impression, based on some stuff I had read on the web (if it's on the web, it must be true!) that part of the Windows DNS Server Service's tasks for creating its cache was to also load its host file into cache along with its local zone data. I searched around and couldn't find hard evidence of this. I tested the theory on my own Server 2008 R2 machine and found that the hosts file was not used to build the DNS Server's Cache.
However, I believe I have a slightly more elegant solution that Massimo. Instead of creating an authoritative zone for the entire nlscan.com zone, simply create a zone named mailserver.nlscan.com and place a nameless A record in that zone. The nameless A record will have the same name as the zone itself and you can give it the IP address that you want. All other domains underneath nlscan.com as well as nlscan.com itself will resolve by public DNS.
I just tested this out on my own Server 2008 R2 DNS server and was able to make my friend's website (nessus.nl) resolve via public DNS servers but the specific subdomain (blog.nessus.nl) resolve to an Apple.com IP address. Try it and see if it works for you.
Older, wrong post commences:
If my understanding is correct (EDIT: and it is not), when the DNS cache is built in the Server 2003 machine it pulls in entries from the hosts file as well as it's zone data. Placing 172.16.0.10 mailserver.nlscan.com
in your Server 2003 machine's hosts file should solve the problem. Restart your DNS services after changing your hosts file.
Use ipconfig /displaydns on any Windows machine (specifically, your Server 2003 DNS machine) to see your host file entries. Also keep in mind that negative responses are cached in your clients so always run ipconfig /flushdns on the clients that you're experimenting with. Otherwise you'll end up abusing yourself against various hard objects as you wonder why your clients can't resolve a name you just entered into a zone / hosts file. =)
Have you tried this and failed?
Not exactly: it depends on how the client is configured. Let's use IE as the basic example.
If you configure IE with an explicit proxy: e.g. no other options ticked, proxy set to something:8080.
User types an address
IE checks the address for a string match against the IE proxy exceptions list (i.e. "Bypass proxy for these addresses:")
a. If it matches an entry in the Bypass list, the client uses its own DNS to resolve the name, and then the client connects directly to the target IP address on port 80 (assumed), then sends a request like:
GET /something.htm HTTP/1.1
Host: fulldomainame.example.com
b. If no bypass list entries match, continue:
IE connects to its configured proxy, and sends a request of the form:
GET http://fulldomainname.example.com/something.htm HTTP/1.1
Bonus factoid: this use of the FQDN in the URL is one way you can tell that a client thinks it's talking to a proxy instead of a real web server
The proxy resolves that host name using its own DNS, and then connects to the target site (acts like the client in step 2 above), etc, etc.
When using WPAD/PAC:
In the case of using a Web Proxy Auto Discovery (WPAD) or Proxy Auto Configuration (PAC or Autoconfig) script, such as those provided by ISA/TMG when autoconfiguration is enabled, it's different:
User types an address
Client downloads the current wpad.dat/autoproxy.js/.pac file from its configured location
Client looks for the function "FindProxyForUrl" in the js file, and executes it
The Autoproxy script processes the hostname and URL. This is a limited-function javascript file, but lots of things are still possible:
a. this may include name resolution (IsInNet, DnsResolve)
b. this may include string matching (ShExpMatch)
c. this may include counting to a million (i++)
d. this may include narky alert popup messages if the admin's a jerk
- (or just funny)
- ((or debugging))
The FindProxyForUrl function returns at least one string: an ordered list of the best proxies to use (semicolon separated)
a. either "DIRECT", in which case the client then needs to resolve the name itself and connect directly, as per the Bypass case above
b. or "PROXY proxyname:8080" or similar, in which case the client connects to that port on that proxy, tells it to GET the full URL, and the proxy performs name resolution.
- As an example: if the script function returned "PROXY yourProxy:8080;DIRECT" that tells the client to connect to yourproxy on TCP port 8080 to request this URL, and if that connection can't be established, try going direct.
Note that TCP session setup failure isn't exactly quick, so this isn't likely to be a pleasant failover experience for a user, but beats nothing. Maybe.
There are occasionally glitches, subtleties and unexplained behaviours, but for the most part when things aren't broken in weird and interesting ways, the above is how I've seen it work over many years. Newer browsers are optimizing behaviour, and parallelizing stuff, and trying interesting things all the time, so check out the most recent docs for your given browser to understand the fine detail.
WinSock Proxy / ISA Firewall Client / TMG Client:
If you're interested in the Winsock Proxy Client (from TMG/ISA Server), that's a different story, with more flexibility and moving parts. Too much to go into here, but there are docs around which describe how it works. In short: it plugs into Windows Sockets, and can intercept both TCP/UDP based traffic and name resolution requests on a per-app and per-user basis. Very powerful, but also deprecated now, and hasn't been updated in several years.
Clients can be Really Clingy:
One final note: Once an HTTP client has decided to talk to a proxy for a given site/url, there's no way for the proxy to tell it not to.
There is no HTTP status code or header for "I don't serve that, you should just go directly to it instead"...
Once the client decides a particular URL is proxy-served, proxy-death-grip ensues.
The only way to avoid it is by getting the selection logic right before the client makes its connection, in the PAC or Bypass list.
A final note on Zones and PAC files
IE treats sites which are DIRECT connected - even if they have dots in the URL - to be part of the Local Intranet Zone (by default - settable in Zone properties), and so will do things like allow Integrated Windows Authentication to those sites (i.e. Kerberos and/or NTLM authentication, transparently). So controlling whether something's in the Local Intranet Zone defines how trusted it is in terms of automatic authentication. Again, at least, by default.
Best Answer
As proxy is not managed by you it's hard to understand what is the situation there. But This server (with proxy) have and use own resolv mechanism and have no idea about your
/etc/hosts
file.You can create own proxy server which forward requests to external proxy for particular hosts and work only for your local machines.
As per edit: you can try to update
hosts
file on the router to make resolv of local hosts faster.