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-corne...
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-c...
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...
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 ...
What do you see after running
ipconfig /displaydnsa few seconds after runningipconfig /flushdns? For example, do you see 23.74.131.109 anywhere? Do you have more than 1 active interface and if so, is it possible that the missing DNS packets were exchanged on an interface you weren't capturing on?You could also try disabling DNS caching beforehand? (Task Manager -> Services -> Dnscache -> Stop)
Hi Chris,
ipconfig /displaydns shows no sign of these addresses, and disabling the other Ethernet NICs in the box did not change behavior -- more pcaps (and displaydns output) posted to the Web site
However, you got me looking more closely at the pcaps, and I'm noticing these short UDP frames being sent after the DNS query but before the DNS responses arrive. UDP frames with what looks like an encrypted payload, sent to IP addresses owned by an entity which WHOIS calls 'Total Server Solutions'
More investigation needed
--sk
OK, I've tried several browsers (FF, IE, Chrome); they each display the same pattern:http://www.skendric.com/dns/W... The Client emits the A Record query, then it emits a UDP frame to an IP address registered to Total Server Solutions, Total Server Solutions returns a response, and then the DNS server returns an A Record response. The Client sends a TCP SYN to an IP address which does not appear in the pcap nor in the output of ipconfig /displaydns
Speculatively, sounds like some kind of competing DNS resolver installed on the Client
--sk