Revision history [back]
What protocols do hosts use to perform host-name to IP address resolution
I am puzzled by how a client is finding the IP address to use when its browser loads a Web page
Typically, I see the client perform an A Record look-up, receive back a A Record response, then send a TCP SYN to the IP address specified in the A Record response, whereupon it loads the home page of this site using TCP/HTTP
http://www.skendric.com/dns/www-cornell-edu-typical.pcapng
However, while analyzing an issue, I notice that the client receives back an A Record response (23.193.130.71) which it doesn't use (happens to be an Akamai host) ... instead, it sends a TCP SYN to some other host (another Akamai IP address: 23.74.131.109), which is uses to load the home page of this site. No where prior to this TCP SYN do I see 23.74.131.109 (Find Packet... Packet Details... String 23.74.131.109). So I wonder: from where did the client learn this IP address?
http://www.skendric.com/dns/www-ibm-com-not-prescient.pcapng
In another example, I see similar behavior ... although I notice as well prescience: the client sends the A Record look-up and before receiving the response emits a TCP SYN to an Akamai host (23.62.159.145). Again, no where prior to this TCP SYN do I see 23.61.159.145)
http://www.skendric.com/dns/www-apple-com-prescient.pcapng
Now, the fact that in the first example, the client speaks directly to a box owned by the site (www.cornell.edu in this case) doesn't surprise me -- this enterprise hosts their own Web server. The fact that the client speaks to Akamai for www.ibm.com and www.apple.com doesn't surprise me: big sites, apparently they outsource content caching to Akamai.
But what surprises me is that the DNS exchange seems not to inform the address used in the TCP/HTTP session. And particularly what surprises me: where does the client get the Akamai IP address it uses for the TCP/HTTP session?
What am I missing? This seems basic ... but apparently, there is something basic which I'm not considering.
Mechanics - Host runs Windows 10 - Pcaps taken via an in-line analyzer (ProfiShark)installed on the patch cord running between the host and the Ethernet switch - pcaps posted above filtered using "not (eth.addr==ff:ff:ff:ff:ff:ff or stp or ssdp)" prior to posting - Host capture procedure: * Start capture * ipconfig /flushdns * Refresh page in browser * Stop capture
Rule-out
I have been reading about DNS over QUIC ... but I see no sign of QUIC in the pcap
And I rule out the local hosts file
C:\>dir hosts /s Volume in drive C is SSD Volume Serial Number is [...] Directory of C:\Windows\System32\drivers\etc 12/07/2019 01:12 AM 824 hosts 1 File(s) 824 bytes Directory of C:\Windows\WinSxS\amd64_microsoft-windows-w..ucture-other-minwin_31bf3856ad364e35_10.0.19041.1_none_eb30aafa046f78ad 12/07/2019 01:08 AM 824 hosts 1 File(s) 824 bytes Total Files Listed: 3 File(s) 1,823 bytes 0 Dir(s) 59,105,091,584 bytes free C:\>
I can see complexity in this environment: The client is loaded with anti-malware software, and there is a Firewall sitting just upstream of the switch. But at the moment, these seem to me to be distractions.
Anyway, if you have suggestions, do let me know.
--sk