Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] How does Wireshark do name resolution?

From: Richard Brooks <richardbuk@xxxxxxx>
Date: Sat, 9 Jan 2010 08:20:34 -0000

OK, I can see where your coming from now. I have attached a screenshot taken from Wireshark. As you can see the first time the 'bskyb-pop3-ssl.l.google.com' information appears in the trace, is in a packet coming from the DNS server’s reply to a reverse DNS query (DNS server ip = 8.8.8.8), and this has always been the case. My guess is that if Wireshark already had the said information cached, it would not have issued the DNS query, that resulted in the said reply.

 

Judging by the responses I’m getting on this question, it looks like I am just going to have to improve my knowledge of TCP/UDP/IP packets and diagnose what’s going on myself from Wireshark’s output.

 

 

 

 

 

Regards

Richard

<RichardBUK@xxxxxxx>

 

 

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Andrew Hood
Sent: 08 January 2010 11:34
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How does Wireshark do name resolution?

 

This really belongs in "users", but since it is here ...

 

Richard Brooks wrote:

> Wireshark must have got the 'bskyb-pop3-ssl.l.google.com' result somehow. I

> can do an nslookup just after Wireshark comes back with

> 'bskyb-pop3-ssl.l.google.com' but I still get the same old vanilla flavoured

> 'pz-in-f208.1e100.net'.

 

Maybe I didn't express it well enough. One of the gurus might please

confirm.

 

If I remember correctly, when Wireshark detects a DNS reply packet in

the datastream it will use the info in that packet to do IP/name resolution.

 

That means that the names you get in your decoded output can vary

depending on which packets are in your trace. If there are no suitable

packets in the trace Wireshark will do DNS lookups to to the IP/name

resolution.

 

So if your trace has:

 

DNS query for bskyb-pop3-ssl.l.google.com

DNS response bskyb-pop3-ssl.l.google.com is 74.125.155.208

TCP conversation with 74.125.155.208

 

then 74.125.155.208 will be reported as bskyb-pop3-ssl.l.google.com

 

If it has:

 

TCP conversation with 74.125.155.208

DNS query for 74.125.155.208 (with realtime DNS resolution Wireshark

might issue this query itself)

DNS reply 74.125.155.208 is px-in-f208.1e100.net

 

then 74.125.155.208 will be reported as px-in-f208.1e100.net

 

If realtime resolution is off, Wireshark will do the query when you

decide the tace and you will again get px-in-f208.1e100.net.

 

If you choose to put entries in your hosts file, you can tell whatever

lies you like in your output.

 

--

There's no point in being grown up if you can't be childish sometimes.

                -- Dr. Who

___________________________________________________________________________

Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>

Archives:    http://www.wireshark.org/lists/wireshark-dev

Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev

             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4755 (20100108) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com