Website domain is dropping intermittently - cloud dns & godaddy as registrar

[na...@godamonggeeks.com]

I have been having issues for a few months, but have been too busy to really mess with it. This started after migrating from godaddy to AWS EC2, while still using GoDaddy DNS. My site will randomly drop,and when I try to hit the site, I just get an error_connection_reset in my browser, and I also get a LOT of pingdom errors, so I know it is not me. However, browsing to the IP works just fine. It happens at random times, dropping for maybe a minute at a time, sometimes happening for a period of an hour or a day.

I moved my DNS from GoDaddy to AWS Route 60, after that didnt fix it, I moved to Google Compute and built a new LAMP server AND moved my DNS to cloud dns. As soot as I got Apache installed and tested the site, the problem arose. Godaddy is my registrar with my nameservers pointing to Cloud DNS, I have just MX records for google apps Gmail, and A record and a www Cname. DNS tests all come back fine except for minor issues that would not affect performance.

It also happens when trying my A record http://GodamongGeeks.Com AND the Cname http://www.GodAmongGeeks.Com so it is not any individual record. Anyone have ANY idea wha could be causing this? IT HAS to be somewhere in GoDaddy, but they say it is all fine... I dont want to move my DNS back, because they insert so many default records right away that my site drops til I propogate twice.

[na...@godamonggeeks.com]

More info:


Pingdom Alerts Snippet:

PingdomAlert UP:
Godamonggeeks (www.godamonggeeks.com) is UP again at 10/01/2016 04:47:18AM, after 9m of downtime.
PingdomAlert UP:
Godamonggeeks (www.godamonggeeks.com) is UP again at 10/01/2016 04:57:18AM, after 9m of downtime.
PingdomAlert UP:
Godamonggeeks (www.godamonggeeks.com) is UP again at 10/01/2016 05:07:18AM, after 9m of downtime.
PingdomAlert UP:
Godamonggeeks (www.godamonggeeks.com) is UP again at 10/01/2016 05:17:18AM, after 9m of downtime.
PingdomAlert UP:
Godamonggeeks (www.godamonggeeks.com) is UP again at 10/01/2016 05:27:18AM, after 9m of downtime.

Compute Instance Details:

Welcome to Cloud Shell! Type "help" to get started.
nash@godamonggeeks-www:~$ gcloud compute instances describe gag-ubuntu-lamp1
For the following instances:
- [gag-ubuntu-lamp1]
choose a zone:
[1] asia-east1-a
[2] asia-east1-c
[3] asia-east1-b
[4] europe-west1-c
[5] europe-west1-d
[6] europe-west1-b
[7] us-central1-b
[8] us-central1-f
[9] us-central1-a
[10] us-central1-c
[11] us-east1-b
[12] us-east1-d
[13] us-east1-c
[14] us-west1-a
[15] us-west1-b
Please enter your numeric choice: 14
canIpForward: false
cpuPlatform: Intel Broadwell
creationTimestamp: '2016-10-03T12:41:47.384-07:00'
description: ''
disks:
- autoDelete: true
boot: true
deviceName: gag-ubuntu-lamp1
index: 0
interface: SCSI
kind: compute#attachedDisk
licenses:
- https://www.googleapis.com/compute/v1/projects/ubuntu-os-cloud/global/licenses/ubuntu-1604-xenial
mode: READ_WRITE
source: https://www.googleapis.com/compute/v1/projects/godamonggeeks-www/zones/us-west1-a/disks/gag-ubuntu-l...
type: PERSISTENT
id: '7063641369224350356'
kind: compute#instance
machineType: https://www.googleapis.com/compute/v1/projects/godamonggeeks-www/zones/us-west1-a/machineTypes/n1-st...
metadata:
fingerprint: pcv30XGYW4w=
items:
- key: serial-port-enable
value: 'true'
kind: compute#metadata
name: gag-ubuntu-lamp1
networkInterfaces:
- accessConfigs:
- kind: compute#accessConfig
name: External NAT
natIP: 104.199.127.191
type: ONE_TO_ONE_NAT
name: nic0
network: https://www.googleapis.com/compute/v1/projects/godamonggeeks-www/global/networks/default
networkIP: 10.138.0.3
subnetwork: https://www.googleapis.com/compute/v1/projects/godamonggeeks-www/regions/us-west1/subnetworks/defaul...
scheduling:
automaticRestart: true
onHostMaintenance: MIGRATE
preemptible: false
selfLink: https://www.googleapis.com/compute/v1/projects/godamonggeeks-www/zones/us-west1-a/instances/gag-ubun...
[11] us-east1-b
serviceAccounts:
- email: 9606158278...@developer.gserviceaccount.com
scopes:
- https://www.googleapis.com/auth/devstorage.read_only
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/servicecontrol
- https://www.googleapis.com/auth/service.management.readonly
status: RUNNING
tags:
fingerprint: 6smc4R4d39I=
items:
- http-server
- https-server
zone: https://www.googleapis.com/compute/v1/projects/godamonggeeks-www/zones/us-west1-a
nash@godamonggeeks-www:~$






