Can't validate "www" for domains

Why are they serving a redirect to http://mclnfriends.com? Why is your server not reachable?

Not sure. Can you share with me how you came up with that so I can get with namecheap and get it resolved. When I try to go to www.mlcnfriends.com I get a redirect to mlcnfriends.com

mlcnfriends.com is the correct URL.

$ dig www.mlcnfriends.com

; <<>> DiG 9.9.5-9+deb8u4-Debian <<>> www.mlcnfriends.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16649
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.mlcnfriends.com.           IN      A

;; ANSWER SECTION:
www.mlcnfriends.com.    1271    IN      A       67.209.241.26
www.mlcnfriends.com.    1271    IN      A       192.64.119.108

;; AUTHORITY SECTION:
mlcnfriends.com.        1253    IN      NS      dns1.registrar-servers.com.
mlcnfriends.com.        1253    IN      NS      dns2.registrar-servers.com.

;; ADDITIONAL SECTION:
dns1.registrar-servers.com. 163745 IN   A       216.87.155.33
dns2.registrar-servers.com. 163745 IN   A       216.87.152.33

;; Query time: 8 msec
[...]

Then

$ printf 'GET / HTTP/1.0\r\nHost: www.mlcnfriends.com\r\n\r\n' | nc 192.64.119.108 80
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 14 Jan 2017 17:06:38 GMT
Content-Type: text/html
Connection: close
Content-Length: 154
Location: http://mclnfriends.com

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>

(note the typo in the Location header) and

$ printf 'GET / HTTP/1.0\r\nHost: www.mlcnfriends.com\r\n\r\n' | nc 67.209.241.26 80
(UNKNOWN) [67.209.241.26] 80 (http) : Connection timed out

These are the root causes.

67.209.241.26 is reachable from my end. But indeed, 192.64.119.108 is the culprit for the typo in the redirect.

Your nginx is searching for the file in /usr/local/etc/nginx/html according to the error log you just pasted. It doesn't think that up by its own :wink: Or you typed the log entry wrongly?

This server’s firewall is configured weirdly it seems. Or its routing is wrong.

# traceroute -I -f 6 67.209.241.26
traceroute to 67.209.241.26 (67.209.241.26), 30 hops max, 60 byte packets
 6  80.157.130.154 (80.157.130.154)  117.834 ms  117.781 ms  117.772 ms
 7  cer-edge-17.inet.qwest.net (67.14.8.86)  131.284 ms  131.274 ms  131.826 ms
 8  63.145.140.122 (63.145.140.122)  143.641 ms  143.990 ms  143.979 ms
 9  a67-209-250-129.cust.mi.winntel.net (67.209.250.129)  139.929 ms  140.131 ms  140.297 ms
10  67-209-241-26.dhcp.portland.mi.freedomnet.com (67.209.241.26)  140.855 ms  140.846 ms  140.846 ms
11  67-209-241-26.dhcp.portland.mi.freedomnet.com (67.209.241.26)  164.602 ms  155.453 ms  158.004 ms
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  *^C

A traceroute shouldn’t look like that.

I bet anything it was from the automatic park on www that they put in place when I registered the domain. I'll get with them and see if I can get it resolved. Thanks so much for your help with this.

Again, I don't know how since it's not referenced on any of the config files. The config files are posted and you can see what's in them.

What part looks odd?

The destination host should be the last one that answers. It shouldn’t answer twice and there shouldn’t be hops beyond it.

Depends. Many routers/firewalls block traceroutes (mostly ICMP), but don't block plain HTTP(S) packages through port 80/443 et cetera.

The traceroute looks the same from my end and the webserver is reachable.[quote="Jailer, post:26, topic:25672"]
Again, I don't know how since it's not referenced on any of the config files. The config files are posted and you can see what's in them.
[/quote]

Did you copy/paste the error log or type it?

The traceroute still wouldn't look like that.

Onus probandi :slight_smile:

There, satisfied?:

