Google Cloud DNS intermittently dropping - google-cloud-dns

Situation:
Had registered domain via G Suite and domain synthetic records set up for gmail under another (Google) account.
Transferred the domain to a different (Google) account - gmail still working fine.
Enabled Google Cloud services for the account.
Set up a Compute Engine with fixed IP address.
Set up new Zone for the domain and Cloud DNS settings.
Reset the domain DNS to the Cloud DNS servers
Create MX records according to instructions to reinstate gmail
Created A record for root domain
Created CNAME record for WWW subdomain
At this point, gmail seems to be working fine.
However, resolution for the root domain and subdomain is intermittent - it will be up for a few minutes, then drop for a few minutes.
When its alive, I can ping the root domain. I can't ping the www subdomain at all.
The domain is 'lifetreelaw.com'
Here are the dig outputs for each:
lifetreelaw.com:
; <<>> DiG 9.11.4-3ubuntu5.3-Ubuntu <<>> lifetreelaw.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25514
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;lifetreelaw.com. IN A
;; ANSWER SECTION:
lifetreelaw.com. 325 IN A 34.66.70.41
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri May 10 13:33:51 MDT 2019
;; MSG SIZE rcvd: 60
www.lifetreelaw.com:
; <<>> DiG 9.11.4-3ubuntu5.3-Ubuntu <<>> www.lifetreelaw.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36100
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.lifetreelaw.com. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri May 10 13:33:40 MDT 2019
;; MSG SIZE rcvd: 48
For the www subroute, dig is showing an 'A' record, not the CNAME record. I haven't set that -- is there something in the G Suite/gmail setup that would have set that? That is hanging around?
Followup
I removed the www CNAME record. This is the dig output, now:
; <<>> DiG 9.11.4-3ubuntu5.3-Ubuntu <<>> www.lifetree.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60309
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;www.lifetree.com. IN A
;; ANSWER SECTION:
www.lifetree.com. 4160 IN A 208.91.197.128
;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri May 10 13:50:14 MDT 2019
;; MSG SIZE rcvd: 61
It's still returning an A record, and resolving to a different IP.
Followup 2
Ok, after a period of time, the 'www' sub is not returning an 'A' record, anymore. But it's not returning a 'CNAME' record, either, even though I have it set.
Maybe I just need to wait it out.

Ok, waiting it out was part of the answer -- I'm just not used to a DNS name change taking so long to propagate and settle down.
The other part of the answer seemed to be flushing the DNS cache at this site:
https://developers.google.com/speed/public-dns/cache
And everything seemed to straighten out.

Related

Unable to resolve DNS for server after setting up a domain using Cloud DNS

I followed the steps in the tutorial:
https://cloud.google.com/dns/docs/tutorials/create-domain-tutorial
However when I get to the verify my setup, I don't see my servers IP, instead I see this:
$ dig -t NS dandyrobot.com.
; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> -t NS dandyrobot.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56042
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;dandyrobot.com. IN NS
;; Query time: 2339 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Tue Feb 07 11:00:42 EST 2023
;; MSG SIZE rcvd: 43
Are there any additional steps I can take to narrow down what the problem is?
Based on our conversation what seems to be the problem is that the configuration of custom nameserver under Google Domains. Then we use this link as a guidance to resolve this concern.

coredns doesnt give IP but just name

