Score:0

Website on Ubuntu 20.04 will not show to public

cn flag

I'm facing a strange issue, at least to me, that I can't crack. My domain is fully propagated according to whatsmydns.net:

whatsmydns.net report

Yet dig won't give me an ip:

; <<>> DiG 9.16.1-Ubuntu <<>> defactocannabis.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5692 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;defactocannabis.com. IN A ;; Query time: 284 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Tue Mar 15 01:26:04 +04 2022 ;; MSG SIZE rcvd: 48

I checked with my registrar (Namecheap) and they told me everything is okay on their end.

netstat -taupen | grep LISTEN reports:

tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 114 36844 3300/redis-server tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 21112 686/systemd-resolve tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 24658 815/sshd: /usr/sbin tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 113 25942 884/mysqld
tcp6 0 0 ::1:6379 :::* LISTEN 114 36845 3300/redis-server 1 tcp6 0 0 :::80 :::* LISTEN 0 68578 8381/apache2
tcp6 0 0 :::22 :::* LISTEN 0 24670 815/sshd: /usr/sbin

So I can see the server is listening on port 80 for ipv6, but I can't see it mentioned for ipv4.

I've tried disabling both the cloud firewall and UFW (both are the same). This is UFW:

22/tcp ALLOW 5.226.139.148
25/tcp ALLOW 5.226.139.148
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
443/udp ALLOW Anywhere
53 ALLOW Anywhere
80/udp ALLOW Anywhere
3306 ALLOW Anywhere
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
443/udp (v6) ALLOW Anywhere (v6)
53 (v6) ALLOW Anywhere (v6)
80/udp (v6) ALLOW Anywhere (v6)
3306 (v6) ALLOW Anywhere (v6)

I honestly can't figure out what's wrong. If I go to the ip address (http://78.141.209.186/) it's working perfectly. My DNS propagated yesterday, but I still can't get dig to report the appropriate IP or my browsers (Chrome, Chromium, Firefox) to display the page.

Further Information: Earlier today I booted to my live usb and tried going to the website by domain name in firefox, and it worked. So I thought it must my OS (after about an hour of learning to flush DNS caches, etc). I reinstalled the OS. Now it still isn't working! I reset my router. No go. I tried four different VPN nodes. Nothing.

My website simply will not resolve using the domain name. Only the IP. I also tried changing the settings in WordPress from http://78.141.209.186 to http://defactocannabis.com. Only the IP works.

I would really appreciate assistance solving this problem because it is beyond my technical knowledge, and I don't know what to do anymore.

Note The other thing is when I type http://78.141.209.186 into Firefox, it automatically changes to my domain name and I get the error the website can't be found...

Score:1
cn flag

SERVFAIL means fatal DNS error, and can happen for DNSSEC related errors.

However a good troubleshooting tool like DNSViz, shows no problem with your DNS settings, see https://dnsviz.net/d/defactocannabis.com/Yi_Bhw/dnssec/

All 3 major public DNS resolvers have no issues resolving your name, see:

$ for x in 1 8 9 ; do echo $x ; dig @$x.$x.$x.$x defactocannabis.com. A +short ; done
1
78.141.209.186
8
78.141.209.186
9
78.141.209.186

Other web related checking tools have no issues either to load your website, see https://shotsherpa.com/adventure/622fc274a3a7405a1349a3b9

So your problem is really a local DNS configuration error somewhere. Your dig output shows 127.0.0.53 which is typically the IP address used by systemd-resolved DNS server so you will need to check its status and log. And do a local dig query using another nameserver and you will see things work.

PS: there is no DNS propagation, that never existed despite all bad documentation saying so. If you query authoritative nameservers the changes are visible immediately. As for recursive nameserver, they are bound by the TTL and the whole flow is not top down (which would have been a propagation) but only recursive nameservers fetching new data when the TTL expires.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.