 Hi, I'm gonna briefly discuss what the Kubernetes end dots issue is and then show you how you can use Pixie to see if this issue is negatively affecting the performance of your applications. So an advantage of using Kubernetes is that it seamlessly handles service discovery. A service represents a virtual IP backed by a set of pod IPs. This makes your intranode communication really easy and portable. A service can simply use the virtual IP for another service rather than include the full domain. Now, DNS resolution is dictated by a pods, et cetera, resolve.conf config file. I've got an example of one pulled up here. There's three things in this file. There's the name server, which is the IP address where DNS queries should be forwarded to. In this case, it's cube DNS. We have five local search domains here and I'll get back to those in a second. And then we have an end dots optional configuration value. This is the threshold for the number of dots which must appear in a name before an initial absolute query will be made. With an end dots value of five, any name containing less than five dots inside it, the syscall will try to resolve it sequentially going through all the local search domains listed above before trying it as an absolute name. Any name greater than, with greater than five dots will be considered fully qualified and it will just do the absolute name query first. A fully qualified domain name is a domain name for which there are no local search will be executed and the name will be treated as an absolute one during the resolution. You can make any name fully qualified by adding a period at the end. So let's look at Pixie and see this in action. So I've got Pixie installed in my cluster and I've pulled up the script of the week DNS external FQDN list script here. Now this script, Pixie traces all DNS traffic in your cluster automatically without instrumentation and it pairs the DNS requests with responses. So what this script is doing is it's looking at all those DNS requests and it's looking at the ones that were resolved successfully and pulling out those fully qualified domain names. Now I filtered out anything ending in dot local or dot internal so that I'm only looking at the external names. So here you can see the number of requests and we can sort it by number of requests and the fully qualified domain names. Now here's where we have an opportunity for optimization. For each one of these external names we can see how many times it's since all of these have less than five dots we're gonna look at how many times they're bouncing around with the local domain names first. So let's look at one of these and this link will take us to another script which uses the FQDN as a substring again searching all of the DNS requests in our cluster. So we've used this name not as a fully qualified domain name. And so you can see here that it's trying this name with dot cluster dot local dot Google dot internal basically all of the local domain names specified in that resolve.conf file that we were looking at and you can see over here the number of requests that were resolved or the number of requests for each of these queries and the percentage that were resolved as well as the latency for each of these requests. So the impact on your application performance will depend on the number of requests as well as the latency but you can use these two scripts let me go back up to the first one to see if any of your external name resolutions could be made fully qualified.