ScreeenShots of DNS Server config, DNS Records & IP:

I cant get these to insert, so here are the links to the screenshots on my gcloud storage:

Current DNS Records:
https://storage.googleapis.com/godamonggeeks-www.appspot.com/images/dnsrecords.png

DNS Servers set at Godaddy:
https://storage.googleapis.com/godamonggeeks-www.appspot.com/images/dnsservers.png

External IP:
https://storage.googleapis.com/godamonggeeks-www.appspot.com/images/externalip.png

Browser error I get:
https://storage.googleapis.com/godamonggeeks-www.appspot.com/images/2016-10-04.png

[Richard Woodbury]

My feeling is that this is not a DNS issue. If it were, I'd expect your browser error to be something like ERR_NAME_NOT_RESOLVED or DNS_PROBE_FINISHED_NXDOMAIN. The error you're getting is ERR_CONNECTION_TIMED_OUT, which implies that the DNS resolution completed, but a TCP connection could not be made to the address (or perhaps the web server stopped responding after the connection was established, but that may be a different error).

BTW, while I don't believe this is causing you an issue, it is a bit awkward that you have a CNAME pointing to the apex (i.e., www.godamonggeeks.com points to godamonggeeks.com). This causes things like the SOA and NS records to be visible at www, which is not what you really want. That said, I wouldn't be surprised to find this to be common practice.

--
You received this message because you are subscribed to the Google Groups "cloud-dns-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cloud-dns-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[na...@godamonggeeks.com]

I am playing around with the www dns methods, and have since added a forward. I keep hearing conflicting views on using an A record vs a Cname for www.

Anyways, any idea what could be causing this? It is weird that the issue has followed me between clouds and dns servers. I have heard of issues being caused by the registrars servers encountering delays when delivering the NS entries, but I don't think that could cause it, especially not an intermittent issue like this. Yet, it isn't just me, which is causing me a headache. My site constantly appears to be down.

[Richard Woodbury]

The fact that the issue has followed you between clouds and DNS providers is a strong signal that the issue is with your webserver configuration, as that's the common thread.

I recommend doing some low-level diagnostics while the site appears to be down. E.g., while logged in via ssh to your webserver VM, watch the webserver logs for connections, check things like netstat to see that connections are coming in, maybe even do packet captures. You'll narrow down the problem space quickly.

On Wed, Oct 5, 2016 at 3:23 PM <na...@godamonggeeks.com> wrote:

I am playing around with the www dns methods, and have since added a forward. I keep hearing conflicting views on using an A record vs a Cname for www.

Anyways, any idea what could be causing this? It is weird that the issue has followed me between clouds and dns servers. I have heard of issues being caused by the registrars servers encountering delays when delivering the NS entries, but I don't think that could cause it, especially not an intermittent issue like this. Yet, it isn't just me, which is causing me a headache. My site constantly appears to be down.

[Alex Dupuy]

Richard Woodbury wrote:

