<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

<meta name="Generator" content="Microsoft Word 15 (filtered medium)">

<style><!--

/* Font Definitions */

@font-face

        {font-family:"Cambria Math";

        panose-1:2 4 5 3 5 4 6 3 2 4;}

@font-face

        {font-family:Calibri;

        panose-1:2 15 5 2 2 2 4 3 2 4;}

@font-face

        {font-family:"Times New Roman \(Body CS\)";

        panose-1:2 11 6 4 2 2 2 2 2 4;}

/* Style Definitions */

p.MsoNormal, li.MsoNormal, div.MsoNormal

        {margin:0in;

        font-size:12.0pt;

        font-family:"Calibri",sans-serif;}

a:link, span.MsoHyperlink

        {mso-style-priority:99;

        color:#0563C1;

        text-decoration:underline;}

span.EmailStyle17

        {mso-style-type:personal-compose;

        font-family:"Calibri",sans-serif;

        color:windowtext;}

.MsoChpDefault

        {mso-style-type:export-only;

        font-size:12.0pt;}

@page WordSection1

        {size:8.5in 11.0in;

        margin:1.0in 1.0in 1.0in 1.0in;}

div.WordSection1

        {page:WordSection1;}

--></style>

</head>

<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">

<div class="WordSection1">

<p class="MsoNormal"><span style="font-size:16.0pt">Hey Folks, <br>

<br>

Has anyone else seen an increase in DNS over TCP traffic in their environment?   We have been seeing a steady increase since late last year and have believe we have narrowed down a major cause.   After reaching out to the Chromium folks and Cricket Liu reaching

 out to the Microsoft folks it seems that there has been a recent behavior change that is incompatible with each other, which is causing DNS over TCP to be preferred over UDP.

<br>

<br>

Based on my discussion with the Chromium team, It appears that for about 3 years Chrome has a bit of internal logic around falling back to TCP when there is a detection of reduced UDP port entropy being handed out by the OS.   When the Chrome stack falls back

 to TCP, according to the Chromium folks, it will continue to use TCP until Chrome is restarted or there is a network change (port flap, IP address change, etc).  The code that tracks the low entropy can be found here <a href="https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fsource.chromium.org*2Fchromium*2Fchromium*2Fsrc*2F**AA2Fmain*3Anet*2Fdns*2Fdns_udp_tracker.cc__*3BKw!!JYsgTRAg6ZQ!JXbodcwfxhA6x3Ke84KiaeWXV4JdkFYHXZRfkJ4ZNmq9ZgN9K5IM7oGrprLkXfgAXb8S4Syp_uTZAA*24*26data*3D05*7C01*7CJensen.Thomas*40microsoft.com*7C46bf4ec81c0b41f646de08db20f93b7f*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638140027074680500*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C*26sdata*3D9akEpQzQhGOtY8if4wEPGwp*2F*2FvWAzwcsi*2FFbp*2FeWerQ*3D*26reserved*3D0__*3BJSUlJSUlJSUlJSUqJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!JYsgTRAg6ZQ!PhtPjpR8aH8MxSlUxiqTuxxArW-OHrjhf_vlfc-ADjkW-oc1EXPRnJYGT3CILFA-kVB7Jzq4i_EuJ7xnLaFNocN3c2Y*24&data=05*7C01*7CJensen.Thomas*40microsoft.com*7C74e27fc2a3cb41b89d1e08db20fbbd31*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638140037837284609*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C&sdata=VV2IZPD*2FgFvwviEmIxen24tD4dP1h08enUlfUGcQHFg*3D&reserved=0__;JSUlJSUlJSUlJSoqKioqKioqKioqKioqKioqKiUlKioqKioqKioqKioqKioqJSUqKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!JYsgTRAg6ZQ!OVuVgR3GPLP4UsVh3eE8u8k6EO7NinjkVIyVGJqf95zuQ05RfCZhWsJ64IYoy0Asz6zCbaTWXBsa6MfSAkZMu1OJDjI$" title="https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fsource.chromium.org*2Fchrom">net::DnsUdpTracker</a>.  <br>

<br>

The Chromium folks confirmed that they are seeing an increase of TCP traffic from Windows client only.   Crickey Liu reach out to the Microsoft folks and dfound that starting with Windows 11, the OS began to use socket caching due to exhaustion occurring with

 UDP ports.  Meaning that DNS UDP port is cached when communicating with the same server and any DNS client will continue to get the same UDP src-port when connecting to that DNS server.   Now starting in Chrome 105, there was a change made by the Chromium

 folks to leverage the internat Chrome DNS stack to to run more Windows DNS queries through the Chrome stack instead of delegating the resolutions to the OS.   Due to the low UDP port entropy logic discussed above in combination to the socket caching introduced

 Windows 11,  we are seeing DNS clients preferring TCP over UDP for what seemed like to discernable reason until these discussions with the Chromium and Microsoft folks.

<br>

<br>

>From our perspective this is and will cause a lot of issues for DNS providers as more and more Chrome + Windows clients begin to prefer TCP over UDP for DNS. And believe this has the potential to quickly become a rather large issue for DNS providers, especially

 at scale. <br>

<br>

Is anyone here seeing a seemingly unexplained increase in DNS over TCP traffic and if it is causing any issues within their network?   

<br>

<br>

For reference, Google Chrome version 105 was released on August 30th, 2022 and Windows 11 was released on October 5th, 2021.  Only with the combination of the two (post August 30th, 2022) would the issue be seen.

<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-size:16.0pt"><br>

Thanks, <br>

<br>

<o:p></o:p></span></p>

<p class="MsoNormal"><span style="font-size:14.0pt">Adam Casella | Solutions Architect<br>

Infoblox | infoblox.com<br>

914.953.8571</span><o:p></o:p></p>

</div>

</body>

</html>