Can IIS refuse to serve a domain?

[Mabel van Asperen]

I run a website from home under IIS using my own domain name (myDomain).
I've got a dynamic ip address, which changed yesterday. I updated the dns records accordingly: two A-records, one for myDomain, one for www.myDomain.
Now, the site comes up fine for www.myDomain but myDomain produces a timeout!
What could possibly be the cause of this behaviour?
I can't understand where the fault could lie. I have PINGed www.mydomain as well as myDomain, with the exact same result. (I have no ping-server running so I don't get a response, but I can see the ip address the ping is sent to.) It seems as if IIS is simply refusing to serve myDomain, but that is technically impossible, isn't it?
I'm baffled

Mabel

 

[ChatGPT]

Hi Mabel,
Your situation where www.myDomain works but myDomain times out, despite both A-records pointing to the same updated IP, is a classic IIS and DNS binding-related issue rather than IIS "refusing" the domain outright. IIS itself does not refuse domains arbitrarily, but it will only respond on host headers and bindings explicitly configured.
Here are the most likely causes and what you can check and adjust:

1. IIS Site Bindings: Host Header Configuration
   • IIS sites must have bindings for each domain name they serve.
   • Check your IIS Manager under your website’s Bindings and ensure you have entries for both:
     • myDomain (without www)
     • [www.myDomain](http://www.mydomain)
   • Bindings can be on port 80 or 443 (SSL) and must specify the proper hostname in the Host Name field if you use host headers.
   • If only the [www.myDomain](http://www.mydomain) binding exists, then IIS will only respond to that and ignore requests to myDomain causing a timeout.
   • To fix, add a binding for the naked domain (myDomain) especially if DNS is set correctly.
2. DNS Records Consistency
   • You mentioned having two A records, one for myDomain and one for [www.myDomain](http://www.mydomain) pointing to the updated IP. Double-check:
     • That there are no typos or trailing dots.
     • That DNS propagation has fully completed (although ping shows correct IP which is a good sign).
   • A common cause is that the naked domain might have a CNAME or other conflicting record.
3. Firewall and Router Port Forwarding
   • Since you host from home, ensure your router forwards HTTP (port 80) and HTTPS (port 443 if used) correctly to your server IP for requests coming to both domain variants.
   • Sometimes routers handle domain-based forwarding differently if advanced settings are in place.
   • Since www.myDomain works, this is less likely but worth verifying.
4. Browser or Cache Issues
   • Sometimes cached DNS or expired browser cache on your client may cause inconsistent behavior. Try accessing your non-www domain from another device or network.
5. IIS Logs and Network Tracing
   • Check IIS logs to see if requests to the naked domain are reaching your IIS server at all.
   • If no logs are generated when accessing [url]http://mydomain[/url], it likely means requests aren't reaching IIS, possibly DNS or firewall problem.
   • If logs show requests but no responses, check HTTP error logs or firewall rules on the server.
6. Timeout vs. Refusal
   • A timeout means no response is received at all, which often points to DNS or a network routing issue.
   • A refusal would imply IIS replied with an error, like 404 or 403.

Summary: Your IIS server must have explicit bindings for both the naked domain and www subdomain. Without these, IIS will not respond to one variant even if DNS points there. Also verify your router and firewall allow incoming connections on the expected ports for both.
Steps to Fix:

1. Open IIS Manager.
2. Select your website.
3. Click on "Bindings" in the right pane.
4. Ensure two bindings exist:
   • One with Host Name: myDomain
   • One with Host Name: [www.myDomain](http://www.mydomain)
5. If missing, add a new binding for myDomain on port 80 (and 443 if using SSL).
6. Restart IIS (iisreset).
7. Test access again.

IIS does not technically refuse a domain; it simply ignores requests for host headers it is not configured to serve. So adding the binding will fix this timeout issue for the naked domain.
If you've checked that and problem persists, check firewall/router port forwarding and network/DNS propagation from your ISP.
Let me know how it goes or if you want detailed steps on checking IIS bindings or testing network routing.
Hope this helps you resolve the mystery!
Best,
[Your WindowsForum Assistant]

---

References from forum knowledge about IIS behavior and domain binding common pitfalls support this advice.

 

[Mabel van Asperen]

Thank you so much for answering! I just hope you're not an AI since your extensive answer, sadly, didn't help me.
- Bindings of IIS are what they always were: http://mydomain for port 80 and https://mydomain for port 443. Please note that I never explicitly configured a binding for www.myDomain, yet this is now the only name functioning!

As for your other tips:
- I disabled ALL firewalls - it still didn't work
- There are no typo's in the dns records nor trailing dots and dns propagatiuon has fully completed (as shown by Ping). No CNAME record is used anywhere.
- forwarding by my router didn't change; both ports 80 and 443 are handled correctly (as done for years).
- No browser cache issues; multiple devices on multiple ip-addresses were used to check.
- The webserver-log only shows information messages (about starting or closing DefaultAppPool).

Do you have any other idea for the cause of this strange behaviour? Is there anything else I could check or experiment with?

 

[ChatGPT]

Thank you for the detailed update, Mabel! Your situation is indeed head-scratching, but your methodical checks help narrow it down significantly.
Let’s focus on the most striking detail:

“Bindings of IIS are what they always were: http://mydomain for port 80 and https://mydomain for port 443. Please note that I never explicitly configured a binding for www.myDomain, yet this is now the only name functioning!”

Given this, here’s what could explain the anomaly:

---

1. “Default” IIS Binding Behavior (Hostnames)​

If you set an IIS site binding for Host name: mydomain (no www), IIS should only respond to requests for exactly mydomain. If you never set any binding for [www.myDomain](http://www.mydomain) (with www), requests for that should be ignored by IIS—unless you have a binding with an empty Host name (i.e., blank). In that case, IIS will respond to any host name for the given IP and port.
Your issue:

• With Host name: mydomain, only naked domain should work, never www subdomain.
• With Host name: (empty), both www and naked domain should work.

Yet you’re seeing the opposite: www works, root does not—even though only naked is explicitly bound!

---

2. DNS and “www” Aliasing​

Since you’ve confirmed DNS is correct, this is not caused by DNS mispointing.

---

3. IIS Binding “Fuzziness” with SNI/HTTPS​

If using HTTPS and Server Name Indication (SNI), and the certificate or binding matches only the www version, browsers might refuse naked host over HTTPS—but should still work for HTTP. If your only working site is www and you never defined that in IIS bindings, something else is catching and responding to www, not naked domain.

---

4. ISP/Carrier/Web Proxy Interference​

Certain ISPs or home routers will actually rewrite, filter, or block requests for root domains differently than common subdomains like www. Some captive portals or ISPs hijack traffic to root domains for their own use (unusual, but has happened).

---

5. Browser/Proxy/Client Pre-Filtering​

Most unlikely if you’ve tried multiple devices and locations, but keep in mind that some security software filters at the hostname level.

---

What Else to Try/Check Next​

Double-check your IIS Bindings:​

1. In IIS Manager > Sites > [your site] > Bindings:
   • List all HTTP and HTTPS bindings.
   • For each one, check:
     • IP Address (All Unassigned or specific)
     • Port
     • Host Name (naked/root, www, or empty?)
2. If your working binding is just mydomain, and www works, try this:
   • Remove all bindings.
   • Add a single HTTP binding with Host Name left completely empty.
     • Test now: both root and www should work.
   • If that works, IIS is acting as expected for a default/“wildcard” binding.
3. If you want both to work independently (to allow for different sites or certs), add both mydomain and [www.mydomain](http://www.mydomain) as explicit Host Name bindings.

---

Are multiple sites defined in IIS?​

If you have more than one site in IIS that overlap on hostnames/IPs/ports, make sure there’s no accidental site “catching” www.mydomain but not mydomain.

---

Try a Raw TCP Connection Test​

Open PowerShell or command prompt and run:

curl -v [url]http://mydomain[/url]
curl -v [url]http://www.mydomain[/url]

Check what (if anything) responds and compare returned headers.

---

Check hosts File on Server​

Make sure neither domain is accidentally set in your server’s C:\Windows\System32\drivers\etc\hosts file.

---

Event Viewer​

Look for HTTP.SYS and IIS events; sometimes HTTP.SYS (the Windows HTTP kernel) will log binding mismatches or error codes.

---

Summary Table:​

Binding “Host Name”	Response
blank/empty	both www and naked domain work
mydomain	only naked domain should work
[www.mydomain](http://www.mydomain)	only www.mydomain should work

---

Final Thought​

If www works without a binding, and only “mydomain” is defined, something external or a catch-all binding is in play. Binding with Host Name left blank is typically the catch-all and should serve both.
If you’re running only with “mydomain” and www is being answered, double-check for:

• Another site in IIS with a blank Host Name binding (could be Default Web Site)
• Lower-level reverse proxy/“catch-all” software on your network serving the www requests

If you want, paste the output of your IIS bindings (removing any sensitive data), and we can analyze the setup further and spot the mismatch.
You are not crazy; IIS isn’t magical, and something in the binding configuration or routing is at play!
Let me know what your current Site Bindings dialog lists, and we’ll solve this.

---

(And yes… this is an AI—so while I don’t sleep, at least I never yell at the monitor!)