3

TL;DR ...our domain policy silently force pushed the LAN settings (including the proxy reference) to my machine on a predefined interval, which happened to be while I was developing but after I had manually disabled the proxy. Since I knew for a fact that I had disabled it for local addresses, it did not occur to me that it would be the root of my issue.

On one of my development machines that is running Windows Server 2012 R2, I am experiencing curious behavior with local resolution of a host through the hosts file.

[ Description to reproduce ]

Console

C:\Windows\system32>ping baz.inga
Ping request could not find host baz.inga. Please check the name and try again.
C:\Windows\system32>_

Hosts file

127.0.0.1 baz.inga
::1 baz.inga

Back in Console

C:\Windows\system32>ping baz.inga

Pinging baz.inga [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Windows\system32>_

...Then, I host an application on localhost:7890

Fiddler

/GET http://baz.inga:7890

[Expected]: local host resolution resolves "baz.inga" to "localhost" and serves my content

[Actual]: 503 "Service Unavailable" response and a DNS lookup failure

Is there any reasonable explanation as to why this is not resolving locally? I tested the exact same procedure out on a machine running Windows 7 and the response to the HTTP Proxy is a locally resolved resource.

WTH?!?!

K. Alan Bates
  • 223
  • 2
  • 12
  • The HTTP 503 "Service Unavailable" contained the DNS lookup failure in its response body. I'm sorry if that wasn't clear when I said that the 503 was returning a DNS lookup failure. – K. Alan Bates Feb 04 '16 at 23:53
  • I was afraid that there might be some "down in the weeds" settings in the Server Operating System that I was unfamiliar with that forced these settings and precluded local host resolution. – K. Alan Bates Feb 04 '16 at 23:57

2 Answers2

2

HTTP 503 is an error response from your application, not a DNS lookup failure; if the request wasn't actually able to reach your application due to not resolving its hostname, it would not have received a 503 response.

Looks like your name resolution is ok (as expected, and as confirmed by ping working); your application, instead, isn't.

Massimo
  • 68,714
  • 56
  • 196
  • 319
  • ...I was about to reply that whenever I navigate to `http://localhost:7890` in the browser (tested out earlier), that the application loads fine but for some reason it currently is not. ...my ref to `http://localhost:7890` is getting switched out to `http://www.localhost.com:7890` which is definitely screwy. I must have broken something else trying to fix the local resolution issue – K. Alan Bates Feb 04 '16 at 22:13
  • ...I think that `www.*.com` snafu was related to trying to set up an lmhosts file. Deleted it and that error went away. Now, when I browse to `http://localhost:7890` I get my application, but when I hit `http:baz.inga:7890` in Fiddler, I get the same 503 error that I reported. – K. Alan Bates Feb 04 '16 at 22:23
  • Well, i still think the issue is in your application. It might be expecting to be called in the proper way, i.e. using host headers; a web server *can* and *will* do different things if you call it "localhost" or "baz.inga", depending on its configuration. – Massimo Feb 04 '16 at 22:24
  • It's being hosted in IIS and `baz.inga` is set up as the host header in the binding. `re:"depending on its configuration"` ...please continue – K. Alan Bates Feb 04 '16 at 22:29
  • `re: web browser` Same problem. "503: Service Unavailable" If I self-host outside of IIS, the local host resolution works in Windows 7, but not in Windows Server 2012 R2. – K. Alan Bates Feb 04 '16 at 22:32
  • 1
    503 is an *application error code*. The request *is* getting to your web server; what isn't working is in the actual code (or in the web server configuration), which screws up when it's called using that name. – Massimo Feb 04 '16 at 22:32
  • This is *not* a name resolution issue; it's a web server issue, or an issue with the application code. – Massimo Feb 04 '16 at 22:35
  • The 503 is being returned from an intermediate proxy that is identified through the 503's Via header, so I know that the request is leaving my machine and attempting a DNS lookup. It doesn't matter that a 503 is an application error code. I'm trying to figure out why a DNS lookup is even being made because I have an explicit hosts entry that should take priority over a DNS lookup. – K. Alan Bates Feb 04 '16 at 22:36
  • Sorry to be blunt, but your assumption that "the 503 is being returned from my DNS" is just plain *wrong*. A HTTP error code is returned from a *web server*, not from a DNS. – Massimo Feb 04 '16 at 22:40
  • Anyway, if you still don't believe the request is actually getting to your web server and crashing there, just have a look at the web server logs: they will tell you for sure if the request is getting there or not. – Massimo Feb 04 '16 at 22:40
  • An intermediate proxy? Why didn't you state this before? This adds lots of possible complications to the issue. You should provide more details if you want meaningful answers. – Massimo Feb 04 '16 at 22:41
  • ...an intermediate proxy is not even supposed to be involved because this request is not supposed to leave my machine. I'm trying to resolve the host name locally and that is the whole point of this. The intermediate proxy is proxying back a DNS lookup failure through a 503!!! I didn't think that the extra detail was pertinent because the crux of the matter is that this wasn't supposed to leave my machine. – K. Alan Bates Feb 04 '16 at 22:44
  • Unless you have proxy settings configured in Fiddler or in your web browser; have you checked that? – Massimo Feb 04 '16 at 22:51
  • Anyway, at this point a network sniffer would really be your friend. Just grab WireShark and check what's actually happening. – Massimo Feb 04 '16 at 22:53
  • ...The stupid proxy was wrong. It was the first thing I checked (you know...seeing as how I was not wanting this to resolve through the proxy) but somehow the settings got reverted to the automatic configuration script pushed by our DC and it was trying to proxy localhost traffic. I was about to shoot myself in the face trying to get this damned thing straightened out. – K. Alan Bates Feb 05 '16 at 00:17
2

Our group policy dictates that the LAN settings for the domain automatically push out to all of our connected machines on a timer.

Although I had disabled the proxy script while configuring my local host resolution, when the timer was up, the proxy script reference was silently force pushed across the LAN and introduced my error. Since I had already disabled the http proxy manually, it did not occur to me that it would be the root of my issue and that it "must" be something more elaborate.

In lieu of creating a new "privileged" domain policy that does not have these strict settings automatically pushed, our solution is to define a convention where hosts intended for resolution on the local machine will be given a convention-based "reserved" ending authority segment, which will then automatically resolve through the proxy as a DIRECT reference by modifying the proxy.pac file pushed from the DC with

if(dnsDomainIs(host, ".reserved")) { return "DIRECT"; }

K. Alan Bates
  • 223
  • 2
  • 12