DNS resolution issue in APAC region

[Arvindkumar J]

Hi, 

We are noticing an issue with the DNS resolutions for a few aliases and this is only with 8.8.8.8 and 8.8.4.4 DNS servers from APAC regions. And this works fine from US regions. 

 

Please find the dig outputs below. 

### OpenDNS - working fine

viz-admin@viz-ltp-178:~$ dig @208.67.222.222 engage.vizury.com

;; ANSWER SECTION:
engage.vizury.com.    900    IN    CNAME    dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com.
dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com. 60 IN A 52.4.93.214
dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com. 60 IN A 54.210.225.213

### 8.8.8.8 from APAC region... puts a suffix of vizury.com to the actual CNAME record
viz-admin@viz-ltp-178:~$ dig @8.8.8.8 engage.vizury.com

;; ANSWER SECTION:
engage.vizury.com.    113    IN    CNAME    dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com.vizury.com.

### 8.8.8.8 from, US region. works fine

ubuntu@ip-10-0-207-207:~$ dig @8.8.8.8 engage.vizury.com

;; ANSWER SECTION:

engage.vizury.com. 899 IN CNAME dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com.

dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com. 59 IN A 52.4.93.214

dmpui-prod-elb-1048382604.us-east-1.elb.amazonaws.com. 59 IN A 54.210.225.213

As you have noticed, the APAC region resolution adds a suffix ".vizury.com" to the response and this results in the failure. What should be done here to correct this?

[Alex Dupuy]

As you have noticed, the APAC region resolution adds a suffix ".vizury.com" to the response and this results in the failure. What should be done here to correct this?

What do you see when you query via the web or DNS-over-HTTP interface to dns.google.com? And what is the /24 subnet of your APAC host that is getting these strange responses?

[Arvindkumar J]

Quick update here:

We made changes to our CNAME record ( adding trailing dot ) and it started working fine. But just curious to know why it was working before without the trailing dot. Is there any norm that we should follow here ?

[Alex Dupuy]

On Monday, July 10, 2017 at 12:06:41 PM UTC-4, Arvindkumar J wrote:

Quick update here:

We made changes to our CNAME record ( adding trailing dot ) and it started working fine. But just curious to know why it was working before without the trailing dot. Is there any norm that we should follow here ?

There is no norm, sadly.

Some DNS hosting services and software require it (BIND, Google Cloud DNS, many others) as it was written in the RFCs.

Others try to be "helpful" and add an implicit trailing dot whether you put one there or not (EasyDNS, some other one).

And then there are the frustrating ones like PowerDNS and GoDaddy that will not accept the trailing dot.

I thought I read (or wrote?) something listed more specifics about which software / services require . and which don't, and which won't accept it. But I can't find it.

I would always put the . there to start (since it is the RFC-right thing to do) and you will never get a silent misconfiguration (worst you get a parse error from PowerDNS or GoDaddy), and which point you accept the unfairness of the world and take it out.

https://serverfault.com/questions/18113/dns-trailing-periods

https://serverfault.com/questions/803033/should-i-append-a-dot-at-the-end-of-my-dns-urls

https://stackoverflow.com/questions/19480767/domain-names-with-dots-at-the-end

http://www.zytrax.com/books/dns/apa/dot.html

[Arvindkumar J]

Thanks Alex for the explanation. 

Also wanted to understand is why would Google DNS servers behave differently in APAC and US ? The resolution requests from APAC had issues (appended the suffix ".vizury.com" ) but the US requests were working fine. 

[Alex Dupuy]

The difference was probably just that there were cached bad answers in one location, and not the other. Or your name servers are running different versions and the handling of (lack of) trailing dot changed 

[Des]

We had the exact same issue at the exact time affecting the same location. Adding the trailing full stop to our cnames solved this for us too. Cheers.