I'm trying to set up DNS receiving and tracking records for Mailgun. The DNS sending records were verified and work fine, but for some reason the receiving records and tracking records don't get verified.
The domain I'm using is mg.optimizeprice.com and the DNS provider I'm using is Dynadot. There are two mx records that it wants me to set up. I took screenshots of the Mailgun DNS records page as well as the Dynadot DNS records page as I have them set up right now. What do I need to change to get this to work?
Also, here is the output of dig optimizeprice.com mx:
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> optimizeprice.com mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8708
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;optimizeprice.com. IN MX
;; ANSWER SECTION:
optimizeprice.com. 10800 IN CNAME curved-aardvark-xbc5jxmn5ja3pdaq403yoxab.herokudns.com.
;; AUTHORITY SECTION:
herokudns.com. 10 IN SOA dns1.p05.nsone.net. hostmaster.nsone.net. 1563353642 600 900 1209600 10
;; Query time: 41 msec
;; SERVER: 75.75.75.75#53(75.75.75.75)
;; WHEN: Wed Jul 17 01:55:08 PDT 2019
;; MSG SIZE rcvd: 176
Related
We are doing API calls to Docusign, which fail occasionally with "getaddrinfo: Name or service not known" errors. Investigating further, we see that when we connect, name resolution fails sometimes, but only from our West datacenter location. Seems the GLB DNS for the US West can take a very long time to resolve, causing DNS client timeouts when it takes >10s to look up the address.
$ dig #1.1.1.1 www.docusign.net
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> #1.1.1.1 www.docusign.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49468
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.docusign.net. IN A
;; ANSWER SECTION:
www.docusign.net. 22 IN CNAME www-geo.docusign.net.akadns.net.
www-geo.docusign.net.akadns.net. 22 IN CNAME www-west.docusign.net.akadns.net.
www-west.docusign.net.akadns.net. 22 IN A 162.248.184.27
;; Query time: 1 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Oct 04 13:16:43 EDT 2018
;; MSG SIZE rcvd: 126
Above is a good result, which took 1msec (cached)
$ dig #1.1.1.1 www.docusign.net
; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> #1.1.1.1 www.docusign.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21193
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;www.docusign.net. IN A
;; ANSWER SECTION:
www.docusign.net. 6 IN CNAME www-geo.docusign.net.akadns.net.
www-geo.docusign.net.akadns.net. 6 IN CNAME www-west.docusign.net.akadns.net.
www-west.docusign.net.akadns.net. 6 IN A 162.248.184.27
;; Query time: 2725 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Oct 04 13:21:29 EDT 2018
;; MSG SIZE rcvd: 126
This one is worse, as it took nearly 3s. During testing we've seen this go over 12s which will time out a lot of DNS clients and requesting apps.
Since the TTL is set to 30s, that means that every 30 seconds we have a chance at getting a timeout, our app generating errors, then a DNS success results in resumption of service. Unfortunately, this shows up as an error to our customers in our app.
We're able to work around this using hacks, but am curious if anyone else is seeing this, and how you've worked around it. Also, it might be good for people at docusign/akamai to look into why the performance of the www-west.docusign.net.akadns.net record is so bad.
I would like to enable SSL for my domain assigned to the wordpress in Azure.
My domain is created in Freenom.
To finish the process I need to manually verify the domain from Azure:
Azure Domain Verification
Then I created TXT record in my domain in Freenom:
Freenom provider settings
But the TXT record is not created:
$ dig nemoz.ml TXT
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> nemoz.ml TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29489
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0005 , udp: 4096
;; QUESTION SECTION:
;nemoz.ml. IN TXT
;; ANSWER SECTION:
nemoz.ml. 5 IN CNAME nemoz.azurewebsites.net.
nemoz.azurewebsites.net. 5 IN CNAME waws-prod-am2-203.sip.azurewebsites.windows.net.
waws-prod-am2-203.sip.azurewebsites.windows.net. 5 IN CNAME waws-prod-am2-203.cloudapp.net.
;; AUTHORITY SECTION:
cloudapp.net. 5 IN SOA prd1.azuredns-cloud.net. msnhst.microsoft.com.cloudapp.net. 2110897293 900 300 604800 60
;; Query time: 299 msec
;; SERVER: 192.168.47.2#53(192.168.47.2)
;; WHEN: Tue Oct 02 16:56:54 EDT 2018
;; MSG SIZE rcvd: 250
And I am not able to verify the domain from Azure. I tried many configurations in Freenom, using networking tools, and searched many web pages. And nothing working.
Can you please help me find the problem?
It works!
I removed CNAMEs from Freenom and now I get TXT record:
$ dig nemoz.ml TXT
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> nemoz.ml TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26447
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; MBZ: 0005 , udp: 4000
;; QUESTION SECTION:
;nemoz.ml. IN TXT
;; ANSWER SECTION:
nemoz.ml. 5 IN TXT "phkg1hlljofbujbrfvl8pe8l62"
nemoz.ml. 5 IN TXT "nemoz.azurewebsites.net"
;; Query time: 1677 msec
;; SERVER: 192.168.47.2#53(192.168.47.2)
;; WHEN: Wed Oct 03 03:33:42 EDT 2018
;; MSG SIZE rcvd: 112
Also in Azure the domain verification is successful. Thanks a lot.
But the question is why is that? Why CNAME record prevents TXT record in domain?
Make sure you type the correct TXT record format in your domain DNS zone. named # with a valid value ph*********62in Freenom provider. And wait a few minuies for DNS propagation.
Here is an example in Azure DNS.
In Freenom replace 1examplevalue1 with the token ph*********62.
One possible problem can be that you have two TXT records with the same value.
For some reason it causes a conflict and records won't take effect.
While doing the DNS query through dig utility, sometimes i got Additional records in the results while sometimes not. This is very much normal.
But today i saw something interesting in the output of the dig. While querying for fb.com domain, i got some additional records in the response.
Interesting part is the information displayed along with flags.
There dig utility informs that there are ADDITIONAL: 5 (five additional records) while in the actual output section, it displays only 4 additional responses.
This is not specific to fb.com domain only but i am also getting similar things (mismatch in Additional Section) in other domains too.
`[root#Kansal~]# dig fb.com
; <<>> DiG 9.10.3-P3 <<>> fb.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34411
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;fb.com. IN A
;; ANSWER SECTION:
fb.com. 221 IN A 31.13.74.36
;; AUTHORITY SECTION:
fb.com. 735 IN NS b.ns.facebook.com.
fb.com. 735 IN NS a.ns.facebook.com.
;; ADDITIONAL SECTION:
a.ns.facebook.com. 3485 IN A 69.171.239.12
a.ns.facebook.com. 3485 IN AAAA 2a03:2880:fffe:c:face:b00c:0:35
b.ns.facebook.com. 3485 IN A 69.171.255.12
b.ns.facebook.com. 3485 IN AAAA 2a03:2880:ffff:c:face:b00c:0:35
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 20 15:24:59 IST 2016
;; MSG SIZE rcvd: 183
[root#Kansal~]# `
Bind version is 9.10.3
Please explain what i am missing here ?
The fifth RR in the Additional section is the OPT pseudo-RR. Its information is displayed under the OPT PSEUDOSECTION header in your example, rather than among the other RRs, since it's special. You can read all about it in RFC 2671.
As part of a project I've written a very simplistic DNS server whose only purpose is to resolve queries for the zone it serves, and to store the IP addresses of the server that made the query.
I've noticed that if I use dig, my DNS server gets queried multiple times - sometimes from the same IP address. Why does this happen? Is it due to the unreliable nature of UDP?
For example, here's a dig reply I made:
C:\Data>dig xyz.dns.example.com
; <<>> DiG 9.10.4-P2 <<>> xyz.dns.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2539
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xyz.dns.example.com. IN A
;; ANSWER SECTION:
xyz.dns.example.com. 12321 IN A 50.16.166.175
;; Query time: 224 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Aug 11 15:07:42 Eastern Daylight Time 2016
;; MSG SIZE rcvd: 77
In this example, the zone file for example.com has an NS record for dns.example.com which is where my simplistic DNS server runs. Fror this one query, my server was called 4 times from 2 different IP addresses.
I also noticed that I'm supposedly returning an "Additional" record, but the data I return in bytes 10 and 11 are clearly 0. Could this be causing a problem?
Try dig's +trace option:
dig example.com +trace
When I run the following dig command on www.google.com with the +nssearch option I get no results:
mac$ dig www.google.com +nssearch
mac$
Can someone explain why no data is returned here? The +nssearch option reads the SOA of all the authoritative name servers I believe. Does this mean there are no authoritative name servers? How is that possible? The domain www.google.com obviously works so I was expecting some sort of result.
; <<>> DiG 9.9.5-3ubuntu0.2-Ubuntu <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40522
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 20 IN A 74.125.196.106
www.google.com. 20 IN A 74.125.196.104
www.google.com. 20 IN A 74.125.196.99
www.google.com. 20 IN A 74.125.196.147
www.google.com. 20 IN A 74.125.196.105
www.google.com. 20 IN A 74.125.196.103
;; Query time: 2 msec
;; SERVER: 192.168.186.1#53(192.168.186.1)
;; WHEN: Wed Jun 17 17:17:37 CDT 2015
;; MSG SIZE rcvd: 139
From "man dig":
+[no]nssearch
When this option is set, dig attempts to find the authoritative name servers for the zone containing the name being
looked up and display
the SOA record that each name server has for the zone.
Since there's no authority section in the response, +nssearch is going to return nothing.
www.google.com is not a zone, but a name in a zone. Therefore it doesn't have any NS records (or SOA records) for dig to display. Try dropping the www. bit and you'll get more output.