Skip to content

Incorrectly formatted FQDN's to googleapis.com #2213

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ericuldall opened this issue Apr 11, 2017 · 5 comments
Closed

Incorrectly formatted FQDN's to googleapis.com #2213

ericuldall opened this issue Apr 11, 2017 · 5 comments
Assignees

Comments

@ericuldall
Copy link
Contributor

I've noticed all of the references to the Fully Qualified Domain Name "googleapis.com" are incorrectly formatted. Per RFC 1034 FQDN's should have a trailing dot in order to remove any ambiguity and unnecessary lookups.

Explanatory documentation HERE

We were pointed to this doc by a Kubernetes network engineer at Google after having many DNS lookup issues inside of our GKE clusters. After running some tests we noticed a minimum 100ms improvement per request after adding the trailing dot.

I have a PR ready that I will post for review.

@ericuldall
Copy link
Contributor Author

PR #2214 opened

@lukesneeringer
Copy link
Contributor

Hi @ericuldall,
Thanks for reporting.

I am not going to make the change suggested in #2214 for the reasons I covered there. However, you can continue to use this in your own implementation by specifying your baseUrl directly:

new BigTable({ baseUrl: '...' });

@ericuldall
Copy link
Contributor Author

ericuldall commented Apr 12, 2017

I understand your concerns. I would highly suggest putting a warning for people using this library in a kubernetes cluster with a large number of http requests as the internal kube-dns will drop lots of requests without the trailing dot. This is because in the kubernetes resolve.conf they use a large number of ndots to check for internal services.

resolv.conf sample:

search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.project.internal
nameserver 10.20.30.40
options ndots:5

One of the main problems is the setting: sysctl -w net.netfilter.nf_conntrack_max=65535
That table is of a finite size per host machine and if it overflows, requests get dropped (this shows up as getaddrinfo ENOTFOUND, errors). Using the trailing dot seems to be an easy remedy to avoid all the internal lookups and bypass the problem completely.

Another option is to set the pod dnsPolicy, DnsPolicy: Default in the pod spec.

We will move forward creating instances with the overridden baseUrl for our needs. Thanks for looking into this.

@lukesneeringer
Copy link
Contributor

lukesneeringer commented Apr 12, 2017

Hmm, I understand. Let me think on this more and discuss it internally and see if my position changes. (It might.)

@stephenplusplus
Copy link
Contributor

Due to an issue brought up in #2249, we're going to revert this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants