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: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 6 Jan 2010 16:28:37 -0800
On Jan 6, 2010, at 12:55 PM, Richard Brooks wrote:

> I think that Sky have more than one email server/mirror. Try doing an
> nslookup on '74.125.127.208', on my PC it came back as
> 'pz-inf208.1e100.net'.'

So there are at least two different A records out there in DNSland that return 74.125.127.208.

Let's see:

$ host -a bskyb-pop3-ssl.l.google.com
Trying "bskyb-pop3-ssl.l.google.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51975
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;bskyb-pop3-ssl.l.google.com.	IN	ANY

;; ANSWER SECTION:
bskyb-pop3-ssl.l.google.com. 211 IN	A	74.125.127.208

;; AUTHORITY SECTION:
google.com.		31920	IN	NS	ns1.google.com.
google.com.		31920	IN	NS	ns3.google.com.
google.com.		31920	IN	NS	ns4.google.com.
google.com.		31920	IN	NS	ns2.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.		341295	IN	A	216.239.34.10
ns1.google.com.		36532	IN	A	216.239.32.10
ns4.google.com.		150710	IN	A	216.239.38.10
ns3.google.com.		70248	IN	A	216.239.36.10

Received 197 bytes from XX.XX.XX.XX#53 in 23 ms

$ host -a pz-in-f208.1e100.net
Trying "pz-in-f208.1e100.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34359
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13

;; QUESTION SECTION:
;pz-in-f208.1e100.net.		IN	ANY

;; ANSWER SECTION:
pz-in-f208.1e100.net.	86351	IN	A	74.125.127.208

;; AUTHORITY SECTION:
net.			17825	IN	NS	E.GTLD-SERVERS.net.
net.			17825	IN	NS	H.GTLD-SERVERS.net.
net.			17825	IN	NS	D.GTLD-SERVERS.net.
net.			17825	IN	NS	J.GTLD-SERVERS.net.
net.			17825	IN	NS	F.GTLD-SERVERS.net.
net.			17825	IN	NS	G.GTLD-SERVERS.net.
net.			17825	IN	NS	I.GTLD-SERVERS.net.
net.			17825	IN	NS	A.GTLD-SERVERS.net.
net.			17825	IN	NS	C.GTLD-SERVERS.net.
net.			17825	IN	NS	K.GTLD-SERVERS.net.
net.			17825	IN	NS	B.GTLD-SERVERS.net.
net.			17825	IN	NS	M.GTLD-SERVERS.net.
net.			17825	IN	NS	L.GTLD-SERVERS.net.

;; ADDITIONAL SECTION:
B.GTLD-SERVERS.net.	75602	IN	A	192.33.14.30
B.GTLD-SERVERS.net.	75602	IN	AAAA	2001:503:231d::2:30
F.GTLD-SERVERS.net.	85234	IN	A	192.35.51.30
J.GTLD-SERVERS.net.	78545	IN	A	192.48.79.30
H.GTLD-SERVERS.net.	79639	IN	A	192.54.112.30
L.GTLD-SERVERS.net.	150475	IN	A	192.41.162.30
I.GTLD-SERVERS.net.	155091	IN	A	192.43.172.30
A.GTLD-SERVERS.net.	57911	IN	A	192.5.6.30
A.GTLD-SERVERS.net.	57911	IN	AAAA	2001:503:a83e::2:30
D.GTLD-SERVERS.net.	55140	IN	A	192.31.80.30
K.GTLD-SERVERS.net.	109507	IN	A	192.52.178.30
M.GTLD-SERVERS.net.	41034	IN	A	192.55.83.30
C.GTLD-SERVERS.net.	75746	IN	A	192.26.92.30

Received 507 bytes from XX.XX.XX.XX#53 in 2 ms

Both of those came from an internal server caching the results.  And for the reverse lookup:

$ host -a 74.125.127.208             
Trying "208.127.125.74.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55402
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;208.127.125.74.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
208.127.125.74.in-addr.arpa. 86210 IN	PTR	pz-in-f208.1e100.net.

;; AUTHORITY SECTION:
125.74.in-addr.arpa.	44346	IN	NS	NS4.GOOGLE.COM.
125.74.in-addr.arpa.	44346	IN	NS	NS1.GOOGLE.COM.
125.74.in-addr.arpa.	44346	IN	NS	NS3.GOOGLE.COM.
125.74.in-addr.arpa.	44346	IN	NS	NS2.GOOGLE.COM.

;; ADDITIONAL SECTION:
NS1.GOOGLE.COM.		36446	IN	A	216.239.32.10
NS3.GOOGLE.COM.		70162	IN	A	216.239.36.10
NS4.GOOGLE.COM.		150624	IN	A	216.239.38.10
NS2.GOOGLE.COM.		341209	IN	A	216.239.34.10

Received 225 bytes from XX.XX.XX.XX#53 in 7 ms

Again, from the internal server.

Perhaps if some other server is queried, a different PTR record will come back for 208.127.125.74.in-addr.arpa.  It would be interesting to see the DNS traffic issued when you do an nslookup on 74.125.127.208 and when Wireshark resolves 74.125.127.208.

The problem is that the difference might just reflect configuration differences in the resolvers, or quirks of the current implementations of those resolvers, or something else not guaranteed to be an invariant characteristic of whatever resolver Wireshark happens to be using (which is a function of how it was built - it might just be using the native OS's resolver, rather than any of the asynchronous resolvers it can be configured to use).