osiris@desktop ~ $ sudo traceroute -T -p 80 67.209.241.26
traceroute to 67.209.241.26 (67.209.241.26), 30 hops max, 60 byte packets
 1  speedtouch (192.168.1.254)  0.519 ms  0.662 ms  0.804 ms
 2  lo0.dr13.d12.xs4all.net (194.109.5.212)  8.683 ms  8.891 ms  9.279 ms
 3  0.ae23.xr4.1d12.xs4all.net (194.109.7.17)  9.276 ms 0.ae23.xr3.3d12.xs4all.net (194.109.7.53)  9.271 ms 0.ae23.xr4.1d12.xs4all.net (194.109.7.17)  10.454 ms
 4  0.ae5.xr1.sara.xs4all.net (194.109.5.2)  10.450 ms  10.445 ms 0.ae4.xr1.sara.xs4all.net (194.109.5.6)  10.774 ms
 5  30gigabitethernet1-3.core1.ams1.he.net (80.249.209.150)  35.763 ms  35.775 ms  36.061 ms
 6  100ge9-1.core1.lon2.he.net (72.52.92.213)  20.523 ms  30.160 ms  31.424 ms
 7  100ge1-1.core1.nyc4.he.net (72.52.92.166)  97.662 ms  93.584 ms  93.532 ms
 8  100ge5-1.core1.chi1.he.net (184.105.223.161)  100.448 ms  101.258 ms  104.555 ms
 9  216.66.76.146 (216.66.76.146)  115.074 ms  115.283 ms  117.003 ms
10  a67-209-250-129.cust.mi.winntel.net (67.209.250.129)  111.547 ms  111.697 ms  114.011 ms
11  67-209-241-26.dhcp.portland.mi.freedomnet.com (67.209.241.26)  116.251 ms  116.548 ms  115.470 ms
12  67-209-241-26.dhcp.portland.mi.freedomnet.com (67.209.241.26)  128.396 ms  130.206 ms  130.535 ms
13  67-209-241-26.dhcp.portland.mi.freedomnet.com (67.209.241.26)  148.066 ms  144.593 ms  147.679 ms
14  67-209-241-26.dhcp.portland.mi.freedomnet.com (67.209.241.26)  144.304 ms  134.016 ms  137.344 ms
osiris@desktop ~ $ 

I agree, it does look strange, but it doesn't have anything to do with the non-reachability on your end, as demostrated above.

Copied and pasted a snippet. The entire error from the last dry run I tried is below

2017/01/14 10:28:01 [error] 36698#102176: *2 open() "/usr/local/etc/nginx/html/.well-known/acme-challenge/ULP8x7iZI-vStfFCooMZGGqOjmAniOz0P9cyCLx5a_s" failed (2: No such file or directory), client: 66.133.109.36, server: www.mlcnfriends.com, request: "GET /.well-known/acme-challenge/ULP8x7iZI-vStfFCooMZGGqOjmAniOz0P9cyCLx5a_s HTTP/1.1", host: "www.mlcnfriends.com", referrer: "http://www.mlcnfriends.com/.well-known/acme-challenge/ULP8x7iZI-vStfFCooMZGGqOjmAniOz0P9cyCLx5a_s"

The traceroute would stop somewhere in front or at the host. Certainly the host wouldn’t answer twice and then still have hops beyond itself.

Is your webroot /usr/local/www/nginx a symlink perhaps? I.e., try ls -ld /usr/local/www/nginx Because that would explain the log entry. (But not why it isn't working.)

@Jailer, can you show netstat -rn output on the host? Are these jails? Can you show the packet filter config?

Sure it does, or is your IP address the same as mine? :slight_smile: There is definitely something wrong on the routing level (as also evidenced by the very first post in this entire thread).

The error in the first post is because of the typo in the redirect at namecheap.

Futher, my traceroute through TCP port 80 ends perfectly without timeouts (although it does give 4 hops of the last hop, indeed, but it works) and my telnet to port 80 works too.. So I'm quite convinced this is not a global routing or firewall issue.

It works for your connection. That doesn’t mean it works for everyone.

In post 3 @Jailer got a 404 file not found error from Let’s Encrypt… Which means there was a successful connection on OSI layer 4.

Negative, it's a directory.

drwxr-xr-x 3 root wheel 4 Jan 7 13:05 /usr/local/www/nginx

Yes these hosts are in jails. Requested output below.

Routing tables

Internet:
Destination        Gateway            Flags      Netif Expire
default            192.168.0.1        UGS     epair5b
127.0.0.1          link#1             UH          lo0
192.168.0.0/24     link#2             U       epair5b
192.168.0.225      link#2             UHS         lo0

Internet6:
Destination                       Gateway                       Flags      Netif Expire
::/96                             ::1                           UGRS        lo0
::1                               link#1                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%lo0/64                     link#1                        U           lo0
fe80::1%lo0                       link#1                        UHS         lo0
ff01::%lo0/32                     ::1                           U           lo0
ff02::/16                         ::1                           UGRS        lo0
ff02::%lo0/32                     ::1                           U           lo0

Maybe the client chose the other IP address this time. I have a host in .sk from where it works. I also have a host in .uk from where it doesn’t work.

Your methodology is flawed.