By running a dig command for a service in my kubernetes cluster, coredns just gives service name but not the IP. Does anyone know why this is happening?
This is related with how dig utility and DNS work.
Note that when you run:
dig <your-service-name>
you're asking your CoreDNS literally about this particular string and simple service name isn't even a valid domain name. Just take a look at the following example:
root#python-client:/# dig my-release-mysql
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27445
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;my-release-mysql. IN A
;; AUTHORITY SECTION:
. 86399 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021012500 1800 900 604800 86400
;; Query time: 19 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 16:22:12 UTC 2021
;; MSG SIZE rcvd: 120
As you can see it doesn't even contain "ANSWER" section (ANSWER: 0) and if you take a closer look at the "QUESTION" section:
;; QUESTION SECTION:
;my-release-mysql. IN A
you'll notice that dig asks CoreDNS for A record for my-release-mysql., which, as I already mentioned, isn't even a valid domain name.
Note that CoreDNS doesn't keep any records for my-release-mysql. so when you ask it about such "domain", it doesn't know anything about it.
If you ask instead for A record for a valid fully quallified domain name (FQDN), you'll get the expected response:
root#python-client:/# dig my-release-mysql.default.svc.cluster.local
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A
;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87
;; Query time: 0 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 15:59:55 UTC 2021
;; MSG SIZE rcvd: 76
Again, take a closer look at both "QUESTION" and "ANSWER" sections:
;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A
;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87
As you can see, when we ask CoreDNS in QUESTION SECTION for an A record for my-release-mysql.default.svc.cluster.local. which happens to be a valid FQDN (unlike my-release-mysql.) that this DNS server keeps records for, we get correct response in our ANSWER SECTION.
Note that dig utility doesn't use entries in your /etc/resolv.conf which may look as follows:
root#python-client:/# cat /etc/resolv.conf
nameserver 10.3.240.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
but instead, it queries the DNS server about the raw string my-release-mysql..
Tools like host or nslookup, unlike dig, leverage the content of /etc/resolv.conf when doing DNS lookup. So instead of asking CoreDNS about raw my-release-mysql, default.svc.cluster.local suffix is added and such query is sent to CoreDNS e.g.:
root#python-client:/# host my-release-mysql
my-release-mysql.default.svc.cluster.local has address 10.3.244.87
Note, that although we give my-release-mysql as an argument for our host command, it matches it with the first entry in the search section of our /etc/resolv.conf file, which happens to be default.svc.cluster.local and queries the DNS server not about my-release-mysql but about a fully quallified domain name my-release-mysql.default.svc.cluster.local for which it keeps records.
Same thing with nslookup tool:
root#python-client:/# nslookup my-release-mysql
Server: 10.3.240.10
Address: 10.3.240.10#53
Name: my-release-mysql.default.svc.cluster.local
Address: 10.3.244.87

Problems setting up a mail server in a EC2 instance

I'm trying to setup my own mail server in an EC2 instance on AWS. I've installed the following image:
https://aws.amazon.com/marketplace/pp/B00K600RWK?ref=cns_srchrow
This image contains Webuzo: 2.2.9 + SquirrelMail:1.4.22. I followed all installation steps and the server is up and running ok. But whenever I try to login into an email account on SquirrelMail I get the following message:
"ERROR
Error connecting to IMAP server: ofaroldigital.com.br.
0 : php_network_getaddresses: getaddrinfo failed: No address associated with hostname"
Dig output:
$ dig ofaroldigital.com.br
; <<>> DiG 9.8.3-P1 <<>> ofaroldigital.com.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9193
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ofaroldigital.com.br. IN A
;; AUTHORITY SECTION:
ofaroldigital.com.br. 173 IN SOA ns-1959.awsdns-52.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 24 msec
;; SERVER: 212.58.251.198#53(212.58.251.198)
;; WHEN: Tue Feb 2 10:58:37 2016
;; MSG SIZE rcvd: 125
I believe my route53 was configured correctly. What am I missing?
Thanks!
While ofaroldigital.com.br isn't resolving to anything, www.ofaroldigital.com.br is:
$ dig www.ofaroldigital.com.br +short
54.233.84.251
Have you made sure that you've added an A record for the Apex domain, that is to say, without the 'www' or any other subdomain?

Github Pages and Godaddy - CNAME error

I'm trying to use my Godaddy domain with github pages.
At this moment I've added the CNAME.md file with davidcafor.me
Created a A record to 192.30.252.153 and a CNAME www record to davidcafor.github.io.
But the problem is that davidcafor.me doesn't works.
What I'm doing wrong?
Your DNS records are correct:
; <<>> DiG 9.8.3-P1 <<>> a davidcafor.me
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31777
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;davidcafor.me. IN A
;; ANSWER SECTION:
davidcafor.me. 3600 IN A 192.30.252.153
The issue is that github.io is not configured to respond to that SNI. You will need to check with your settings in Github to make sure that domain is properly registered.
I believe the file needs to be named just CNAME, not CNAME.md. Or was it different in 2015?

Google Cloud DNS New zone

I create new zone to Google Cloud DNS, change domain registrants NS records to pointing ns-cloud-b1.googledomains.com, dig is showing correct information from authoritative NS but records doesn't appears on public DNS, is other configuration needed? or i must wait?
dig mydomain.com #ns-cloud-b4.googledomains.com
; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> mydomain.com #ns-cloud-b4.googledomains.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12022
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
mydomain.com. IN A
;; ANSWER SECTION:
mydomain.com 300 IN A x.x.x.x
;; Query time: 176 msec
;; SERVER: 216.239.38.107#53(216.239.38.107)
;; WHEN: Thu Apr 23 21:49:38 2015
;; MSG SIZE rcvd: 40
You need to wait for the information to propagate throughout the Domain Name System. This depends on the time-to-live setting of each RRset. If you just created the zone and switched the nameservers in the registrar, you need to wait for the TTL of the nameserver records to expire - they are just records in the parent zone.
dig +trace mydomain.com should help to ensure that everything is set up properly.