When I visit anythinghere.mysite.tld I get a DNS error. However, if you observe the behaviour of anythinghere.google.com and anythinghere.example.com you'll see there's no DNS error.

Note: doesnotexist.mysite.tld, random.mysite.tld and so on don't exist; all non-existing subdomains seem to be affected. What could be the reason for getting a DNS error in this situation?

Note 2: I'm using GitHub Pages with CloudFlare.

Update: If I clear my browser cache the DNS error doesn't happen. I see the exact same behaviour at random.lsquo.com as I see at random.google.com. That's good as it's exactly what I want. However, when I then visit lsquo.com again and then re-visit random.lsquo.com I see the DNS error again.

  • 2
    With DNS problems you really need to tell us the domain names if you want effective advice. – Tim May 10 '17 at 18:58
  • 3
    I'm voting to close this question as off-topic because all the critical information is censored. – ceejayoz May 10 '17 at 18:58
  • 1
    I'm not sure I understand what you are trying to achieve. Neither of anythinghere.google.com or anythinghere.example.com resolve, rather produce DNS errors. – Håkan Lindqvist May 10 '17 at 19:34
  • 4
    @henrywright Looks like your ISP is hijacking NXDOMAIN. Not good. – ceejayoz May 10 '17 at 19:56
  • 1
    @HåkanLindqvist " It does it for both. But your strict-transport-security including subdomains ensures that the browser will only do HTTPS under your domain, which their hijack nonsense can't support." - Could you explain this some more to help me understand? Perhaps in an answer. I'd appreciate the info :) – henrywright May 10 '17 at 20:12

First of all, it's normal to get a DNS error in all the mentioned examples (none of them resolve, neither random.google.com nor random.lsquo.com).

However, looking at your screenshots it's important to note that you do not in fact get a DNS error for random.lsquo.com, you get "Connection timed out".

It appears that your configured DNS server (probably provided by your ISP) does NXDOMAIN hijacking, where they make names that do not resolve, ie status NXDOMAIN, resolve to some page that generates revenue for them.

What changes the behavior after visiting your site is that you use HSTS and say that the policy also applies to subdomains.
Ie, includeSubDomains in Strict-Transport-Security: max-age=15552000; includeSubDomains; preload

The browser is tricked by the NXDOMAIN hijack in your case as well, but as the servers hosting the NXDOMAIN-hijack site do not do HTTPS (and if it would, it wouldn't have a valid certificate for your domain anyway, so there would be no point even trying), the browser fails to connect.

All in all, your domain fares best out of the mentioned examples thanks to your HSTS policy. Good!

|improve this answer|||||

In order to achieve this, you should have a Wildcard Record for your domain. Currently you don't have

*.lsquo.com.   IN   A
*.lsquo.com.   IN   A
*.lsquo.com.   IN   AAAA    2400:cb00:2048:1:0:0:681b:b030  
*.lsquo.com.   IN   AAAA    2400:cb00:2048:1:0:0:681b:b130

where the IP addresses match your lsquo.com..

What I can't understand is why you got this working once and how you got it working with Google, that doesn't seem to have any wildcard records, either.

What's good is that you have HSTS configured and your sertificate has wildcard *.lsquo.com. This means you have everything else in shape for your desired state. In many cases these would become the next problem.

Hopefully your webserver doesn't have a catch-all virtualhost, but uses redirects to a canonical hostname for your site instead.

|improve this answer|||||
  • I don't think this is what they are talking about, rather some variation on the "Use a web service to help resolve navigation errors" setting in the browser. – Håkan Lindqvist May 10 '17 at 19:55
  • 1
    OP likely didn't get anything "working with Google". Looks like an ISP-injected NXDOMAIN page. – ceejayoz May 10 '17 at 19:56
  • 1
    (For one thing, Google does not have any wildcard record, and if they did it wouldn't go to a Yahoo search page like in their screenshot) – Håkan Lindqvist May 10 '17 at 19:56
  • 1
    @ceejayoz Yes, that's probably the right interpretation! That fits with how strict-transport-security causes the NXDOMAIN hijack to break – Håkan Lindqvist May 10 '17 at 19:58
  • 1
    So ISP broke how Google should behave and OP's sites HSTS header corrected ISP's bad desicion. Nice. – Esa Jokinen May 10 '17 at 19:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.