These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for Website down but nothing manually changed? on the new forum.
Hi, website was up and running, however it won't load on browsers.
Nothing has been manually changed on virtualmin/webmin.
Some troubleshooting I have tried is:
[root@centos ~]# dig www.domain.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> www.domain.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36717 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.domain.com. IN A ;; Query time: 35 msec ;; SERVER: 192.168.1.180#53(192.168.1.180) ;; WHEN: Mon Sep 30 14:45:36 2013 ;; MSG SIZE rcvd: 37
I restarted BIND DNS Server in Webmin > System Information > Status > BIND DNS Server. I restarted Apache Webserver in Webmin > System Information > Status > Apache Webserver.
traceroute www.domain.com results: [root@centos ~]# traceroute www.domain.com
traceroute to www.domain.com (199.101.28.130), 30 hops max, 60 byte packets 1 Main (192.168.1.180) 0.524 ms 0.552 ms 0.315 ms 2 10.246.48.1 (10.246.48.1) 24.650 ms 42.307 ms 58.623 ms 3 58.160.48.33 (58.160.48.33) 74.874 ms 89.780 ms 105.362 ms 4 gi2-2.agg2.cha.bigpond.net.au (58.160.51.254) 124.925 ms 141.060 ms 157.845 ms 5 172.18.117.166 (172.18.117.166) 174.519 ms 187.406 ms 203.895 ms 6 172.18.117.173 (172.18.117.173) 220.967 ms 233.980 ms 259.976 ms 7 172.18.241.105 (172.18.241.105) 265.555 ms 32.886 ms 49.100 ms 8 bundle-ether10-woo10.brisbane.telstra.net (110.142.226.13) 47.359 ms 71.524 ms 86.439 ms 9 bundle-ether3.woo-core1.brisbane.telstra.net (203.50.11.52) 91.960 ms 116.026 ms 132.541 ms 10 bundle-ether11.chw-core2.sydney.telstra.net (203.50.11.70) 177.944 ms 178.130 ms 178.279 ms 11 bundle-ether1.oxf-gw2.sydney.telstra.net (203.50.6.90) 178.492 ms 180.418 ms 184.186 ms 12 203.50.13.194 (203.50.13.194) 186.632 ms 200.377 ms 200.452 ms 13 i-0-2-0-5.sydo-core02.bi.telstraglobal.net (202.84.223.42) 157.068 ms 32.514 ms 55.895 ms 14 i-0-2-0-1.1wlt-core01.bx.telstraglobal.net (202.84.249.50) 174.401 ms 184.108 ms 183.846 ms 15 i-0-4-0-2.eqla01.bi.telstraglobal.net (202.40.149.242) 227.959 ms 237.285 ms 238.283 ms 16 gblx-peer.eqla01.pr.telstraglobal.net (134.159.61.22) 207.327 ms 212.371 ms 212.558 ms 17 po3-20G.ar3.SJC2.gblx.net (67.16.141.62) 240.092 ms 240.291 ms 208.969 ms 18 NOMINUM.GigabitEthernet9-10.ar3.SJC2.gblx.net (64.215.27.74) 195.783 ms 195.673 ms 195.781 ms 19 199.101.29.225 (199.101.29.225) 213.383 ms 181.150 ms 186.897 ms 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *
ping www.domain.com results: [root@centos ~]# ping www.domain.com
PING www.domain.com (199.101.28.130) 56(84) bytes of data. 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=1 ttl=45 time=200 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=2 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=3 ttl=45 time=178 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=4 ttl=45 time=180 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=5 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=6 ttl=45 time=176 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=7 ttl=45 time=178 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=8 ttl=45 time=178 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=9 ttl=45 time=176 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=10 ttl=45 time=181 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=11 ttl=45 time=178 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=12 ttl=45 time=183 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=13 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=14 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=15 ttl=45 time=181 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=16 ttl=45 time=176 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=17 ttl=45 time=176 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=18 ttl=45 time=176 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=19 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=20 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=21 ttl=45 time=187 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=22 ttl=45 time=177 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=23 ttl=45 time=178 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=24 ttl=45 time=178 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=25 ttl=45 time=176 ms 64 bytes from www.bigpondsitehelp.com (199.101.28.130): icmp_seq=26 ttl=45 time=177 ms
http://www.intodns.com/domain.com
Parent Info Domain NS records Nameserver records returned by the parent servers are: ns2.domain.com. ['WAN IP'] [TTL=14400] ns1.domain.com. ['WAN IP'] [TTL=14400] v.au directed me to x.au which was kind enough to give us that information. NOTE: You also need to know that you have a country code second-level domain (ccSLD) that may require an extra NS lookup and may delay a little the visitors to your website! Warn TLD Parent Check WARNING: Looks like the parent servers do not have information for your TLD when asked. This is ok but can be confusing. Pass Your nameservers are listed Good. The parent server v.au has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers. Pass DNS Parent sent Glue Good. The parent nameserver sent GLUE, meaning he sent your nameservers as well as the IPs of your nameservers. Glue records are A records that are associated with NS records to provide "bootstrapping" information to the nameserver.(see RFC 1912 section 2.3) Pass Nameservers A records Good. Every nameserver listed has A records. This is a must if you want to be found. NS Info NS records from your nameservers NS records got from your nameservers listed at the parent NS are: Oups! I could not get any nameservers from your nameservers (the ones listed at the parent server). Please verify that they are not lame nameservers and are configured properly. Pass Recursive Queries Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone. Pass Same Glue Hmm,I do not consider this to be an error yet, since I did not detect any nameservers at your nameservers. Pass Glue for NS records OK. Your nameservers (the ones reported by the parent server) have no ideea who your nameservers are so this will be a pass since you already have a lot of errors! Error Mismatched NS records WARNING: One or more of your nameservers did not return any of your NS records. Error DNS servers responded ERROR: One or more of your nameservers did not respond: The ones that did not respond are: WAN IP. Pass Name of nameservers are valid OK. The nameservers reported by the parent send out nothing as shown above. I can't check nothing so it's a green! Error Multiple Nameservers ERROR: Looks like you have less than 2 nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me. Pass Nameservers are lame OK. All the nameservers listed at the parent servers answer authoritatively for your domain. Pass Missing nameservers reported by parent OK. All NS records are the same at the parent and at your nameservers. Error Missing nameservers reported by your nameservers You should already know that your NS records at your nameservers are missing, so here it is again: ns2.domain.com. ns1.domain.com. Pass Domain CNAMEs OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Pass NSs CNAME check OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present. Pass Different subnets OK. Looks like you have nameservers on different subnets! Pass IPs of nameservers are public Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like Pass DNS servers allow TCP connection OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default. Pass Different autonomous systems OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down. Pass Stealth NS records sent Ok. No stealth ns records are sent SOA Error SOA record No valid SOA record came back! MX Error MX Records Oh well, I did not detect any MX records so you probably don't have any and if you know you should have then they may be missing at your nameservers! WWW Error WWW A Record ERROR: I could not get any A records for www.domain.com! (I only do a cache request, if you recently added a WWW A record, it might not show up here.)
Sorry, your console output is nearly impossible to read this way. You should put it in
[code]
[/code] tags to preserve linebreaks and monospace font. Also please don't use placeholders for domains and IP addresses in question. This way we cannot do any tests of our own. If your domains and IPs are "top-secret", you can replace them with placeholders once your problem is solved.Then the usual questions. Please elaborate "won't load in browsers", what exactly happens? Does the hostname resolve? Can you telnet to the server on port 80? What's in the Apache error logs?
Thank you for the reply. Points noted.
Browser to www.sk8parks.org.au gives result: Hmm, www.sk8parks.org.au isn't loading right now.
The hostname does not resolve.
I cannot telnet to the server on port 80.
Apache logs: [root@centos virtualmin]# vim sk8parks.org.au_access_log-20130915.gz
[root@centos virtualmin]# vim sk8parks.org.au_access_log-20130922.gz
[root@centos virtualmin]# vim sk8parks.org.au_access_log-20130929.gz
[root@centos virtualmin]# vim sk8parks.org.au_error_log-20130915.gz
[root@centos virtualmin]# vim sk8parks.org.au_error_log-20130922.gz
[root@centos virtualmin]# vim sk8parks.org.au_error_log-20130929.gz
www.intodns.com gives the following results:
Deleted.
Your registrar has the IP 124.191.169.67 as glue for your nameservers, but that IP does not respond to DNS queries.
The usual, like before. Make sure the IP is correct, BIND is running on that server, no firewall is blocking UDP port 53, or routers correctly forward it, check syslog / BIND error log, etc. etc.
Hmm, the website was working with the current settings. Yes, it seems the IP address or DNS and BIND is the common issue.
I'm unclear as my registrar has the Host name as ns1.sk8parks.org.au and ns2.sk8parks.org.au which both point to the WAN IP.
So the Virtualmin server with the nameservers setup before handle DNS queries. I can't see any settings changed on Virtualmin or the registrar?
Sorry, can't say anything else besides check if the IP at your registrar is correct, if BIND is running and listening on port 53 UDP, and if the port is forwarded properly/not blocked by a firewall, and check the syslog/BIND error logs. For anything else I'd need to take a look at your system myself, which I know you don't want. ;)
On another note, the route to your nameserver IP has the most insane amount of hops I've ever seen when tracing a target host.
You might want to consider getting an actual rootserver at a hoster (possibly outside of Australia), instead of using your home IP; I'd not be surprised if port 53 packets to you are dropped somewhere along the way. Then you can debug your system all you want, your home connection is probably just not suitable for a server.
I done some more testing with www.intodns.com and the errors are:
Error Mismatched NS records WARNING: One or more of your nameservers did not return any of your NS records. Error DNS servers responded ERROR: One or more of your nameservers did not respond: The ones that did not respond are: 124.191.169.67
Error Multiple Nameservers ERROR: Looks like you have less than 2 nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me.
Error Missing nameservers reported by your nameservers You should already know that your NS records at your nameservers are missing, so here it is again:
ns2.sk8parks.org.au. ns1.sk8parks.org.au.
SOA Error SOA record No valid SOA record came back! MX Error MX Records Oh well, I did not detect any MX records so you probably don't have any and if you know you should have then they may be missing at your nameservers! WWW Error WWW A Record ERROR: I could not get any A records for www.sk8parks.org.au!
(I only do a cache request, if you recently added a WWW A record, it might not show up here.)
The Virtualmin BIND DNS Server is running, so any suggestions please?
The very same as before apparently: udp packets on port 53 don't reach your system. Can't say anything else that I haven't said already. Suggestion: use a hosted server instead of your home internet (which I assume you're using now) or ask your ISP if they block anything, since you insist that your own routing setup is correct. :)
I checked my Zone file and maybe it's not correct as these are the results.
I think this is the zone file which I found in etc/named.conf/, however it doesn't look like the right details:
My details:
Can you please put your text/shell listings in
[code]
[/code] tags, to preserve linebreaks and monospace font.Also, as per your post, IntoDNS reported a connectivity error:
Error: DNS servers responded: ERROR: One or more of your nameservers did not respond: The ones that did not respond are: 124.191.169.67
This implies that your server is not reachable on UDP port 53 from the outside. The test I just did confirms that.
It doesn't matter if your zone files are erroneous or not; as long as your server remains unreachable from the outside, your nameserver won't work. So, again, before you start fixing zone files, you need to make sure that your server is reachable from the outside on UDP port 53.
Here's a traceroute result:
You can see that your host is not even reachable via traces. So again, my advice would be to get a hosted server, and not use your home Internet connection, which apparently is not suitable for server purposes.
Thank you for the reply and clearing up the issue is port 53 before working on the Zone file.
The issue is curious as the website worked before and then with no changes on my end, it seems now port 53 is not receiving any packets.
I will do some further tests as if it worked before, then it does work. It seems to be a matter of understanding the network to locate the issue and resolving what the cause is.
Okay, trying IPv6, but Virtualmin doesn't seem to change format from IPv4 to IPv6. https://www.virtualmin.com/documentation/system/ipv6 says go to System Settings -> Virtualmin Configuration -> Use default IPv6 address for new virtual servers to allow IPv6, but I don't see the option on my Virtualmin 4.03.gpl GPL.