BTW, while I don't believe this is causing you an issue, it is a bit awkward that you have a CNAME pointing to the apex (i.e., www.godamonggeeks.com points to godamonggeeks.com). This causes things like the SOA and NS records to be visible at www, which is not what you really want. That said, I wouldn't be surprised to find this to be common practice.

It's very much common practice, and although it makes SOA and NS records visible at www, given that the NS "delegation" is a self-delegation, every thing is pretty much legal (except for the fact that NXDOMAIN and NODATA in authoritative answers will have the zone apex name in their Authoritative section SOAs, which is such a corner case I doubt anything will care). For a DNSSEC-signed zone, having CNAME with a DS record present at the CNAME target might cause some weirdness, but I'm not sure.

Note that the inverse (having a CNAME from zone apex to www subdomain) is not okay, and definitely can cause problems, so it is better to be lenient with apex->www CNAME case since it is demonstrably less bad than the most likely alternative.

[na...@godamonggeeks.com]

Lest debate best practices after I figure this out... I would normally agree 100% that it is my network/server.. The problem with that, is that this issues started while I was running a server on Amazon Web Services EC2, and using Amazon Route 66 DNS. I have moved to Google Compute, made a NEW instance, installed a blank Ubuntu 16.04 server and set-up a very basic LAMP. I then moved my DNS servers to Google Cloud DNS.

So, EVERYTHING is new, the only thing that has not changed, is Godaddy being my registrar. That is why I am looking in that direction. I have even beet trying the site from different physical locations and different devices.... This is why I have a big headache and tuned here :)

[Richard Woodbury]

I really don't think it is GoDaddy. Once the NS records are published in .com, it is very unlikely that GoDaddy will change them without an action on your part. If you want to eliminate the registrar as a cause, you could transfer to another registrar (Google Domains, perhaps). Note also that GoDaddy doesn't serve any DNS when it is being used only as a registrar; everything in .com is served by Verisign, regardless of which registrar was used to register it.

Here's an idea: Can you configure Pingdom to test the web server via IP address instead of DNS name? I don't mean just to ping it, but to do an HTTP GET with an IP address in the URL. Let it run for a while (a day or two), and if you still see failures, you can eliminate DNS as your problem.

On Wed, Oct 5, 2016 at 4:51 PM <na...@godamonggeeks.com> wrote:

Lest debate best practices after I figure this out... I would normally agree 100% that it is my network/server.. The problem with that, is that this issues started while I was running a server on Amazon Web Services EC2, and using Amazon Route 66 DNS. I have moved to Google Compute, made a NEW instance, installed a blank Ubuntu 16.04 server and set-up a very basic LAMP. I then moved my DNS servers to Google Cloud DNS.

So, EVERYTHING is new, the only thing that has not changed, is Godaddy being my registrar. That is why I am looking in that direction. I have even beet trying the site from different physical locations and different devices.... This is why I have a big headache and tuned here :)

[na...@godamonggeeks.com]

> Here's an idea: Can you configure Pingdom to test the web server via IP address instead of DNS name?

That is a very good idea, and if pingdom can't do it, I can find something else to. Yeah, I didnt see how godaddy could be the cause, but at the same time, I am not extremely familiar with the role of the registrar, and I doubted they were resolving name servers on every request.

The timing is weird, like how it happens at random times. Before I had a www cname or www forward in my dns, both www and the naked domain would have issue, but at different times, so I might get an error on www. but be able to hit the naked domain with no prob, and vice versa, that no longer happens thanks to the forward.

If anyone else sees it on my domain, would be nice to hear about, I am going to try some more monitoring. When I do ping the domain during the issue, I got a can't find host error. Also, earlier it happened while I was updating some settings, and my SSH connection never even hiccuped, though I was connected via the gcloud shell to the instance name, not the domain or IP, but it shows it has to be DNS related somewhere.

Thanks for the input so far.It is just VERY annoying. I encoded some 2 hour long video that I am going to try streaming in an HTML5-friendly format next time I see the issue, to see if it affects a stream, or only individual requests.